Path: eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Newsgroups: comp.arch
Subject: Re: Is Intel exceptionally unsuccessful as an architecture designer?
Date: Sat, 14 Sep 2024 07:29:02 GMT
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Lines: 105
Message-ID: <2024Sep14.092902@mips.complang.tuwien.ac.at>
References: <memo.20240913205156.19028s@jgd.cix.co.uk>
Injection-Date: Sat, 14 Sep 2024 11:20:23 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6db5ee5180e7e79132e55bada9f3289b";
	logging-data="1479723"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/p+o5n7yAapK4wZ2a10Hmw"
Cancel-Lock: sha1:SkAG3iSaOr2L7C89Yyiazxc+2UU=
X-newsreader: xrn 10.11

jgd@cix.co.uk (John Dallman) writes:
>The tribe of x86 architectures didn't originate as an Intel design. The
>8008 ISA originated at Datapoint, and grew through the 8080 and 8085.
>Intel recognised their limitations, and decided to make something better,
>but the iAPX 432 took time to mature and the 8086 was designed as an
>extended 8080 to keep the company going until the 432 succeeded. 
>
>The 432 was a total failure, but the x86 line kept the company going and
>growing. Then they came up with the i960, which had some success as a
>high0end embedded processor, but was cancelled when Intel acquired rights
>to DEC's StrongARM cores.

The i960 was the outcome of salvaging another project, BiiN, which had
similar goals (from reading the Wikipedia article) as the 432 and had
many 432 veterans.  But apparently they learned from their mistakes,
and the base architecture is a RISC, and was competetive for a while.

Reading the 386 oral history, Intel's idea at the start of the 386
project was that BiiN was going to be the big thing, and 386 just a
stopgap for those who had already invested in the 80286 (similar to
432 and 8086).  At that point the IBM PC existed, but there was no big
PC market yet.  Some time during the project, the PC market grew far
beyond expectations, and the 386 became the main project of Intel.
And they then rode with 386 followons until they produced the same
situation again with IA-64 against Pentium Pro and its followons.

Anyway, the kind of market that BiiN was developed for did not appear
for BiiN.  Tandem and Stratus owned this market; my impression was
that BiiN was intended to be an alternative to those instead of
marketing the BiiN hardware to them.  Tandem went with MIPS
processors, and Stratus with the 68000, then, strangely, i860, then HP
PA, and finally Intel Xeon.

So when BiiN stopped as a project and company in 1989, the base
architecture, the i960 was salvaged and marketed as an embedded
processor (Intel management at the time did not want to market it for
Unix systems, probably because they were already marketing the 486 for
PCs and the i860 as super-chip).

According to Wikipedia, the first i960 taped out in the same month as
the 386, but that apparently was only for internal BiiN usage at the
time, and it only made commercial appearance in 1989 as embedded
processor with all the more advanced features disabled.

One interesting i960 is the i960CA (announced in July 1989), which is
the first single-chip superscalar: dual issue, one integer, one
memory, and one branch instruction can be performed at the same time,
at 33MHz (the R3000 came out in 1989 with single-issue and similar
clock).

Intel reassigned the development teams in 1990, with the now-former
i960 team working on the Pentium Pro and a smaller team working on the
i960, so the i960 fell back relative to the competition.  Given the
decision to market it only for embedded systems, that's probably
understandable.  The decision to replace it with StrongARM is in the
same vein.

If they had designed and marketed the i960 for the Unix market and if
they had done that from the start, they probably would have been among
the first commercial RISCs, maybe the first.  My guess is that an MMU
for Unix takes less development effort and less silicon than all the
features they designed in for BiiN, and they would have taped out and
released earlier.  It's not clear how that would have turned out in
the long run: Would IA-32/AMD64 still have taken over the Unix market?
Would they have started IA-64?

>The i860 was a pretty comprehensive failure, but the x86 line made them
>into a behemoth.

According to
<https://web.archive.org/web/20220705003416/https://spectrum.ieee.org/intel-i860>,
this was started around the same time as the 486.  Unlike the i960,
this was marketed as high-performance general-purpose CPU, probably to
address the widespread belief at the time that RISCs are the future
and IA-32 was doomed.  But apparently the i860 was designed for very
good performance from perfectly scheduled code, but was not so great
at usual compiler output (a mistake repeated in IA-64; so they did not
learn from their mistakes in this case).  I remember the explicitly
pipelined FPU, but don't remember anything where the i860 would
perform worse than other RISCs of its time.  Anyway, the i860 did not
see mainstream general-purpose use.

>Then they decided to phase that out and do Itanium.

There was never a successor to the i860, so IA-64 (which was not
started at Intel until 1994) is unlikely to have anything to do with
it.  Given that they wanted to market the i860 as high-end CPU, I
expect that there was a followup project worked on when the i860 was
released, but either that project failed (which would not surprise me,
as i860 features look like being bad ideas like branch-delay slots,
only more of them), or Intel decided that the market for the i860 was
too small, and they canceled the project (or both).

>It
>was less of a failure than 432 or i860, but they had to adopt AMD's
>x86-64 ISA to avoid shrinking themselves into a subsidiary of HP.

It seems to me that IA-64 was a bigger failure: More money invested,
and more money lost (probably even relative to the size of the company
at the time).

- anton
-- 
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
  Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>