Allow me to express my gratitude by not enumerating the memory
limitations and other resource constraints of the various devices I
had the dubious pleasure to program (1K FOR THE ARGUMENTS? THAT'S ONE
SHITLOAD OF WASTED MEMORY!).
No shit. When they upgraded Cory to V7 my file browser on the PDP-11
had to start writing that to disk so I could use the extra 1k of space
for my screen buffer for my curses workalike (curses was too wasteful
to fit), and when I wanted to run a program I'd re-read it after
fork()ing so the environment would be available for the child process.
God that was hateful.
The guys who managed to fit a RSTS system call emulator into the first
512 bytes of a RSTS core image since that was always available as the
default stack so they could run RSTS Basic+ under Version 7 and retire
the lasts RSTS box on the Berkeley campus were Gods.
Then when I started working at Hydril and found I was sharing a machine
with 4K of RAM and 12K of ROM with two other people... at least
Polyforth on the 1802 was direct-threaded and had a fixed NFA and could
run headerless. That saved a good 5-10 bytes per defined word,
especially since you could keep register 12 pointing at the inner
interpreter so instead of having to start them with "JSR DOCOL" (3
bytes) you could start them with "SEP C" (1 byte).
The 1802 was so wonderfully TIGHT as a Forth box you could forget it
ran at about half a megahertz.
Headerless code was pretty hateful to debug, though.
Forth on the PDP-11 was kinda cool, since you could inline DOCOL and
SEMIS as single instructions, kinda, if you assembled "JSR IP,xxxx" and
then overwrote the "xxxx" with the first word of the threaded
definition. For all its fancy instruction modes the VAX was never a
great Forth target. In fact the VAX was pretty hateful. PDP-11
outlasted that slug and its virtual performance.
Hey, you know, thinking about that RSTS Basic+ hack... I'll bet there's
at least 1K of wasted crap loaded into RAM between _start and main() on
any statically linked executable. Even in a.out on the PDP-11 you could
probably have fit the code to implement reading argv[][] from $ARGVFD
in the padding after the a.out header... and in elf, my god, If you
crushed the dwarf you wouldn't even need pliers, and if you passed the
length of the argv[][] you could allocate all the core you'd need in
one trip through setbrk()...
Surely that's not hateful...
