Chuck wrote... (regarding assembly, not machine language): ------- "typically tied to hardware"? Can anyone cite a case where it was not? ------- Absolutely. The Pick Operating System assembly language. They could not afford a machine when they began development of the OS. So they wrote the entire OS in a "made up" assembly language that didn't really exist on any real machine. This got them two benefits - one, didn't have to buy hardware up front, and two, porting the entire OS to a completely different platform/architecture was a task typically measured in weeks, not months or years. In addition, because it was a "mythical" assembly language, it allowed them to pretend they had hardware instructions that were unusually well suited to manipulating data structures that were unique to the database architecture.
The os was available on around 30 different machines, everything from ibm 4331, IBM RT, PDP11, 68000, X86, etc. On all those it was implemented one of two ways - software implementation or hardware implementation. For the hardware implementation, a firmware board provided the real time translation/lookup of "Pick Instructions" to "native instructions". For the software implementations, the assembly process was more interesting. You'd program in Pick assembly language, then run the pick assembler (written in pick assembler of course). This would produce pick "virtual machine" (in the mythical hardware sense, not todays virtual sense) machine language. Then you'd run a BASIC program (hardware specific) that would translate the pick machine language to the native processor's assembly language. Then you'd run the native (z8000 for example) assembler to create native machine code. That could then be loaded for execution. J
