Live data from Hacker News

How to fit a large program into a small machine (1980)

mud.co.uk

21–30 of 43 posts

Re: How to fit a large program into a small machine (1980)

#21
the answer is to encode your program using a higher-level machine code targeting a portable virtual machine.

that’s also how they managed to fit all the software of the Apollo guidance computer into it.

> “The AGC had a sophisticated software interpreter, developed by the MIT Instrumentation Laboratory, that implemented a virtual machine with more complex and capable pseudo-instructions than the native AGC.” (https://en.wikipedia.org/wiki/Apollo_Guidance_Computer#softw...)

Re: How to fit a large program into a small machine (1980)

#22

Does anyone know of any good books which describe the design and implementation of small VMs/interpreters like these?

I think it isn't a constrained enough topic to write a textbook on. The conclusion section of the article under discussion summarizes the technique pretty well.

I have encountered brief discussions of the technique in a few places though. Jon Bentley wrote a column called Programming Pearls, collected in a couple of compilation books, and one of those was called Squeezing Space which talked about this a bit. I think that Peter Norvig had a chapter on it in Paradigms of Artificial Intelligence Programming but couldn't swear to it. I've also read that KDB+ uses this technique, and I seem to remember that one of the few columns that discussed implementation (it's proprietary technology, so there's not much on it) talked about stuff like this.

The general idea was also briefly discussed in Dynamic Languages Wizards Series - Panel on Runtime (from 2001), though they didn't go into methods, just trade-offs [1]

[1] https://www.youtube.com/watch?v=4LG-RtcSYUQ

Re: How to fit a large program into a small machine (1980)

#23

An instance of compiling the program to a bespoke bytecode and then interpreting the bytecode. This is one of my favourite programming tricks - high effort and high effectiveness, rarely used. Dwarf does this as one of the size optimisation tricks. I used to know another example but it isn't coming to mind.

Too bad ROM was expensive those days. If a language with a nice balance between expressiveness and performance (say Lisp, Forth, Pascal, maybe Lua or even Java) had been embedded in the machine's ROM, then many programs could contain just their core functionality. While having all the machine's capabilities easily accessible (and maybe some standard library of often-used functions).

As opposed to containing implementations of various interpreters, VMs etc, as described here (and functions that 100s of other programs implemented as well).

Or even better: a selection of languages, letting programmers pick or even mix & match for various parts of the program.

Even today "big ROM, small RAM" is common (eg. in uC's). With flash offering extra flexibility for the 'ROM' part.

But the limitations of the day made many (system) ROMs little more than a glorified boatloader + some low level I/O code. If you were lucky, with an easy to learn but slow language like (interpreted!) BASIC.

Re: How to fit a large program into a small machine (1980)

#27

An instance of compiling the program to a bespoke bytecode and then interpreting the bytecode. This is one of my favourite programming tricks - high effort and high effectiveness, rarely used. Dwarf does this as one of the size optimisation tricks. I used to know another example but it isn't coming to mind.

Too bad ROM was expensive those days. If a language with a nice balance between expressiveness and performance (say Lisp, Forth, Pascal, maybe Lua or even Java) had been embedded in the machine's ROM, then many programs could contain just their core functionality. While having all the machine's capabilities easily accessible (and maybe some standard library of often-used functions). As opposed to containing implement…

There's an interesting design point in high wattage processors. If your bytecode interpreter fits comfortably in the L1 cache, and the bytecode is denser than machine code, and the program doesn't fit in the caches, then there's potential for interpreted bytecode to outperform native code. Quirk of really fast compute paired with moderately fast memory. I can see that working particularly well if one interpreter instance executes code for multiple processes.

Re: How to fit a large program into a small machine (1980)

#28
post #6

I've always been fascinated by Zork despite coming of age decades after its release. Reminded of it a few years back through The Digital Antiquarian, I wrote a C# implementation of the Z-Machine ( https://github.com/raegwolf/zmachine ). Seeing how so much could be achieved with so little memory was eye opening.

I love Zork because I started learning English on it (forest being one of the first words, never could find "stiletto" in any dictionary I had!). At the same time we were all pirating punks in middle school who loved skipping copy protection or boosting stats in assembler, and Zork was one of the only games who completely baffled me, which I now know is because of the interpreter. Good times.

Re: How to fit a large program into a small machine (1980)

#29

the answer is to encode your program using a higher-level machine code targeting a portable virtual machine. that’s also how they managed to fit all the software of the Apollo guidance computer into it. > “The AGC had a sophisticated software interpreter, developed by the MIT Instrumentation Laboratory, that implemented a virtual machine with more complex and capable pseudo-instructions than the native AGC.” ( https:…

You probably know this, but to be clear for anyone else reading - the AGC's code was written in a mix of interpreted code and native code. Writing in native AGC assembly was necessary for the most performance-sensitive parts of the flight, such as during the LM's landing.

Re: How to fit a large program into a small machine (1980)

#30
It's mentioned briefly, but another big advantage of the Z-machine was being mostly hardware-independent, which was especially important with the wide variety of computers in the early 80's. The Digital Antiquarian says that Infocom supported over 20 different platforms at its height. [1]

[1] https://www.filfre.net/2013/03/the-top-of-its-game/

Post reply on HN