From: Tom Lyon <firstname.lastname@example.org>
To: segaloco <email@example.com>
Cc: COFF <firstname.lastname@example.org>, The Eunuchs Hysterical Society <email@example.com>
Subject: [TUHS] Re: [COFF] Re: What Happened to Interdata?
Date: Fri, 4 Aug 2023 20:46:05 -0700 [thread overview]
Message-ID: <CANxB0bSVf+wc=Np8B+AbMPJ+myLhJR9m0M+etfEyrviqok0uSg@mail.gmail.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 6062 bytes --]
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).
On Fri, Aug 4, 2023 at 6:46 PM segaloco via TUHS <firstname.lastname@example.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, email@example.com <firstname.lastname@example.org>
> 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.
[-- Attachment #2: Type: text/html, Size: 7432 bytes --]
prev parent reply other threads:[~2023-08-05 3:46 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <HVRjf4jkQW1dVYskomfTSIyGSjCdbjfs0ykG_cGfY4xTnXPSkPDIgZt86xk_jyaYHr_ukdE8a9LsjFtfWVwgvF3AbB8br2S5BUDNeyZKnEgemail@example.com>
[not found] ` <firstname.lastname@example.org>
2023-08-05 1:46 ` segaloco via TUHS
2023-08-05 3:46 ` Tom Lyon [this message]
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).