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=2.7 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, HTML_MESSAGE,MAILING_LIST_MULTI,RCVD_IN_SBL_CSS,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 28561 invoked from network); 5 Aug 2023 01:17:16 -0000 Received: from minnie.tuhs.org (50.116.15.146) by inbox.vuxu.org with ESMTPUTF8; 5 Aug 2023 01:17:16 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 56D35426BB; Sat, 5 Aug 2023 11:17:13 +1000 (AEST) Received: from quail.birch.relay.mailchannels.net (quail.birch.relay.mailchannels.net [23.83.209.151]) by minnie.tuhs.org (Postfix) with ESMTPS id 2BDE0426B7 for ; Sat, 5 Aug 2023 11:17:08 +1000 (AEST) X-Sender-Id: dreamhost|x-authsender|scj@yaccman.com Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 86E8294124E; Sat, 5 Aug 2023 01:17:07 +0000 (UTC) Received: from pdx1-sub0-mail-a214.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 2796B9404A6; Sat, 5 Aug 2023 01:17:07 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1691198227; a=rsa-sha256; cv=none; b=kz7Y94dPUg08++TvNhWSHyfC/u2HaULbZCGdH0+U3zMiHJQUSLv/FiEyBt6GC0r5rc1jMR /0SdQaTjnZ/mY4j67Sv5MXHbGgbkS9fmsuPtKO0YkNXfPnd/GLni3B7GKuTDFVqAprguzt TEHUDfKs+FId6YvbecxnZmis6d2X+ht5fpPIzvyHn/T86zUZHwUZF/vntfSaBqRD6aA68B WsPpAbP7TxOP+ciBEke6N+683m9YwR5IxFJS6OdPWrNFseCevxA2OzgcRk8ZoLqfkOTH74 a44OFqs4WxnMUgHZCcZQCJYn/0fMLE4GB4nNe0+bx5x5HPCX8YxwuFArxysbSw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1691198227; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=Da6Jusa/gerG3jgc6FphRIIcZyeapBkGGcnzme6tG1g=; b=mtpURFCJNzJIXLbwkB2uZyEXEtsN5FX0XDjldAZNc7/oRYsNtRzEpA7GS/bqTpvxpOW83s lF9QNDJsZSvd/LlW49hhkvlX4USLNyAUBJrDYdLp+aZ0CHTgrZNcOwze8qZF1Ssx8mNSAm dzp02R7eOp57Z/hqPICROrz6smgrME+tLjP/YJ3Qot9GAyVWxYf3vzkpUQTe3wRhaq/xtk EaIYf+1Fl5SlYygvnQFcOiN1u6w8LNJffYGv0DTtHtWL0egRjjoUWr1OU00bD8JhCZgYkv byOgT02SyrRTFz+62K7WDCkVc+Odko2AV4C6Royjrt7wva5hygsMkrSsvKbHSw== ARC-Authentication-Results: i=1; rspamd-849d547c58-7nt9t; auth=pass smtp.auth=dreamhost smtp.mailfrom=scj@yaccman.com X-Sender-Id: dreamhost|x-authsender|scj@yaccman.com X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|scj@yaccman.com X-MailChannels-Auth-Id: dreamhost X-Chief-Troubled: 4f60904963e9693c_1691198227398_440646894 X-MC-Loop-Signature: 1691198227398:271152946 X-MC-Ingress-Time: 1691198227398 Received: from pdx1-sub0-mail-a214.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.106.0.221 (trex/6.9.1); Sat, 05 Aug 2023 01:17:07 +0000 Received: from webmail.dreamhost.com (ip-66-33-200-4.dreamhost.com [66.33.200.4]) (Authenticated sender: scj@yaccman.com) by pdx1-sub0-mail-a214.dreamhost.com (Postfix) with ESMTPA id 4RHl6p6ZSbzTP; Fri, 4 Aug 2023 18:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yaccman.com; s=dreamhost; t=1691198226; bh=Da6Jusa/gerG3jgc6FphRIIcZyeapBkGGcnzme6tG1g=; h=Date:From:To:Cc:Subject:Content-Type; b=sya9Z5/lug+lOEnvvaz/6e1G+dn80V+12u7IdH3GcnF1DHMWP0ETzP9Cd/1BrYZ5w gb9cQulPkhiH0StBY7b/tB5yoNx12VFnHQ/E5NDEX04GzjBVaUsh9w+AT+8aASDh/e ajXrFk2XD31PoaTOthqeeAjxWzmieZ52MrequtavnrRIvFuhUWOAvPrukU6ba5D6Lg Ii/7+CfgjnpaG/WFQASiCoYrpgvFD64js/TJOPXUFYIAlTWin0qB4WEEAo5iOj81QL yg0BfZjQdMP7ybW0gXaADngGRmqdIH/9zT9nUP6fxFnvfwWAWBnmIa1pRYvDw/uWMN dQIWE2E/11lkQ== MIME-Version: 1.0 Date: Fri, 04 Aug 2023 18:17:06 -0700 From: scj@yaccman.com To: segaloco In-Reply-To: References: User-Agent: Roundcube Webmail/1.4.3 Message-ID: X-Sender: scj@yaccman.com Content-Type: multipart/alternative; boundary="=_c061a436a57275e49544a18250ee657a" Message-ID-Hash: 5ODLQZFMETWSGDBNVKBWBROVDDIOICH3 X-Message-ID-Hash: 5ODLQZFMETWSGDBNVKBWBROVDDIOICH3 X-MailFrom: scj@yaccman.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 X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [COFF] Re: What Happened to Interdata? List-Id: Computer Old Farts Forum Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --=_c061a436a57275e49544a18250ee657a Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed 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. --=_c061a436a57275e49544a18250ee657a Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=UTF-8

Sorry for the year's delay in responding...   I wrote the comp= iler for the Interdata, and Dennis and I did much of the debugging.  T= he Interdata had much easier addressing for storage: the IBM machine made y= ou load a register, and then you had a limited offset from that register th= at 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 allow= ed a larger memory offset and pretty well eliminated the offsets as a probl= em.  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= =2E  This gave Dennis and Ken some problems since it was easy to get t= he wrong endian, which blew gaskets when executed or copied into the file s= ystem.  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-lev= el 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 t= hat came true.   On the whole, the project was so successful that= we set up a high-level meeting with Interdata to demo and discuss cooperat= ion.  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= =2E  In V7, we fixed this to return 0, but there was still a lot of us= er code that used the old convention.  When the Interdata saw a reques= t to load -1 it first noticed that the integer load was not on an address d= ivisible by 4, and jumped to a location in the microcode and executed a cou= ple of microinstructions.  But then it also noticed that the address w= as out of range and entered the microcode again, overwriting the original a= ddress 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 th= e 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, an= d 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 c= ode) 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 scoo= p on what happened to them. The Wikipedia article gives some good info on t= heir history but not really anything about, say, failed follow-ons that tan= ked their market, significant reasons for avoidance, or anything like that= =2E I also find myself wondering why Bell didn't do anything with the Inter= data work after springboarding further portability efforts while several ot= her little streams, even those unreleased like the S/370 and 8086 ports see= med to stick around internally for longer. Were Interdata machines problema= tic in some sort of way, or was it merely fate, with more popular minis fro= m 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, a= s I've worked with Perkin-Elmer analytical equipment several times in the c= hemistry-side of my career and am curious if I was ever operating some vagu= e descendent of Interdata designs in the embedded controllers in say one of= my mass specs back when.
 
- Matt G.
 
P.S. Lookin= g for more general history hence COFF, but towards a more UNIXy end, if the= re'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 i= n the System or was only ever on the machines being used for the portabilit= y work, I'm sure that could benefit from a CC to TUHS if that history winds= up in this thread.
--=_c061a436a57275e49544a18250ee657a--