←back to thread

122 points rickcarlino | 1 comments | | HN request time: 0.202s | source
Show context
throw0101c ◴[] No.45656104[source]
Ah, Forth-as-BIOS. Memories of Sun SPARC (and Apple PowerPC):

* https://en.wikipedia.org/wiki/Open_Firmware

* https://apple.fandom.com/wiki/Open_Firmware

replies(2): >>45656603 #>>45657848 #
DonHopkins ◴[] No.45657848[source]
When Mitch Bradley put OpenFirmware on the OLPC (One Laptop Per Child), he implemented this easter egg:

>You may be amused to know that the firmware has an Easter Egg of the Conway's Life. If you press the rocker pad (left side of screen) to the right after powering on, you will get a randomly-select amusement, one of which is Life. It uses the traditional life-death rule with a wrap-around field, and initial conditions that result in a fairly long number of generations before steady-state. Specificially, the initial state is a glider gun and an R-pentomino. The pentomino evolution eventually wrecks the gun, but things get pretty wild for awhile as gliders wrap around and interact with the debris from the pentomino. It almost stabilizes several times, but then something will set off another burst of activity for awhile before it finally dies out.

https://news.ycombinator.com/item?id=21049568

DonHopkins on Sept 23, 2019 | parent | context | favorite | on: OLPC’s $100 laptop was going to change the world (...

That's Mitch Bradley's Open Firmware Forth, which was also on Suns, post-NuBus PowerPC Macs, Pegasos, and IBM Power Systems!

I used to call it "L1-A Forth", because that's the Forth you got when you pressed "L1-A" on a Sun keyboard to get into the boot monitor. He also made a great version of that Forth system with a metacompiler that ran under Unix (Forthmacs), which I used a lot.

https://github.com/MitchBradley

https://github.com/MitchBradley/openfirmware

https://en.wikipedia.org/wiki/Open_Firmware

https://web.archive.org/web/20121119070656/https://elinux.or...

http://macos9lives.com/smforum/index.php?topic=1965.0

https://github.com/ForthHub/ForthFreak/blob/master/Forthmacs

Also:

https://news.ycombinator.com/item?id=38689282

>Mitch Bradley came up with a nice way to refactor the Forth compiler/interpreter and control structures, so that you could use them immediately at top level! Traditional FORTHs only let you use IF, DO, WHILE, etc in : definitions, but they work fine at top level in Mitch's Forths (including CForth and Open Firmware).

More about Mitch and OpenFirmware:

https://news.ycombinator.com/item?id=29261810

https://web.archive.org/web/20090920123423/http://radian.org...

>And lest you think this is some kind of Apple-paid rant, I'll mention Mitch Bradley. Have you read the story of Mel, the "real" programmer? Mitch is that guy, in 2008. Firmware superhacker, author of the IEEE Open Firmware standard, wrote the firmware that Sun shipped on its machines for a good couple of decades, and in general one of the few people I've ever had the pleasure of working with whose technical competence so inordinately exceeds mine that I feel I wouldn't even know how to start catching up. Mitch's primary laptop runs Windows.

replies(1): >>45662900 #
kragen ◴[] No.45662900[source]
How do if, do, and while work at top level in Mitch's Forths? I've been thinking about different ways to achieve that.
replies(1): >>45665329 #
DonHopkins ◴[] No.45665329[source]
The magic is +LEVEL and -LEVEL (instead of FIG-FORTH's traditional STATE), which when you start a top level loop or conditional it transitions from level 0 to 1, and switches the outer interpreter into temporary compilation mode that compiles headerless code into into a compile-buffer, then when you -LEVEL back to zero it executes the code you just compiled, without it actually being part of a permanent word.

So your temporary top level code is out of the way of HERE and can compile permanent stuff into the dictionary or whatever it needs to do. Then you can do stuff like "10 0 do i , loop" and the numbers you're ,'ing won't get mixed up with the code of the loop that's ,'ing them.

This post has a bunch of links to the OpenFirmware metacompiler's implementation and also the CForth implementation:

https://news.ycombinator.com/item?id=38689282

Here are the control structures in kernel.fth (this is some beautiful FORTH code to read for pleasure):

kernel.fth: https://github.com/MitchBradley/openfirmware/blob/master/for...

Here is the same approach in CForth, the low level C kernel code (necessarily ugly C macrology) and the higher level FORTH control structure definitions (more beautiful FORTH code):

forth.c: https://github.com/MitchBradley/cforth/blob/master/src/cfort...

control.fth: https://github.com/MitchBradley/cforth/blob/master/src/cfort...

Here is another paper about refactoring the FORTH compiler/interpreter with deferred words that Mitch wrote called "Yet Another Interpreter Organization":

https://groups.google.com/g/comp.lang.forth/c/lKQjcJL_o54/m/...

>There has been a mild controversy in the Forth community about how to implement the text interpreter. The particular problem is how the distinction between compiling and interpreting should be coded. At least three distinct solutions have been advocated over the years. I propose a fourth one, and claim that it is the best solution yet.

[describes FIG-FORTH's solution with STATE, PolyForth's solution with two separate loops for compiling and interpreting, Bob Berkey's coroutines approach]

>What is Wrong with all this

>These different schemes do not at all address what I consider to be the fundamental problems with the interpreter/compiler.

>Fundamental Problem #1:

>The compiler/interpreter has a built-in infinite loop. This means that you can't tell it to just compile one word; once you start it, off it goes, and it won't stop until it gets to the end of the line or screen.

>Fundamental Problem #2:

>The reading of the next word from the input stream is buried inside this loop. This means that you can't hand a string representing a word to the interpreter/compiler and have it interpret or compile it for you.

>Fundamental Problem #3:

>The behavior of the interpreter/compiler is hard to change because all the behavior is hard-wired into one or two relatively large words. Changing this behavior can be extremely useful for a number of applications, for example meta-compiling.

>Fundamental Problem #4:

>If the interpreter/compiler can't figure out what to do with a word (it's not defined and it's not a number), it aborts. Worse yet, the aborting is not done directly from within the loop, but inside NUMBER. This severly limits the usefulness of NUMBER because if the string that NUMBER gets is not recognizable as a number, it will abort on you. (The 83 standard punts this issue by not specifying NUMBER, except as an uncontrolled reference word).

[describes Mitch's solution of making DO-DEFINED, DO-LITERAL, and DO-UNDEFINED a deferred word]

>So what?

>This may seem to be more complicated than the schemes it replaces. It certainly does have more words. On the other hand, each word is individually easy to understand, and each word does a very specific job, in contrast to the old style, which bundles up a lot of different things in one big word. The more explicit factoring gives you a great deal of control over the interpreter.

[describes cool examples of what you can do with it]

>Finally, a really neat way to write keyword-driven translators. Suppose you have some kind of a file that contains a bunch of text. Interspersed throughout the text are keywords that you would like to recognize, and the program should do something special when it sees a keyword. For things that aren't keywords, it just writes them out unchanged. Suppose that the keywords are ".PARAGRAPH", ".SECTION", and ".END". [...]

>I have used this technique very successfully to extract specific information from data base files produced by a CAD system. Instead of outputting unrecognized words, I actually just ignored them in this application, but the technique is the same in either case.

  Mitch Bradley
  Bradley Forthware
  P.O. Box 4444
  Mountain View, CA 94040
  wmb@forthware.com
Mitch had the coolest P.O. Box address for his Forthware company in Mountain View!

This deferred word approach is actually what I used for the HyperTIES markup language interpreter/formatter for NeWS I wrote in Forth and C and PostScript, using Mitch's Sun Forth / Forthmacs (predecessor to OpenFirmware that ran on the Sun):

https://donhopkins.com/home/ties/doc/formatter.st0

https://donhopkins.com/home/ties/fmt.f

https://donhopkins.com/home/ties/fmt.c

https://donhopkins.com/home/ties/fmt.cps

https://donhopkins.com/home/ties/fmt.ps

replies(1): >>45667021 #
1. kragen ◴[] No.45667021[source]
Thanks, this is great! Too bad Google Groups has grayed out the "Show original message" link, but maybe I can puzzle out enough of the formatting through Google's mangling.