A note from Steve Johnson about the Bell 8/32 porting project:
Date: Fri, 04 Aug 2023 18:17:06 -0700
I wrote the compiler for the Interdata, and Dennis and I did much of the debugging. The Interdata had much easier addressing for storage: the IBM machine made you load a register, and then you had a limited offset from that register that you could use. I think IBM was 10 bits, maybe 12. But all of it way too small to run megabyte-sized programs. The Interdata allowed a larger memory offset and pretty well eliminated the offsets as a problem. I seem to recall some muttering from Dennis and Ken about the I/O structure, which was apparently somewhat strange but much less weird than the IBM.
Also, IBM and Interdata were big-endian, and the PDP was little-endian. This gave Dennis and Ken some problems since it was easy to get the wrong endian, which blew gaskets when executed or copied into the file system. Eventually, we got the machine running, and it was quite nice: true 32-bit computing, it was reasonably fast, and once we got the low-level quirks out (including a famous run-in with the "you are not expected to understand this" code in the kernel, which, it turned out, was a prophecy that came true. On the whole, the project was so successful that we set up a high-level meeting with Interdata to demo and discuss cooperation. And then "the bug" hit. The machine would be running fine, and then Blam! it has lept into low memory and aborted with no hint as to what or where the fault was.
We finally tracked down the problem. The Interdata was a microcode machine. And older Unix system calls would return -1 if they failed. In V7, we fixed this to return 0, but there was still a lot of user code that used the old convention. When the Interdata saw a request to load -1 it first noticed that the integer load was not on an address divisible by 4, and jumped to a location in the microcode and executed a couple of microinstructions. But then it also noticed that the address was out of range and entered the microcode again, overwriting the original address that caused the problem and freezing the machine with no indication of where the problem was. It took us only a day or two to see what the problem was, and it was hardware, and they would need to fix it. We had our meeting with Interdata, gave a pretty good sales pitch on Unix, and then said that the bug we had found was fatal and needed to be fixed or the deal was off. The bottom line, they didn't want to fix the bug in the hardware. They did come out with a Unix port several years later, but I was out of the loop for that one, and the Vax (with the UCB paging code) had become the machine of choice...
- I don't know; I didn't write that! Maybe they were thinking that the PDP-11 and the 360 were "differe[nt] in character sets, architecture and of course machine code", and the thought got garbled in the process of writing it down? Anyway, I'll fix it (after looking to see if the 7/32 and 8/32 are 'different in machine code' - or if we should have separate pages for the two machines).
- Good catch, thanks for finding it! Jnc (talk) 13:16, 7 August 2023 (CEST)
- The Interdata 32-bit machines had a very similar ISA to the 360, but were different in detail (as shown by SCJ's comment, above). So I just diked the whole comment.
- I wound up splitting the 7/32 onto a different page more on general principles than for any specific reason. Interdata documentation does not directly address the question of whether the 8/32 is upwardly compatible with the 7/32; they use the same instruction formats (and thus addressing modes -opcodes are always 8 bits on both machines), but the supported instruction count differs between the two. The 7/32 brochure says "242 instructions", but the 8/32 brochure says "173 instructions total"; I have no idea why such a large difference - or why the 8/32 has less. I wasn't about to compare instruction lists! Jnc (talk) 14:23, 8 August 2023 (CEST)