Here's my summer activity report on my work porting V6 code to the Interdata, working closely under Steve and Dennis. I left before the nasty bug was discovered. (I think). https://akapugsblog.files.wordpress.com/2018/05/inter-unix_portability.pdf On Fri, Aug 4, 2023 at 6:46 PM segaloco via TUHS wrote: > Steve thank you for the recollections, that is precisely the sort of story > I was hoping to hear regarding your Interdata work. I had found myself > quite curious why it would have wound up on a shelf after the work > involved, and that makes total sense. That's a shame too, it sounds like > the 8/32 could've picked up quite some steam, especially beating the VAX to > the punch as a UNIX platform. But hey, it's a good thing so much else > precipitated from your work! > > Also, those sorts of microarchitectural bugs keep me up at night. For all > the good in RISC-V there are also now maaaaany fabs with more license than > ever to pump out questionable ICs. Combine that with questionable boards > with strange bus architectures, and gee our present time sure does present > ripe opportunities to experiment with tackling those sorts of problems in > software. Can't say I've had the pleasure but it would be nice to still be > able to fix stuff with a wire wrap in the field... > > - Matt G. > > P.S. TUHS cc as promised, certainly relevant information re: Interdata > 8/32 UNIX. > ------- Original Message ------- > On Friday, August 4th, 2023 at 6:17 PM, scj@yaccman.com > wrote: > > Sorry for the year's delay in responding... 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... > > > --- > > > > On 2023-07-25 16:23, segaloco via COFF wrote: > > So I've been studying the Interdata 32-bit machines a bit more closely > lately and I'm wondering if someone who was there at the time has the scoop > on what happened to them. The Wikipedia article gives some good info on > their history but not really anything about, say, failed follow-ons that > tanked their market, significant reasons for avoidance, or anything like > that. I also find myself wondering why Bell didn't do anything with the > Interdata work after springboarding further portability efforts while > several other little streams, even those unreleased like the S/370 and 8086 > ports seemed to stick around internally for longer. Were Interdata machines > problematic in some sort of way, or was it merely fate, with more popular > minis from DEC simply spacing them out of the market? Part of my interest > too comes from what influence the legacy of Interdata may have had on > Perkin-Elmer, as I've worked with Perkin-Elmer analytical equipment several > times in the chemistry-side of my career and am curious if I was ever > operating some vague descendent of Interdata designs in the embedded > controllers in say one of my mass specs back when. > > - Matt G. > > P.S. Looking for more general history hence COFF, but towards a more UNIXy > end, if there's any sort of missing scoop on the life and times of the Bell > Interdata 8/32 port, for instance, whether it ever saw literally any > production use in the System or was only ever on the machines being used > for the portability work, I'm sure that could benefit from a CC to TUHS if > that history winds up in this thread. > > >