Linux without the GNU toolchain 5101

Tauno Voipio

I did a similar thing. The computer already existed, but the vendor provided no OS. A friend wrote an "OS" that could read and write tracks to a disk drive. This took 256 words, IIRC. The hardware had a button that would read a paper tape into low memory, but that was about it.

I wrote an OS for it that took about 4096 words of RAM, leaving about 12000 words for applications. It is kind-of tough to write a useful OS in such a small space, but since we were not multiprogramming, had only one main processor (and two DMA-like devices something like primitive SCSI controllers), it could be done.

We did have an buttembler which I used to bootstrap everything. It produced absolute code by default, so I had to make it produce relocatable code. Even the OS kernel was relocatable except for the interrupt vectors in low memory.

We also had a FORTRAN compiler that generated code incompatible with the buttembler. The buttembler and the compiler arranged COMMON storage in opposite orders.

So I had to write the OS, and rewrite the buttembler and compiler. The hardware was more than just running a computer. The computer was actually the controller for some real-time moving picture hardware so we could study improved coding schemes for real-time ("Picturephone") television transmission systems. Keeping that stuff synchronized and running was tricky because unlike most equipment, you cannot tell a camera to wait while you make a disk drive seek to the next cylinder. We needed constructs, in addition to read(), write(), in UNIXLinux terminology such as startread() and startwrite() which returned as soon as the command was queueed to the list of commands to the devices and the application would not be suspended until the operation was completed. We could call other functions to determine if the specified buffer had been filled or emptied. UNIX was especially bad at this kind of thing, and AFAIK, it still cannot do this unless you write custom drivers and ioctl() entries. We had to be able to send data from one device to another without running it through the main memory, because main memory was too small and too slow. You could only get 32K words on machines in those days, although when the PDP-11-45 came out, you could go up to almost 128K bytes, but no one process could see them all.

Not far at all. ;-)

Easier said than done, if you want that buttembly source to be any good. I do not know how gcc does it, but most modern compilers compile straight to binary code and do not actually run an buttembler. When I worked at Bell Labs, the compiler could be made to put out buttembly level code, and our optimizer read that, optimized it at buttembler level, and then invoked the buttembler, link-editor, and loader as required. One nice feature of that was that if the optimizer noticed it was in trouble, it would just exit and pbutt the compiler stuff straight to the buttembler with an error message of course. I do not think that happened to users, but it was helpful for debugging things.

Some of our optimizations were kind of fun, though I buttume they are commonplace these days. In addition to the usual peephole optimizations, we would do other things like common tail merging. We would expand functions inline (tricky when they were recursive), unroll loops, do register optimization and overloading. My favorite, which I wrote, moved invariant stuff out of loops. These were very funny for one of the parts of the so-called Whetstone benchmark, The part in question was originally in the benchmark to evaluate function call and return overhead. It did, IIRC, a loop 10000x with some boring simple floating point calculations. Well, we expanded it inline, which defeated the original purpose, but many people think Whetstone is a floating point benchmark. Not after we optimized it. Once expanded inline, I moved ALL the instructions from the loop, so they were done only once. Then live-dead analysis removed them (including the now empty loop instructions), since the results were never used. So that part then ran instantaneously. You cannot get better than that. But for real work, that optimizer was a bit less effective, though useful.

-- .~. Jean-David Beyer Registered Linux User 85642. V PGP-Key: 9A2FC99A Registered Machine 241939. ^^-^^ 12:40:00 up 5 days, 11:01, 4 users, load average: 4.22, 4.16, 4.16