3 ms·
SBus peripherals use the Forth language in their PROMs to initialize themselves[1]. [1] https://docs.oracle.com/cd/E19957-01/802-3239-10/sbusandfc.html#11274 h
by chirsz 4mo ago
SBus peripherals use the Forth language in their PROMs to initialize themselves[1].
[1] https://docs.oracle.com/cd/E19957-01/802-3239-10/sbusandfc.html#11274 https://docs.oracle.com/cd/E19957-01/802-3239-10/sbusandfc.h...
- DonHopkins 4mo agoGood call! (Whether it's a directly threaded, indirectly threaded, subroutine threaded, token threaded, Huffman threaded, or string threaded call.) https://en.wikipedia.org/wiki/Threaded_code#Token_threading https://en.wikipedia.org/wiki/Threaded_code#Token_threading Mitch Bradley created OpenFirmware. It started at Sun as OpenBoot (informally "SunForth") on the SPARCstation 1 in 1989, was standardized as IEEE 1275-1994, and was renamed OpenFirmware at that time. Its lineage runs back through Mitch's earlier Forthmacs (Bradley Forthware, early 80s), which ran on 68k Macs, Sun-2/3, Atari ST, and Amiga. Mitch credits Henry Laxen and Michael Perry's F83 and Glen Haydon's MVP-Forth as the public-domain ancestors. The metacompiler can target many platforms, word sizes, CPUs, and threading models, and produce stripped ROMable images. It can build the kernel as direct-threaded (DTC), indirect-threaded (ITC), subroutine-threaded (STC), or token-threaded (TTC), with 16, 32, or 64 bit cells. Shipping kernels are DTC native code with cell-sized xt pointers: 32 bit on the original SPARC and PowerPC machines, 64 bit on modern PPC64, SPARC64, and ARM64 builds. Peripheral expansion cards ship a separate, portable, variable-byte token format called FCode. The kernel interprets FCode at boot/probe time and recompiles it on the fly into the live native dictionary. After probe, FCode-loaded drivers run as ordinary native Forth words. That two-stage design (fast native runtime, portable FCode transport) is what let Sun ship one card PROM image that worked across CPU generations. https://github.com/MitchBradley https://github.com/MitchBradley https://github.com/MitchBradley/openfirmware https://github.com/MitchBradley/openfirmware FCode was designed for SBus on the SPARCstation 1, with cross-CPU portability built in. Sun's earlier and contemporary buses were not interchangeable with SBus (Sun-2 used Multibus, Sun-3 used VMEbus, the Sun386i "Roadrunner" used AT-bus), so the cross-architecture payoff arrived later, when IEEE 1275-1994 standardized OpenFirmware and PCI allowed FCode in option ROMs. After that, the same expansion-card PROM image could boot on Sun SPARC, Apple PowerPC Macs, IBM PowerPC servers (CHRP), and the OLPC XO. Interview with Mitch Bradley (he's like the Woz of Forth): https://web.archive.org/web/20120118132847/http://howsoftwareisbuilt.com/2008/03/27/interview-with-mitch-bradley-firmware-olpc/ https://web.archive.org/web/20120118132847/http://howsoftwar... In parallel with the OpenBoot work, Mitch also developed an extremely portable C-based Forth (the public version is "C Forth 93"). It runs a switch-threaded inner interpreter over packed tokens, with configurable cell width (16, 32, or 64 bit) and configurable token width (pointer-sized by default, 16 bit with the T16 build flag for tight flash budgets), plus a small hand-rolled FFI built around a fixed-arity 12-argument marshalling trampoline driven by a format string. It is now the embedded variant used in OLPC's OpenFirmware and in PlatformIO targets including RP2040, Teensy, ESP32, ESP8266, and STM32: https://github.com/MitchBradley/cforth https://github.com/MitchBradley/cforth OpenFirmware even has its own song: https://www.youtube.com/watch?v=b8Wyvb9GotM https://www.youtube.com/watch?v=b8Wyvb9GotM More on Mitch, OpenFirmware, and CForth: https://news.ycombinator.com/item?id=21822840 https://news.ycombinator.com/item?id=21822840 https://news.ycombinator.com/item?id=33681531 https://news.ycombinator.com/item?id=33681531 https://news.ycombinator.com/item?id=38689282 https://news.ycombinator.com/item?id=38689282
- anthk 4mo agoI ran EForth under the Subleq from Howe R.J at https://github.com/howerj/muxleq https://github.com/howerj/muxleq (the subleq one) first at QuickJS (trivial tasks, almost a 1:1 map from the C code, made in a hurry) and under... jsinterp.py from the infamous yt-dlp but using arrays instead of printing functions. But... if yt-dlp's "mini-JS" implements some captcha input functions... you can add I/O with ease and run EForth with what they call (not me) a "Not totally functional interpreter". Not totally... until people there run the 110 rule program, Conway's Life, Subleq+EForth...
- DonHopkins 4mo agoYou may need to write a WebGPU shader and run it in a Beowulf Cluster to make that run fast!
- anthk 4mo agoI ran EForth under Muxleq (multiplexed subleq) under an n270 Atom (32 bits Intel) and was fast enough. Much slower than GForth or even PFE (which is slow compared to GForth), but usable even to do Algebra exercises. Rendering a Mandelbrot fractal (ASCII) lasted half a minute but it's amazing that few lines of C enable you to run a Forth with input composed of numbers. I even have a backup in paper. https://sites.google.com/view/win32forth/win32forth-readme/mandelbrot-in-6-lines https://sites.google.com/view/win32forth/win32forth-readme/m... I did some syntax changes for floats and that's it.
- actionfromafar 4mo agoPower Macs had an x86 emulator which ran the x86 ROM in PCI cards.
- mjg59 4mo agoI don't think that's true? Macs were running Open Firmware, they had an expectation of the same Forth code that Suns made use of, and several cards needed to be flashed with Apple firmware to be Mac compatible. Alphas definitely ran x86 video card init code under emulation, though.