I was developing Open Boot - the Forth-based firmware that eventually became Open Firmware AKA the IEEE 1275-1994 Standard - at Sun back in the late '80s. It was intended to replace Sun's existing "sunmon" firmware which was written in C. The diagnostics group that maintained sunmon was adamantly opposed to Open Boot, probably mainly because it threated their ownership of the firmware. The argued against Open Boot, thinking that they had an ironclad argument: "Forth is interpreted therefore it is too slow". The argument totally backfired because I knew some facts about the hardware that had apparently escaped them. The dominant factor in the perceived firmware speed was scrolling text on the non-accelerated megapixel frame buffer. That involved a megapixel memory-to-memory copy for every line. On the monochrome display it was terrible and on the color frame buffer it was horrendous. The sunmon firmware ran from EPROM, whose access time was glacial compared to RAM and even worse compared to cache - and EPROM was not cacheable. To make matters even worse, on the SPARCstation 1 that was the first target for Open Boot, the EPROM data width was only 8 bits, so a 32-bit instruction fetch took 4 super slow EPROM accesses. You see where I am going with this, right? All it took to leave sunmon in the dust was to copy the screen-scrolling and bitblt routines into RAM. Just to pour salt on the wound, I also copied the modest-sized set of code words at the core of Forth into RAM. Direct-threaded Forth ran from RAM substantially faster than compiled C code ran from EPROM. Our project manager did not let me turn on the cache on the first shipment, worrying about bugs, but relented on later revisions. After the cache was turned on, Forth just flew. The fact that Forth is so well-factored, and the actual machine code is confined to a small compact area, meant that the cache performed extremely well. Furthermore, since Forth didn't need to use the SPARC register windowing mechanism - register windows were designed for C-style stack frames and are essentially useless for Forth stacks - the endemic SPARC problem of window spill and fill handlers didn't affect the firmware at all. That made the firmware much more adept at post-mortem examination of kernel crashes.
In a lot of system code, the performance can be dominated by access to devices that are much slower than cache. In that environment, so long as you are careful about a few CPU intensive routines like memcpy and bitblt, threaded code can be nearly as fast as compiled code, and sometimes faster. And it is much more compact, which matters a lot when you have to fit everything into some flavor of ROM.
Neat story, thanks for sharing. OpenBoot is what got me into Forth. :D. The hack that allowed me to find a process, calculate the uid address and then use open boot to set it to 0. Opened the door for me into looking at unconventional languages like Forth and APL.
In the good old days, one would buy and read a computer magazines equally for its content as well as the ads. They were an important source of information in a day and age without the WWW.
Of course, the advertising back then used a trick which seems to escape all modern advertising think tanks: they had great user targetting without shady tracking schemes, by advertising things a magazine reader would be interested in. Imagine this trick being used in todays web :p.
Back in those days cover art and ads for games often had art drawn by artists in physical media, or photographs, which the 8-bit games of the day never had a snowball's chance in hell of living up to.
The blurbs in ads could never really tell you whether the gameplay was any good.
And, most of all, ads almost always lied.
I learned that marketers and advertisers would say anything to make a sale, and that it was best to just ignore them.
As a result, I never ever bought anything based on an ad... however, an ad might make me aware that something existed and entice me to investigate further.
Then I'd read reviews, which too often were almost as bad as the ads, especially in the popular gaming/software magazines which preferred to write puff pieces about everything they reviewed... probably to stay on the good side of advertisers and to keep getting sent free products to review.
It was rare to find honest reviews, and even then it was hard to ultimately know whether the product was actually any good until you tried it yourself, and did so for an extended period of time.
I've wasted so much money on products which seemed to be good at first but ultimately turned out to be trash or not what I actually wanted/needed.
Advertising rarely makes any of this any better. Usually it makes it worse.
> an ad might make me aware that something existed and entice me to investigate further.
I believe it's one of points of ads: when choosing what product to buy, you're likely to choose between options A and B, which you've heard about (either from ads, or friends), and not option C, which you've never heard about.
I used to subscribe to a model aircraft magazine. The core of the thing is ads: they try a model, see how it builds, feel how it flies, write a nice article with pretty pictures. Then I read it, and dream.
There was a report that targeting article contents yielded better revenue than targeting the audience for some European company, but I can’t find a link right away.
I might be into archery and photography, but if I'm browsing an article about lenses and I see an ad for arrows, that's just creepy.
But if I see an ad for lenses, or even gimbals, I might go and buy one on the spot. Or put it in the cart and sleep on it, whatever.
At this point it's worse than that (for advertisers), because I'll never see the targeted arrow ad, since I block as much surveillance tech as I can without disabling Javascript entirely. But if a blog serves same-site content which happens to be an ad, and some of them are smart enough to do that, I'll see it.
Oh no, that would involve the people operating the website to actually have to give a shit about what ads are shown, and worse, they would have to interact with their advertisers!
I still have a fairly complete set of Byte Magazines from the early 80's to about 2000. I absolutely loved the ads then and love reviewing them when I get a chance. It was amazing how much I learned from the ads.
Explaining Computer Shopper to the web generation is always interesting.
It's odd, I found old books people left in our building hall. And they had the postcard format ad (doubles as a bookmark).. and it felt "nice". Not intrusive, not obnoxious.. yet it's the same device.. but some aspects make it acceptable.
- it's a small size compared to a book
- it's not monitored
- it feels more personal (<= almost absurd)
I feel like this is part of why "IoT" is quite attractive and satisfying, even though you have modern tooling and bluetooth + wifi in a <$5 package nowadays, you're still writing code close to the metal.
In 1985ish I did a silly Forth prog on a Speccy for parent's day at school. I'm just an honest syadmin these days but I think I made text along the lines of "This is a line of text" or "Today is Parent's Day" smoothly bounce around the screen and change colours in about 20 LOC. Please be charitable, this was 35 years ago and I'm no programmer and still lack imagination.
Not sure if there are official IA specs for such things but pretty much all of these old magazine scans tend to have a ZIP full of JPEG2000 images, which the IA will generate directory listings for:
The great thing is, a lot of those old computers still work.
There is no reason not to boot them up and use them and enjoy the way they work.
Disclaimer: 30+ machines in my retro- collection. I will have to dust off the Jupiter Ace and have some Forth sessions at the next 'one page of code' challenge ..
Another disclaimer: lots of old hardware doesn't work anymore. The electrolytic caps evaporated ages ago and the failure modes can sometimes be spectacular. Commodore 64 power supplies for example tended to fail in a way where they would dump high voltage over the line and fry the attached machine.
Old chips can definitely go bad as well. However, many of the machines were simple enough that it's possible to diagnose and fix the problem with a bit of knowledge and some gumption.
It's the one my dad bought in 1984 or so. Imagine the scene:
Me and my brother flew home to West Germany (Rheindahlen) from the UK (Army brats) for the Christmas hols. Dad proudly shows us the new computer and plugged the power into the video input. pop. About two months later we receive the repaired unit from NAAFI. Me and my brother went back to school for the spring term. Mum and Dad had not banked on the C64 as a main Chrimbo pressie for us and gave us other things. They clearly knew well ahead of time how IT will always screw up - they were clearly prescient types.
We absolutely loved it. I wont bore you any more with reminisces but I still have it and it still works.
Capacitors don't evaporate, they swell or blow if dodgy enough - long story, search it ("blown capacitors".)
Of the 30+ machines in my collection, only a small handful have needed cap replacements. And, this is not such a big deal anyway - in fact its quite easy in most cases. Older computers have the advantage that they're quite a bit more accessible than the new stuff.
Much rather have to replace a cap than de-glue a touchscreen display ..
Corewars[1][2][3] is somewhat in the same vein though the arena is the VM memory, and not a physics sim. You write an assembler program whose goal it is to as quickly as possible find other programs and make them run an illegal instruction. Last program standing wins.
Can confirm... I wrote Forth/2 for OS/2, it was a hoot once I got it working. 8)
It looks like I might be resurrecting "STOICAL", which was targeted at Linux, for Windows...http://stoical.sourceforge.net/documentation.php
It would be nice to see it run under Linux... the C source looks too much like typical "be as clever as possible" macro magic, which my non-C adjusted brain can't hack.
I'll re-implement in either assembler, or free pascal.
The reason is that STOICAL implements types, arrays, and dictionaries in what seems to be a quite reasonable and sane matter.
It does type checking when you want, and seems like it could do object oriented as well, if I can push it that way.
Learning how Forth is implemented and then implementing my own totally blew my mind. I've fallen hard in love with Forth.
My greatest motivation to learn Forth inside and out is its value in rebuilding civilization if we ever find ourselves in a place where a significant amount of technology has been lost. I don't think there's a more powerful and yet incredibly simple way to bootstrap a general purpose programming environment than writing a Forth. It's a relatively small amount of knowledge that needs to be preserved, compared to all the complexity that would be needed to have compilers, garbage collectors, and all that jazz again.
On the other hand, according to this[0] author who ported a game from assembly to C and Forth, Forth seems to drastically increase development time and perform 10-20 times worse than the equivalent assembly.
I wonder how taliforth compares to something like VFX forth or SwiftForth. I just remember running an old gforth program in swiftforth and getting something like a 15x speed increase.
I have been out of the loop for a long time, but AFAIK gforth-fast is still quite far behind the commercial forths when it comes to speed. I believe there is still room for improvement of forth speed, but iirc the VFX forth people didn't think it was worth the extra compilation time. Back then it compiled a 1MLOC project in 29 seconds, and the resulting code was plenty fast. As a baseline, a fast non-optimizing compiler should be able to compile about 1mloc a second for a moderately simple language.
In defence of Forth, the performance numbers tell us more about the Forth implementation than about Forth's performance potential, and the development time depends on whether the developer is already a competent Forth programmer.
Fundamental problem speed wise appears to mostly be an issue with the limited 65C02 arch. Quote from article "The X register has to be adjusted to make room on the data stack each time a function is called. It takes 7 cycles to save the X register to the hardware stack at the beginning of the function and restore it at the end. It takes 2 more cycles for DEX for each byte of local variable used to adjust the data stack pointer."
Forth isn't slow because it can be compiled to machine code, which is not even touched on by the article.
The main argument of the article seems to be reiterating the idea that in a tree, most of the nodes are leaves. For instance, in a balanced binary tree containing 2^n-1 nodes, a little over half the nodes are leaves. So if we visualize the call graph as traversing a tree, where the leaves are primary primitives in machine language, the bulk of the activity is always going on in the machine language leaves. When a primitive operation returns, much of the time control soon passes to another primitive operation, staying near the bottom of the tree.
> When a primitive operation returns, much of the time control soon passes to another primitive operation, staying near the bottom of the tree.
Depending on how the threading is implemented, the primitive "return" (NEXT) operation may even pass control directly to the next primitive; a typical threaded implementation of NEXT might be something along the lines of "load next codeword and branch to it". You only go through the full call/return sequence, e.g. updating the return stack, when entering or leaving a non-primitive word.
I think it's a yearning of simplicity. Software engineering today is complex, slow, and extremely removed from the machine. Forth is one of the simplest environments you can build that allows you to build complex software.
I've wondered the same. It feels to me like we as a software writing community are yearning for a new paradigm or challenge.
Often time this expresses itself as a framework du'jour. But recently it seems like people are reaching back to languages of yore to see if there is some piece of mystic art to be applied to today's problems.
I'll admit I'm guilty of this outlook. I would love to write code professionally in Forth, APL, or any number of 'long gone' languages.
I was doing some programming language work last year for Facebook Horizon, and while not appropriate for that product it really made me interested in building a visual Forth or APL for programming in VR, mostly because the high amount of expressiveness with minimal symbols.
I fell into that rabbit hole thanks to the quarantine. I've been find it therapeutic: the simplicity of it is unbeatable. It gives me the same sense of speaking directly to the machine that assembly does, but at a higher level. I've also grown to love RPN.
I posted my project here just the other day: https://news.ycombinator.com/item?id=24604457 I had an absolute blast working on it, and I'm looking forward to my next Forth-related project (still deciding on what it's going to be).
Forth seems to be a write only language, I'm not sure if it's the reverse polish stack oriented structure, or the lack of modern things we're used to like arrays, procedure calls, etc... STOICAL seems to address all of these, but it's written in dense C code that I can't make heads nor tails of... but the ideas are really, really attractive.
The stand out features for me
'string puts a string on the stack (along with a type flag for string
'cube : dup dup * * ; is how you would define cube, which is a bit different, but not a huge shift
He's got ways to do types, dictionaries, arrays that also look like stacks... all sorts of magic including networking!
How much of it could be crammed into something that boots inside of a VM?
The reason might be that there is nothing new to invent or explore so they wallow endlessly in old dried-up shit. Forth is particularly useless, because it only truly made sense in fixed-width computers, where one word was equal one symbol and list of symbols was on separate paper tape. It was so sweet compared to Fortran that I still have cavities in my brain.
I don't remember a lot about Forth, except this. After programming in (8-bit) assembler for about a year, I tried Forth. Getting the -code done- in -so little- time, I grinned broadly as I played Frisbee in that saved time.
There's no way to save time like that any more; the computer's done -before- you finish typing 'run'. (Well, ok, infinite loops aren't any faster, just get -much closer to infinity. I postulate.)
Anyway, those old mags always bring back that sense of WHOA! (I still have Kilobaud #1 and #2.)
which flavor of Forth should I look at if I don't want to deal with the historical page sizes? (not sure of the nomenclature since I last looked at Forth)
In a lot of system code, the performance can be dominated by access to devices that are much slower than cache. In that environment, so long as you are careful about a few CPU intensive routines like memcpy and bitblt, threaded code can be nearly as fast as compiled code, and sometimes faster. And it is much more compact, which matters a lot when you have to fit everything into some flavor of ROM.