From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 694 invoked from network); 5 Aug 2023 03:46:33 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 5 Aug 2023 03:46:33 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 0E682426CE; Sat, 5 Aug 2023 13:46:27 +1000 (AEST) Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com [IPv6:2607:f8b0:4864:20::1136]) by minnie.tuhs.org (Postfix) with ESMTPS id 62905426CD; Sat, 5 Aug 2023 13:46:18 +1000 (AEST) Received: by mail-yw1-x1136.google.com with SMTP id 00721157ae682-5861116fd74so29183707b3.0; Fri, 04 Aug 2023 20:46:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1691207177; x=1691811977; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=MahkV8r5xnOVmmZfycCytiYhck6tt3DALbNLEABhNwc=; b=K6a0vKNFA54szb5qgghYqThLtt14QcJbcH03RXYJj+oa0Sr2tWspxD8J9qDmzAYcvc YLsV1HVuQxtUuurtjwKfTUDak6KwMC4coXeDjtfsnPf4ILaz4fe7NoWM22qYj8xLotNu R/RUaJJLsZvrI5+oJk+PhHG8sP1wpBuS1omZcnCUuZSa38WcSWLcp9nw4Blc+3xorMJJ kDCeFUCb4rrRMAPAXnKiYjXiyXZ4uI7uxzBfmRmrFVa2MLsKn7xz62naRwvp1RLx1Jzg BryZMnY2RgkEy3jw2Ng6JyYWq4BDWPTWJYyAmKjj7TCGWixpt/MkX5IRQl8sTC23s20L b0FQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691207177; x=1691811977; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MahkV8r5xnOVmmZfycCytiYhck6tt3DALbNLEABhNwc=; b=EoCHHv+KEZl8vAPxqobm2UAdeqjEYXDXEX/s8ZYsQc8q9WkIOKIPu9Icve9lTxgbM6 Ixt6BVYPOB7/ZZQx4up/Kt8y4cz/ftCHV4RCsB2d5zdVw/cBkhiDWclBx/ot4eLVJQu4 E+xKyu4kLVmlr22T9M7zd1MxWe8Wn+ES3vhx2pyle2W6YzwW3LFPm+UItyfJf9nTdMyW iHbKVyNfrTmSLhJDMYvDir1rxLKnvkiVeFLnRuK91MQhs1UJVf6MqzTAqzek45JBP6b0 m9vFAhf9jta9nKMpbmie7p9zLzP7nS9G/OFix6CROCEE5jK8wNyYRfdh8xKAyRFupQDS 54WQ== X-Gm-Message-State: AOJu0YzrwvQRGquG+jZwNAlD989XaaKgvdTd9CzctIwstFOWQ+eGHKWQ QiHVkb3iHCphPM2dfFO7WaLIhCPedxpMIoAYghIfnaGyhlE= X-Google-Smtp-Source: AGHT+IHUkXdFRv5MYEd9XTghQZh33R5viFpXY7duNIXiGiLu5HnnoiaSFW/p/SEDXurFL2v0muAOpoQVVbOtqAxTeCk= X-Received: by 2002:a81:8310:0:b0:586:9cbb:eef4 with SMTP id t16-20020a818310000000b005869cbbeef4mr3684506ywf.2.1691207176725; Fri, 04 Aug 2023 20:46:16 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Tom Lyon Date: Fri, 4 Aug 2023 20:46:05 -0700 Message-ID: To: segaloco Content-Type: multipart/alternative; boundary="00000000000002a8bf060224db82" Message-ID-Hash: PWWGWWBBYHZRKOU652VDIBATLWZWXK4P X-Message-ID-Hash: PWWGWWBBYHZRKOU652VDIBATLWZWXK4P X-MailFrom: pugs78@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: COFF , The Eunuchs Hysterical Society X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: [COFF] Re: What Happened to Interdata? List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --00000000000002a8bf060224db82 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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=E2=80=AFPM segaloco via TUHS wr= ote: > Steve thank you for the recollections, that is precisely the sort of stor= y > 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 al= l > the good in RISC-V there are also now maaaaany fabs with more license tha= n > ever to pump out questionable ICs. Combine that with questionable boards > with strange bus architectures, and gee our present time sure does presen= t > 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 th= e > 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 sma= ll > 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-bi= t > computing, it was reasonably fast, and once we got the low-level quirks o= ut > (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 tha= t > 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 t= he > 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 sco= op > 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 80= 86 > ports seemed to stick around internally for longer. Were Interdata machin= es > 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 sever= al > 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 UNIX= y > end, if there's any sort of missing scoop on the life and times of the Be= ll > 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 i= f > that history winds up in this thread. > > > --00000000000002a8bf060224db82 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Here's my summer activity=C2=A0report on my work porti= ng V6 code to the Interdata, working closely under Steve and Dennis.=C2=A0 = I left before the nasty bug was discovered. (I think).

On Fri, Aug 4, 2023 at 6:46=E2=80=AFPM segaloco via TUHS <tuhs@tuhs.org> wrote:
Steve thank you for the recol= lections, that is precisely the sort of story I was hoping to hear regardin= g your Interdata work.=C2=A0 I had found myself quite curious why it would = have wound up on a shelf after the work involved, and that makes total sens= e.=C2=A0 That's a shame too, it sounds like the 8/32 could've picke= d up quite some steam, especially beating the VAX to the punch as a UNIX pl= atform.=C2=A0 But hey, it's a good thing so much else precipitated from= your work!

Also, those sorts of microarchitectura= l bugs keep me up at night.=C2=A0 For all the good in RISC-V there are also= now maaaaany fabs with more license than ever to pump out questionable ICs= .=C2=A0 Combine that with questionable boards with strange bus architecture= s, and gee our present time sure does present ripe opportunities to experim= ent with tackling those sorts of problems in software.=C2=A0 Can't say = I've had the pleasure but it would be nice to still be able to fix stuf= f with a wire wrap in the field...

- Matt G.

P.S. TUHS cc as promised, certainly relevant information re: Int= erdata 8/32 UNIX.
------- Original Message -------
On Friday, August 4th, 2023 at 6:17 PM, scj@yaccman.com <scj@yaccman.com> wrote:

=20

Sorry for the year's delay in responding...=C2=A0 =C2=A0I wrote the = compiler for the Interdata, and Dennis and I did much of the debugging.=C2= =A0 The Interdata had much easier addressing for storage: the IBM machine m= ade you load a register, and then you had a limited offset from that regist= er that you could use.=C2=A0 I think IBM was 10 bits, maybe 12.=C2=A0 But a= ll of it way too small to run megabyte-sized programs.=C2=A0 The Interdata = allowed a larger memory offset and pretty well eliminated the offsets as a = problem.=C2=A0 I seem to recall some muttering from Dennis and Ken about th= e 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.= =C2=A0 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 syst= em.=C2=A0 Eventually, we got the machine running, and it was quite nice: tr= ue 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 t= o understand this" code in the kernel, which, it turned out, was a pro= phecy that came true.=C2=A0 =C2=A0On the whole, the project was so successf= ul that we set up a high-level meeting with Interdata to demo and discuss c= ooperation.=C2=A0 And then "the bug" hit.=C2=A0 The machine would= be running fine, and then Blam! it has lept into low memory and aborted wi= th no hint as to what or where the fault was.

We finally tracked down the problem.=C2=A0 The Interdata was a microcode= machine.=C2=A0 And older Unix system calls would return -1 if they failed.= =C2=A0 In V7, we fixed this to return 0, but there was still a lot of user = code that used the old convention.=C2=A0 When the Interdata saw a request t= o load -1 it first noticed that the integer load was not on an address divi= sible by 4, and jumped to a location in the microcode and executed a couple= of microinstructions.=C2=A0 But then it also noticed that the address was = out of range and entered the microcode again, overwriting the original addr= ess that caused the problem and freezing the machine with no indication of = where the problem was.=C2=A0 It took us only a day or two to see what the p= roblem was, and it was hardware, and they would need to fix it.=C2=A0 We ha= d our meeting with Interdata, gave a pretty good sales pitch on Unix, and t= hen said that the bug we had found was fatal and needed to be fixed or the = deal was off.=C2=A0 The bottom line, they didn't want to fix the bug in= the hardware.=C2=A0 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...


---
=C2=A0


On 2023-07-25 16:23, segaloco v= ia COFF wrote:

So I've been studying the Interdata 32-bit machines a bit more clo= sely 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 i= nfo on their history but not really anything about, say, failed follow-ons = that tanked their market, significant reasons for avoidance, or anything li= ke that. I also find myself wondering why Bell didn't do anything with = the Interdata work after springboarding further portability efforts while s= everal 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 t= oo comes from what influence the legacy of Interdata may have had on Perkin= -Elmer, as I've worked with Perkin-Elmer analytical equipment several t= imes in the chemistry-side of my career and am curious if I was ever operat= ing some vague descendent of Interdata designs in the embedded controllers = in say one of my mass specs back when.
=C2=A0
- Matt G.
=C2=A0
P.S. Looking for= more general history hence COFF, but towards a more UNIXy end, if there= 9;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 wi= nds up in this thread.

--00000000000002a8bf060224db82--