[TUHS] [COFF] Re: What Happened to Interdata?

[Tom Lyon]

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 <tuhs at tuhs.org> 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 at yaccman.com <scj at 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.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tuhs.org/pipermail/tuhs/attachments/20230804/164be4bc/attachment.htm>