: OpenFirmwareSong ( - ♬ )
\ By Mitch Bradley.
\ Sung to the tune of "The Flintstones".
𝄞
." Firmware" cr
." Open Firmware" cr
." It's the appropriate technology," cr
." Features" cr
." FCode booting" cr
." Hierarchical DevInfo tree." cr
." Hack Forth" cr
." Using Emacs on the keys," cr
." Save in" cr
." NVRAM if you please." cr
𝄒 cr
." With your" cr
." Open Firmware" cr
." You can fix the bugs in no time" cr
." Bring the kernel up in no time" cr
." We'll have an FCode time!" cr
𝄒 cr
\ Thank you and good night!
reboot
;
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.
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.
>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).
>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.
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:
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):
Here is another paper about refactoring the FORTH compiler/interpreter with deferred words that Mitch wrote called "Yet Another Interpreter Organization":
>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 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):
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.
Ilo/Konilo is pretty cool, but I already knew that. What I didn't know about was qemu-system -nographic.
Any idea why crc is specifying a custom BIOS image? QEMU comes with a default one, right? Questions like these make me wish asciinema supported recording voiceovers.
I'm guessing that the slow text screen updates are some kind of an artifact of unoptimized UEFI implementation, and/or QEMU, because I'm pretty sure Konilo is a lot snappier than this running under Linux, even though the Ilo implementation is not a highly optimized virtual machine.
I'm not well versed in qemu's various options. When I didn't specify a BIOS image, it seems to be using SeaBIOS, not UEFI, and hangs on "Booting from Hard Disk...". I should be able to start doing proper videos soon; I've been slowly working towards that.
I can say that the display & overall performance is noticeably faster on the two actual computers I tested on than under qemu on my Linux system.
This is a minor pet peeve of mine, actually. I would understand if qemu defaulted to BIOS booting, though I'd prefer that it try UEFI then fall back to BIOS/CSM at this point, but it's actively difficult to do UEFI on qemu; you have to actively feed it the ROM by path, and last I tried you had to include a -pflash for writable storage even if you weren't doing anything with it (thankfully this appears to have been fixed). I really wish they just let you do something like -boot-firmware=uefi,bios or such. (And again, in 2025 I really think UEFI should just be the default, with fallback to CSM/BIOS for backwards compat)
The countervailing force here is the desire for command line backwards compatibility. Every time you change a default to be something that makes more sense today, you break the existing working setups of some unknown number of people...
The approach the project has settled on is to say that providing user friendly defaults should be the job of a "management layer" piece of software like libvirt, and QEMU proper should concentrate on providing flexible and orthogonal options which that other software can use to tell it what to do.
Does qemu make an effort to preserve backwards compatibility with its cli? Because I have distinct memories of getting caught by them changing the way multiple parts of their command line work.
But in this case, my suggestions should be fairly backwards compatible; retaining the default of BIOS but adding a simple `--firmware uefi` option would change nothing for existing users, and even defaulting to `--firmware uefi,bios` should be mostly compatible since it just tries UEFI and then promptly falls back to BIOS.
Yeah, we do try to maintain at least some back compat. Some things go through a deprecate-and-drop cycle, but that is more often driven by "the old thing is a pain to maintain internally" than by "the new thing is more user friendly".
New top level command line options are rare these days, and magic "do what I mean" options also rare: we tend to prefer "tell us specifically what you want".
Maybe we should have new command names with defaults that are reasonable this decade, keeping qemu-system-i386 and the like for backwards compatibility?
Like apt vs apt-get? Yeah, I could potentially go for that. Although in the case of qemu I'm not entirely convinced that we need to go that far because I think it would only take small tweaks to make the existing tool friendlier.
There are actually two similar options, one is -nographic, which simply shows the serial terminal, and the other is -display curses, which will show the VGA text mode console on the terminal.
I suspect that for my purposes both of them will be useful. Thank you! I should go back and read the QEMU man page; groff -man -Tpdf <(gzip -dc /usr/share/man/man1/qemu-system.1.gz) generates a PDF of only 68 pages.
With this, I wasn't seeing any output with -display curses. It does work with -nographic or using a vnc connection to qemu's display, as well as on the two physical machines I currently have access to.
A Forth-like command-line shell (bash replacement) does sound quite interesting actually, particularly if the stack is displayed on the side and is not implicit.
It's rather concise, most functions tend to be a single short line. Its syntax is minimal (or non-existent according to some), it's just flat white-space separated tokens. It has imperative/interactive semantics, in the sense that every successive word makes some changes on the current state (the stack).
All of this makes it quite amenable to be used as an OS shell I think, it seems obvious in retrospect.
The idea of starting with an empty Forth and creating a whole universe of automations and DSLs for your system, one command at a time, is quite pleasing, in a purist sense, although perhaps not entirely practical.
Does such a shell exist? Not as minimal as Ilo, one you can actually use in a modern system instead of bash and the like, ideally with a nice display of the stack. Probably Factor is the most appropriate Forth-like to build it on, it already has a good REPL mode, it would mainly involve adding a bunch of utilities for practical command-line use.
For RetroForth, I have a new interface under development that may be somewhat like this. A screenshot can be seen at https://imgur.com/a/z4jhq6e
I use RetroForth as a working environment on Unix [mostly OpenBSD & FreeBSD], with an (unreleased) userland written in it, along with some use of external standard utilities. I'm still working on improvements around chaining programs via a pipe-like structure, but it's been my main environment apart from Konilo for a few years now.
Your sidebar reminds me of the computer I learned to program on. A TRS-80 Model III.
I went through a short period of figuring out interesting peek/poke memory addresses for modifying the BASIC system, and found the "80" used as the scroll width. Setting that to 60 allowed me to create a non-scrolling status sidebar like that for my first programs/games.
It strikes me that it would have been great to have had a Forth machine back then. That early version of BASIC didn't have a (language accessible) stack! Not even a return address stack, aka GOSUB. So I used strings as a stack to implement a small text adventure parser. (And later, on a computer with graphics pixels, I used BASIC strings as a heap for defining and drawing simple 3D vector objects.) Then I learned Pascal.
Desperate times. Desperate measures. But Forth would have been great.
One of the most useful ways to use Forth is as a command-line shell for scripting assembly-language primitives on a small computer, like, 64KiB of RAM or less. (Ilo has 64KiB of RAM, IIRC.)
64kW of RAM @ a 4 byte (32-bit) word size, so 256KiB of actual RAM for the applications running on ilo.
For a reference, the 8088 build needs a bit more than that to account for stacks, the VM code, drivers, and memory needed for the actual hardware. (Around 384KiB physical RAM on an 8088/8086 works well from my testing, but I've tested with 285-320KiB in non-standard configurations under a few emulation targets).
Honestly I've experimented with doing something basically like this doing a bunch of modifications to zforth and using it on RP2040 and RP2350 and it actually works really nicely. It's amazing the functionality you can fit down onto those MCUs basically building an old school computer with a Forth interface like the Canon Cat was.
That was my immediate thought: it's a Forth that runs inside an ILO controller? Weird, but OK, I can see that could have some intriguing potential applications...
BMC - vendor neutral
RedFish - Current DMTF standard replacing IPMI
ALOM - sometimes encountered in the wild as part of iLO :O
HMC - IBM on non-x86 systems (except OpenPower), not compatible with anything else
RSA - used to be IBM
IMC - Cisco
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
No reference in those articles to the open firmware song? Pity...
https://www.youtube.com/watch?v=b8Wyvb9GotM
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.
How do if, do, and while work at top level in Mitch's Forths? I've been thinking about different ways to achieve that.
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 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
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.
Ilo/Konilo is pretty cool, but I already knew that. What I didn't know about was qemu-system -nographic.
Any idea why crc is specifying a custom BIOS image? QEMU comes with a default one, right? Questions like these make me wish asciinema supported recording voiceovers.
I'm guessing that the slow text screen updates are some kind of an artifact of unoptimized UEFI implementation, and/or QEMU, because I'm pretty sure Konilo is a lot snappier than this running under Linux, even though the Ilo implementation is not a highly optimized virtual machine.
I'm not well versed in qemu's various options. When I didn't specify a BIOS image, it seems to be using SeaBIOS, not UEFI, and hangs on "Booting from Hard Disk...". I should be able to start doing proper videos soon; I've been slowly working towards that.
I can say that the display & overall performance is noticeably faster on the two actual computers I tested on than under qemu on my Linux system.
> I can say that the display & overall performance is noticeably faster on the two actual computers I tested on than under qemu on my Linux system.
You'd probably want to use `-enable-kvm` so it's not doing full software emulation. Assuming you're running this on another x86-64 machine.
Thanks; I'll start doing that when running on Linux. (I had missed this, as my main dev box is running OpenBSD which doesn't have kvm)
I'm surprised to see that tcg (TCG, the tiny code generator, the original QEMU) is still the default accel, even when KVM could be used instead.
you probably should set the serial port speed
Oh, I didn't realize -nographic was using a serial port. That's probably why it's slow!
It may default to 9600... tons of devices will fall back to that, given no other instruction
Yeah, that was my inference. It looked like about 9600.
Thanks!
It makes sense that it would default to using SeaBIOS; QEMU has a lot of options whose defaults were more reasonable 20 years ago.
This is a minor pet peeve of mine, actually. I would understand if qemu defaulted to BIOS booting, though I'd prefer that it try UEFI then fall back to BIOS/CSM at this point, but it's actively difficult to do UEFI on qemu; you have to actively feed it the ROM by path, and last I tried you had to include a -pflash for writable storage even if you weren't doing anything with it (thankfully this appears to have been fixed). I really wish they just let you do something like -boot-firmware=uefi,bios or such. (And again, in 2025 I really think UEFI should just be the default, with fallback to CSM/BIOS for backwards compat)
The countervailing force here is the desire for command line backwards compatibility. Every time you change a default to be something that makes more sense today, you break the existing working setups of some unknown number of people...
The approach the project has settled on is to say that providing user friendly defaults should be the job of a "management layer" piece of software like libvirt, and QEMU proper should concentrate on providing flexible and orthogonal options which that other software can use to tell it what to do.
Does qemu make an effort to preserve backwards compatibility with its cli? Because I have distinct memories of getting caught by them changing the way multiple parts of their command line work.
But in this case, my suggestions should be fairly backwards compatible; retaining the default of BIOS but adding a simple `--firmware uefi` option would change nothing for existing users, and even defaulting to `--firmware uefi,bios` should be mostly compatible since it just tries UEFI and then promptly falls back to BIOS.
Yeah, we do try to maintain at least some back compat. Some things go through a deprecate-and-drop cycle, but that is more often driven by "the old thing is a pain to maintain internally" than by "the new thing is more user friendly".
New top level command line options are rare these days, and magic "do what I mean" options also rare: we tend to prefer "tell us specifically what you want".
Pretty sure they do, but I agree that adding `--firmware uefi` would be fine.
Maybe we should have new command names with defaults that are reasonable this decade, keeping qemu-system-i386 and the like for backwards compatibility?
Like apt vs apt-get? Yeah, I could potentially go for that. Although in the case of qemu I'm not entirely convinced that we need to go that far because I think it would only take small tweaks to make the existing tool friendlier.
Yeah, exactly.
I don't think you can make those small tweaks without breaking tens of thousands of users' production setups which depend on those defaults.
There are actually two similar options, one is -nographic, which simply shows the serial terminal, and the other is -display curses, which will show the VGA text mode console on the terminal.
I suspect that for my purposes both of them will be useful. Thank you! I should go back and read the QEMU man page; groff -man -Tpdf <(gzip -dc /usr/share/man/man1/qemu-system.1.gz) generates a PDF of only 68 pages.
With this, I wasn't seeing any output with -display curses. It does work with -nographic or using a vnc connection to qemu's display, as well as on the two physical machines I currently have access to.
That would probably be because it is using UEFI text mode rather than VGA text mode.
A Forth-like command-line shell (bash replacement) does sound quite interesting actually, particularly if the stack is displayed on the side and is not implicit.
It's rather concise, most functions tend to be a single short line. Its syntax is minimal (or non-existent according to some), it's just flat white-space separated tokens. It has imperative/interactive semantics, in the sense that every successive word makes some changes on the current state (the stack).
All of this makes it quite amenable to be used as an OS shell I think, it seems obvious in retrospect.
The idea of starting with an empty Forth and creating a whole universe of automations and DSLs for your system, one command at a time, is quite pleasing, in a purist sense, although perhaps not entirely practical.
Does such a shell exist? Not as minimal as Ilo, one you can actually use in a modern system instead of bash and the like, ideally with a nice display of the stack. Probably Factor is the most appropriate Forth-like to build it on, it already has a good REPL mode, it would mainly involve adding a bunch of utilities for practical command-line use.
For RetroForth, I have a new interface under development that may be somewhat like this. A screenshot can be seen at https://imgur.com/a/z4jhq6e
I use RetroForth as a working environment on Unix [mostly OpenBSD & FreeBSD], with an (unreleased) userland written in it, along with some use of external standard utilities. I'm still working on improvements around chaining programs via a pipe-like structure, but it's been my main environment apart from Konilo for a few years now.
Your sidebar reminds me of the computer I learned to program on. A TRS-80 Model III.
I went through a short period of figuring out interesting peek/poke memory addresses for modifying the BASIC system, and found the "80" used as the scroll width. Setting that to 60 allowed me to create a non-scrolling status sidebar like that for my first programs/games.
It strikes me that it would have been great to have had a Forth machine back then. That early version of BASIC didn't have a (language accessible) stack! Not even a return address stack, aka GOSUB. So I used strings as a stack to implement a small text adventure parser. (And later, on a computer with graphics pixels, I used BASIC strings as a heap for defining and drawing simple 3D vector objects.) Then I learned Pascal.
Desperate times. Desperate measures. But Forth would have been great.
The BBC Micro had / has a ROM so you can boot straight into it.
https://www.acornelectron.co.uk/info/electron/acornsoft_adde...
I still have mine
There was also the Jupiter Ace[1], which was sorta a Sinclair ZX with Forth in ROM.
[1] https://www.jupiter-ace.co.uk/
These are not developed to that point, really, but you might be interested in dt and mshell.
https://github.com/so-dang-cool/dt
https://github.com/mitchpaulus/mshell
One of the most useful ways to use Forth is as a command-line shell for scripting assembly-language primitives on a small computer, like, 64KiB of RAM or less. (Ilo has 64KiB of RAM, IIRC.)
64kW of RAM @ a 4 byte (32-bit) word size, so 256KiB of actual RAM for the applications running on ilo.
For a reference, the 8088 build needs a bit more than that to account for stacks, the VM code, drivers, and memory needed for the actual hardware. (Around 384KiB physical RAM on an 8088/8086 works well from my testing, but I've tested with 285-320KiB in non-standard configurations under a few emulation targets).
Sorry! I appreciate the correction. I forgot that it was word-oriented.
During the 8 bit home computer days Jupiter Ace, and ROM replacements for ZX Spectrum.
Honestly I've experimented with doing something basically like this doing a bunch of modifications to zforth and using it on RP2040 and RP2350 and it actually works really nicely. It's amazing the functionality you can fit down onto those MCUs basically building an old school computer with a Forth interface like the Canon Cat was.
the name "ILO" clashes with "Integrated Lights-Out" management as used by (or was used by) some server hardware vendors.
That was my immediate thought: it's a Forth that runs inside an ILO controller? Weird, but OK, I can see that could have some intriguing potential applications...
XSCF - Fujitsu/Oracle SPARC
(I wonder how they got that acronym)
Possibly eXtended System Control Facility.
It looks like they generated random four-letter combinations until they found one that wasn't used.
Ooo also, there is the RMC in some HP Alphaservers
eXtended System Configuration Facility?
I wasn't aware of the clash when I chose the name, unfortunately.
Immediately reminded of the PowerPC bootloader on Macs: https://news.ycombinator.com/item?id=9844026