[COFF] Re: What Happened to Interdata?

[COFF] Re: What Happened to Interdata?

[Noel Chiappa]

    > From: Greg 'groggy' Lehey

    > Interdata had instruction sets that were close to the IBM instruction
    > set, but my recollection was that they were different enough that IBM
    > software wouldn't run on them.

Bitsavers doesn't have a wealth of Interdata documentation, but there is some:

  http://bitsavers.org/pdf/interdata/32bit/

Someone who's familiar with the 360 instruction set should be able to look
at e.g.:

  http://bitsavers.org/pdf/interdata/32bit/8-32/8-32_Brochure_1977.pdf

and see how compatible it is.

	Noel

[COFF] Re: What Happened to Interdata?

[Paul Winalski]

On 7/27/23, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:

>
> Someone who's familiar with the 360 instruction set should be able to look
> at e.g.:
>
> and see how compatible it is.

Thanks for the pointer.  I took a quick look.  My knowledge of the
S/360 instruction set is very rusty at this point--it's been over 40
years since I programmed in it.

The program status word (PSW) format looks very familiar.  Both
architectures seem to support 24-bit addressing.

Interdata has some data types and instructions for manipulating them
not present in S/360.  Circular lists, for example, and instructions
for CRC calculation.

I didn't see anything about packed or zoned decimal support.

So perhaps an extended subset of S/360.  I'd have to do a side-by-side
comparison between this document and S/360 Principles of Operation to
determine the level of binary program compatibility, if any.  But it
looks like it might be better than the HitchHiker's Guide to the
Galaxy adage:  "almost, but not quite, entirely unlike tea."

-Paul W

[COFF] Re: What Happened to Interdata?

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 1672 bytes --]

On Thursday, 27 July 2023 at 16:33:54 -0400, Paul Winalski wrote:
> On 7/27/23, Noel Chiappa <jnc@mercury.lcs.mit.edu> wrote:
>
>> Someone who's familiar with the 360 instruction set should be able to look
>> at e.g.:
>>
>> and see how compatible it is.
>
> Interdata has some data types and instructions for manipulating them
> not present in S/360.  Circular lists, for example, and instructions
> for CRC calculation.

Yes, it's possible that both Interdata and RCA/UNIVAC/ICL instruction
sets are supersets of the /360 instruction set.  The only one I still
remember is the LI (load immediate) instruction.  The /360 did the
same function with LA (load address), but IIRC that was RX (4 bytes),
while LI was RR (2 bytes).

> I didn't see anything about packed or zoned decimal support.
>
> So perhaps an extended subset of S/360.  I'd have to do a side-by-side
> comparison between this document and S/360 Principles of Operation to
> determine the level of binary program compatibility, if any.  But it
> looks like it might be better than the HitchHiker's Guide to the
> Galaxy adage:  "almost, but not quite, entirely unlike tea."

Yes, that seems reasonable.  My guess was that binary compatibility
wasn't a big issue in those days, since nearly all applications
software was written only for specific installations.  And of course
licensing issues would preclude running IBM OS on the other machines.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

[COFF] Re: What Happened to Interdata?

[Paul Winalski]

On 7/27/23, Greg 'groggy' Lehey <grog@lemis.com> wrote:
>
> My guess was that binary compatibility
> wasn't a big issue in those days, since nearly all applications
> software was written only for specific installations.  And of course
> licensing issues would preclude running IBM OS on the other machines.

That certainly was true for S/360 in the 1960s.  IBM bundled its
software offerings with its hardware.  If you leased an IBM S/360, you
got the development toolset (compilers, link editor, assembler) for
free, as well as utilities such as sort/merge.  Source code for the OS
and the utilities was readily available in microfiche form.  There
were very few thrid-party software offerings.  One that sticks in my
mind is SyncSort, a sort/merge utility that far outperformed IBM's
sort/merge program.  If you were a big S/360 data center doing really
serious, high-volume stuff, you used Storage Technology tape drives
and SyncSort.

That all changed when a 1969 antitrust complaint caused IBM to
unbundle its software from hardware.  Before, you got the software for
free as part of your hardware lease.  After, you had to buy a separate
license for each software product.

-Paul W.

[COFF] Re: What Happened to Interdata?

[segaloco via COFF]

[-- Attachment #1: Type: text/plain, Size: 5442 bytes --]

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 <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.

[-- Attachment #2: Type: text/html, Size: 6702 bytes --]

[COFF] Re: What Happened to Interdata?

[scj]

[-- Attachment #1: Type: text/plain, Size: 4283 bytes --]

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: 5189 bytes --]

[COFF] Re: What Happened to Interdata?

[Paul Winalski]

On 7/26/23, Greg 'groggy' Lehey <grog@lemis.com> wrote:
>
> That's not the way I remember it.  RCA (and UNIVAC with them) and
> Interdata had instruction sets that were close to the IBM instruction
> set, but my recollection was that they were different enough that IBM
> software wouldn't run on them.  That's a different situation from
> Amdahl, which was almost completely compatible.

As I recall it, the RCA Specra 70 was compatible with the IBM System
360 instruction set.  It thus could run S/360 user applications.  And
maybe OS/360?  The downfall came with S/370.  IBM withheld the
privileged portions of the architecture (including dynamic address
translation [DAT; virtual memory]) and so when OS/VS and DOS/VS came
out they wouldn't run on Spectra 70.  RCA was forced to develop their
own OS.  Over time key IBM applications such as CICS depended on new
features in OS/VS and DOS/VS.  It wouldn't surprise me if many of
those dependencies were gratuitous.  So RCA was stuck in an endless
cycle of having to add new (D)OS/VS features to their own OS.  The big
IT customers who form this market valued stability more than the lower
price for the Spectra vs. S/370, and so RCA lost its market and
eventually gave up.

By the time Amdahl founded his own company, the privileged side of the
S/370 architecture had been revealed.  The S/370 architecture allows
for a restricted set of model-dependent behavior and features in areas
such as control register semantics and machine check handling.  The
Amdahl CPUs were no different from the S/370s as one model of S/370 is
from another.  (D)OS/VS keeps this model-dependent code in separate
modules from the bulk of the OS.  Amdahl only had to provide their own
set of model-dependent modules.  A smaller--and tractable--task
compared to what had faced RCA and Interdata at the start of the S/370
era.

-Paul W.

[COFF] Re: What Happened to Interdata?

[Greg 'groggy' Lehey]

[-- Attachment #1: Type: text/plain, Size: 1330 bytes --]

On Wednesday, 26 July 2023 at 10:38:04 -0400, Paul Winalski wrote:
> On 7/25/23, segaloco via COFF <coff@tuhs.org> wrote:
>> 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?
>
> I suspect that Interdata had the same problem with their S/360
> lookalikes that RCA did with theirs.  If your business model is to
> provide a cheaper hardware alternative to IBM, your machine has to run
> IBM software, particularly the OS.

That's not the way I remember it.  RCA (and UNIVAC with them) and
Interdata had instruction sets that were close to the IBM instruction
set, but my recollection was that they were different enough that IBM
software wouldn't run on them.  That's a different situation from
Amdahl, which was almost completely compatible.

But that was a few years ago now, and I have forgotten the details.
Does anybody know for sure whether they could run IBM software?  I
know from my time at UNIVAC that the 9000 series had their own
operating systems.

Greg
--
Sent from my desktop computer.
Finger grog@lemis.com for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 163 bytes --]

[COFF] Re: What Happened to Interdata?

[segaloco via COFF]

> If your business model is to
> provide a cheaper hardware alternative to IBM, your machine has to run
> IBM software, particularly the OS.
> 
> -Paul W.

I think that's what tripped me up studying this, I didn't realize Interdata was trying to compete with IBM in the mainframe world.  My only knowledge of them is via the UNIX connection regarding 7/32 and 8/32, which gave me the impression that Interdata was more in DECs market slice with minis than competing with IBM mainframes.  That certainly puts their history in better perspective for me, thanks Paul!

- Matt G.

[COFF] Re: What Happened to Interdata?

[Paul Winalski]

On 7/25/23, segaloco via COFF <coff@tuhs.org> wrote:
> 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?

I suspect that Interdata had the same problem with their S/360
lookalikes that RCA did with theirs.  If your business model is to
provide a cheaper hardware alternative to IBM, your machine has to run
IBM software, particularly the OS.  When IBM did their pre-release of
the S/370 specifications they deliberately left out key bits of the
privileged architecture, such as the detailed bit layout of the PSW.
Companies such as RCA and Interdata had make guesses while designing
their S/370 lookalikes and in some cases they guessed wrong.  RCA's
Spectra 70 couldn't run IBM OS/VS or DOS/VS and that made it a total
non-starter for most IBM commercial shops.  I suspect Interdata ran
into the same problem.  Yes, they could design their own me-too
operating systems, but they would always lag behind on new IBM OS
features, on which critical IBM applications would depend.  The IBM
customer base knew this and stuck with genuine IBM.  A lower price
point wasn't enough to make up for the incompatibility.

The advent of 32-bit minicomputers at the end of the 1970s brought
down for good the IBM price umbrella under which Interdata and other
lookalikes had been living.  An example of how high that price
umbrella had been:  In 1978 my undergraduate alma mater was a
true-blue IBM shop with a S/370 model 125 running batch, CICS, and a
small BASIC timesharing system for the students.  They'd outgrown the
model 125.  IBM's solution was to upgrade to a model 135.  For the
same price as the IBM processor upgrade, DEC was offering a complete
VAX-11/780 system to run timesharing and other academic computing,
with the S/370-125 devoted exclusively to the business side of things.
The 11/780 was roughly equivalent in computing power to an IBM
S/370-158--two models up from the 125.  Buying the 11/780 was a
complete no-brainer.

IBM was forced to cut prices on the S/370 line, and that fatally
destroyed Interdata's one advantage over true S/360/370.

-Paul W.