5 ms·

The only API was the machine instruction set, the lower level language was the microcode language used to define machine instructions. For example, the bitblt

The only API was the machine instruction set, the lower level language was the microcode language used to define machine instructions. For example, the bitblt operation used to move graphics around on the screen was a machine instruction implemented in microcode. Ditto for network etc. At boot time, the Alto and later Xerox machines that ran Smalltalk loaded a different microcoded instruction set for each language: Smalltalk, Lisp, Mesa, BCPL ... Then the whole system was written in that language. Details appear in the many papers and reports linked here: http://xeroxalto.computerhistory.org/xerox_alto_file_system_archive.html http://xeroxalto.computerhistory.org/xerox_alto_file_system_... I just noticed that site includes the code, apparently including the microcode, in addition to papers and reports! (I'm not sure if the microcode programs are included in Kay's 10 - 20,000 line estimate.)

alankay1 9y ago
The Alto only had 1024 words (4k bytes) of microcode, so it is included in the estimate. The NoteTaker used several 8086s (the first ones) and was entirely in Smalltalk except for 6k bytes of 8086 code. i.e. "math wins"! ... when coupled into the design of the entire system. And ... we would have loved to have had more microcode!
bsaul 9y ago
Thanks for the info ! I'm still having a hard time understanding how having to ability to program your own "assembly" operation through microcodes could reduce the number of lines for huge programs that drastically. At worst you could still code those operations with the higher level language (smalltalk)... I can imagine how that would make things slower, but that's another issue. Another thing i wonder as someone that hasn't coded in assembly since school : isn't the set of low level instructions required to build most regular programs pretty much settled now ? I'm not talking about high performance or 3D graphics, or AI. Only things personal computers have been doing for the last 30 years. Put it differently: supposing intel gave use the possibility to reprogram a large set of its assembly instruction using microcodes, would the linux codebase be radically smaller ?
- jonjacky 9y ago
  The main reason the Alto and other Xerox PARC machines provided so much functionality with so little code is the designers were quite ruthless about simplification and providing just one best way to do everything, which all programs then had to use. There weren't any huge programs - they didn't need them. Those systems were very unlike Linux or any modern platform. For example Linux plus its typical userland provides perhaps seventeen dozen different ways to put text on a screen. The Alto solved that problem once and for all in microcode, and then all Alto software used that one solution and nothing else. That's where the savings came from: they decided in advance what they needed and then designed the whole techology stack together to provide that in the most parsimoniious way: from the GUI through the programming language and compiler and display hardware and CPU hardware, machine instruction set down to microcode - it was all designed together from a bird's eye view of what the entire finished system was supposed to look like. All done by a small group of people in a short time. It's a completely different process from the decades of accretion in Linux and other modern platforms. To respond to your technical questions about microcode. Microcode (and CISC architectures in general) are motivated by making the compiled binary programs as small as possible - each single machine instruction can do a lot because it runs a lot of microcode. The optimal set of machine instructions isn't settled once and for all, it depends on available technology. The Alto only had 128 kilobytes of RAM, so it was crucial to design an instruction set where compiled programs were as small as possible. So (I recall) their CPU used a stack rather than a lot of registers because then most operands could be implicit - that saves a couple of bytes in a typical instruction. Now that gigabyte memories are commonplace, the design trade-offs are quite different. But I think the microcoded instructions made the programs shorter at the source code level just because they made it unnecessary to re-implement the low level graphics operations (etc.) over and over in system and application code.
- shalabhc 9y ago
  > the linux codebase be radically smaller ? I believe Linux isn't built the same way the Smalltalk system was. One glaring difference is the use of C - with that you can't get very high level and are always programming at a very low level. You also force all integrations to be at a very low leve, given how the ABI and syscalls work. You can do quite a bit more if you use a higher level language with very good meta programming, for instance Lisp or Smalltalk. E.g., you could imagine very high level abstractions that get translated to lower level logic automatically. Unfortunately, this is not an area that has been extensively adopted IMO, and the mainstream thinking is we need to use lower level languages for operating systems and such. > supposing intel gave use the possibility to reprogram a large set of its assembly instruction using microcodes Actually Alan Kay has been critical of Intel not doing this. It may not affect Linux much but it will definitely open the door for systems using more advanced techniques, specifically the ability to build high level emulators. See https://news.ycombinator.com/item?id=15282739 https://news.ycombinator.com/item?id=15282739 for more.

alankay1 9y ago

The Alto only had 1024 words (4k bytes) of microcode, so it is included in the estimate. The NoteTaker used several 8086s (the first ones) and was entirely in Smalltalk except for 6k bytes of 8086 code. i.e. "math wins"! ... when coupled into the design of the entire system. And ... we would have loved to have had more microcode!

bsaul 9y ago

Thanks for the info ! I'm still having a hard time understanding how having to ability to program your own "assembly" operation through microcodes could reduce the number of lines for huge programs that drastically. At worst you could still code those operations with the higher level language (smalltalk)... I can imagine how that would make things slower, but that's another issue. Another thing i wonder as someone that hasn't coded in assembly since school : isn't the set of low level instructions required to build most regular programs pretty much settled now ? I'm not talking about high performance or 3D graphics, or AI. Only things personal computers have been doing for the last 30 years. Put it differently: supposing intel gave use the possibility to reprogram a large set of its assembly instruction using microcodes, would the linux codebase be radically smaller ?

jonjacky 9y ago
The main reason the Alto and other Xerox PARC machines provided so much functionality with so little code is the designers were quite ruthless about simplification and providing just one best way to do everything, which all programs then had to use. There weren't any huge programs - they didn't need them. Those systems were very unlike Linux or any modern platform. For example Linux plus its typical userland provides perhaps seventeen dozen different ways to put text on a screen. The Alto solved that problem once and for all in microcode, and then all Alto software used that one solution and nothing else. That's where the savings came from: they decided in advance what they needed and then designed the whole techology stack together to provide that in the most parsimoniious way: from the GUI through the programming language and compiler and display hardware and CPU hardware, machine instruction set down to microcode - it was all designed together from a bird's eye view of what the entire finished system was supposed to look like. All done by a small group of people in a short time. It's a completely different process from the decades of accretion in Linux and other modern platforms. To respond to your technical questions about microcode. Microcode (and CISC architectures in general) are motivated by making the compiled binary programs as small as possible - each single machine instruction can do a lot because it runs a lot of microcode. The optimal set of machine instructions isn't settled once and for all, it depends on available technology. The Alto only had 128 kilobytes of RAM, so it was crucial to design an instruction set where compiled programs were as small as possible. So (I recall) their CPU used a stack rather than a lot of registers because then most operands could be implicit - that saves a couple of bytes in a typical instruction. Now that gigabyte memories are commonplace, the design trade-offs are quite different. But I think the microcoded instructions made the programs shorter at the source code level just because they made it unnecessary to re-implement the low level graphics operations (etc.) over and over in system and application code.
shalabhc 9y ago
> the linux codebase be radically smaller ? I believe Linux isn't built the same way the Smalltalk system was. One glaring difference is the use of C - with that you can't get very high level and are always programming at a very low level. You also force all integrations to be at a very low leve, given how the ABI and syscalls work. You can do quite a bit more if you use a higher level language with very good meta programming, for instance Lisp or Smalltalk. E.g., you could imagine very high level abstractions that get translated to lower level logic automatically. Unfortunately, this is not an area that has been extensively adopted IMO, and the mainstream thinking is we need to use lower level languages for operating systems and such. > supposing intel gave use the possibility to reprogram a large set of its assembly instruction using microcodes Actually Alan Kay has been critical of Intel not doing this. It may not affect Linux much but it will definitely open the door for systems using more advanced techniques, specifically the ability to build high level emulators. See https://news.ycombinator.com/item?id=15282739 https://news.ycombinator.com/item?id=15282739 for more.