planckforth: Bootstrapping a Forth interpreter from hand-written tiny ELF binary
github.com
github.com
The story is simply that he started with MS-DOS, some floppy disks, and DEBUG. Starting there, he bootstrapped to being able to boot something from a floppy, and just pushed on from there.
Its an interesting development idea of simply molding a RAM image to your liking with little more than POKE, PEEK, BLOCKMOVE and READ/WRITE the RAM image. The assembler is a tasty treat, but hardly necessary, and perhaps not as helpful as one would like since while the mnemonics are nice, its the labels that give an assembler its real power.
I always visualized putting subroutines at 16 byte boundaries, if only to make the addresses stand out a bit in the hex noise, but also to give a little wiggle room to make changes without stomping on other code. Thinking how cautious one has to be, particularly on an MS-DOS machine, you have to be knowing one misstep, one stuck loop, and you're reloading from disk again. "Save early, save often". Plus that one point when you're in the phase of writing the floppy bootsector and you now, suddenly have a larger step to go from bootable primitive Forth kernel, to one that can self-host, even if it's just defining code words as blocks of hex numbers, forgoing an actual assembler early on. But, ideally, by that point, you're already comfortable with block of hex code, however now you don't have the benefit of a disassembler outside of the carbon based meat computer stuck in your head.
I think after a day or two of full immersion in this environment, disassembling hex code would be mostly straightforward. Woz is said to have 6502 binary memorized. It doesn't really take much, you don't need to memorize it all. Knowing a dozen instructions can take you a long way.
Anyway, always been an interesting thought exercise. Nice to see something similar. I like the primitive base Forth used.
It does. I am certainly no Woz, but I used to program a KIM-1 by hand assembling with pencil and paper from a programming card, then keying hex codes into its onboard keypad. After a few days you don't need to look at the card much. It's really quite practical - it's actually easier than dealing with editor and assembler tools. After fifty years, I still recall that A5 encodes LDA.
In my very modest experience, I once wrote a system that I could boot from a floppy, edit, then recompile. For this I needed to make an assembler, or rather I was willing to meet the challenge of writing an assembler for the 8086, which was notoriously difficult (not really for the subset I needed, which did not include the complex addressing modes for one thing).
When it came to writing the changes on the floppy I was very scared to trash my hard disk (writing to HD or floppy was just a value in a register when you use the BIOS API), but fortunately I found an old Toshiba laptop that had an external power-on switch for the hard disk! That thing was running at 10 Mhz in "turbo" mode!
Bottom line: I spent a lot of times reading the ISA specs, write the assembler in Forth, and compare/check its output with an actual assembler. It would have been more efficient to enter directly the instructions in hex, I think, except maybe for the boot sector.
When ELF was added to Linux, I think it used a bit less RAM than a.out.
ELF made it easier to build and deploy shared libraries, and the design was more consistent at keeping code sections read-only despite run-time linking (the PLT stuff), so more RAM pages ended up automatically shared between processes by the kernel, compared with a.out.