gnu@hoptoad.UUCP (01/31/87)
In article <63900002@convex>, wallach@convex.UUCP writes: > the 32-bit superset of the 16-bit instruction set worked very > well. it turns out that to run under the 32-bit os (aos/vs), one had > to relink the 16-bit binaries. otherwsie, if the 16-bit os was > running no relinking was necessary. In article <900@dg_rtp.UUCP>, meissner@dg_rtp.UUCP (Michael Meissner) writes: > ...while the system calls > between AOS and AOS/VS are compatible, but unfortuneately, the system call > numbers are different. The upshot of this is that most users have to > relink their programs (and if they use direct system calls, recompile) > to move them from AOS to AOS/VS. Many programs (including the command > line interpreter) that run on AOS/VS are still 16-bit, though the percentage > is dropping. I worked for DG while they were designing and bringing up the 32-bit machine. (By the way, Steve Wallach, convex!wallach, designed the machine architecture.) I ran across my first production MV/8000 at Berkeley some time after I left DG. I loaded in my old 16-bit programs and tried to run them under the 32-bit OS. They failed miserably. Now Edson DeCastro, the president and founder of DG, had *INSISTED* that the 32-bit machine run old binaries without a mode bit. He had canceled the two previous 32-bit-machine projects because they did not do it this way. As told in "The Soul of a New Machine", Steve went to him and said "what do we have to do so you won't cancel this one" and he said "no mode bit". So they wedged the instruction set into the holes in the old one, modulo some fiddling in the interrupt handlers -- the microcode actually fetched the first instruction of the interrupt routine to see whether to handle the interrupt the "old" way or the "new" way, depending whether it was an "old" or "new" instruction! Steve got the hardware compatability right, but the software screwed it up. What blew up my 16-bit programs was that the OS group had renumbered the system calls. I called back to Westboro and talked to Claude Finn, who managed the OS group. He said, "Yeah, I renumbered them, it made the tables smaller." * I * D * I * O * T * ! * ! * ! * Now, I like Claude but he sure blew binary compatability for an utterly trivial reason. He probably saved about 10 or 20 bytes! Half the system calls in the 16-bit machine had the high-order bit on, because they were handled by a "ghost" process due to 64K address space limits. The other half were handled directly by the kernel. So there were two tables and the code looked at the high order bit to figure which one to use. Claude renumbered all the ghost calls to be sequential with the kernel calls, so he wouldn't have to test the high bit and use two tables any more. What blew me away was that, as a good programmer and as the manager of an operating system group, he didn't see that he had done any harm. Of course, DG has never fixed this mistake, either, though Claude has moved on. (They could add back the second table and support the old ghost call numbers with the same trivial effort it took to remove them.) By now nobody expects them to -- except me. But I'm not a DG customer. I wonder how many customer-years of time were burned to save those 20 bytes, and how many of them knew why? -- John Gilmore {sun,ptsfa,lll-crg,ihnp4}!hoptoad!gnu gnu@ingres.berkeley.edu Love your country but never trust its government. -- from a hand-painted road sign in central Pennsylvania