From: Paul Winalski <paul.winalski@gmail.com>
To: "Greg 'groggy' Lehey" <grog@lemis.com>
Cc: COFF <coff@tuhs.org>
Subject: [COFF] Re: What Happened to Interdata?
Date: Thu, 27 Jul 2023 12:30:45 -0400 [thread overview]
Message-ID: <CABH=_VR9DY9T9+YkYc+QwaOUSJ2Tp9B0M0e1bm_4AkszHGhiSw@mail.gmail.com> (raw)
In-Reply-To: <20230727034350.GC92211@eureka.lemis.com>
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.
next prev parent reply other threads:[~2023-07-27 16:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-25 23:23 [COFF] " segaloco via COFF
2023-07-26 14:38 ` [COFF] " Paul Winalski
2023-07-26 17:39 ` segaloco via COFF
2023-07-27 3:43 ` Greg 'groggy' Lehey
2023-07-27 16:30 ` Paul Winalski [this message]
2023-08-05 1:17 ` scj
2023-08-05 1:46 ` segaloco via COFF
[not found] ` <CANxB0bSVf+wc=Np8B+AbMPJ+myLhJR9m0M+etfEyrviqok0uSg@mail.gmail.com>
2023-08-05 13:57 ` [COFF] Re: [TUHS] " steve jenkin
2023-07-27 19:16 [COFF] " Noel Chiappa
2023-07-27 20:33 ` Paul Winalski
2023-07-28 3:38 ` Greg 'groggy' Lehey
2023-07-28 16:18 ` Paul Winalski
Reply instructions:
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CABH=_VR9DY9T9+YkYc+QwaOUSJ2Tp9B0M0e1bm_4AkszHGhiSw@mail.gmail.com' \
--to=paul.winalski@gmail.com \
--cc=coff@tuhs.org \
--cc=grog@lemis.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).