1 Dec
2014
1 Dec
'14
12:32 p.m.
From: Steven M Jones
only to be pummeled by the emerging RISC designs...
My (dim) recollection of the NS32K architecture (I recall someone came to MIT
and gave a presentation on it, and I have an early architecture document - so
old that it's called the NS16K!) was that it was very elegant, but my sense
now, looking back, was that it was one of that wave of machines (the VAX being
the other notable one) that went down the CISC road just before RISC arrived,
and showed that CISC was not really the way to go; those systems were all
dinosaurs.
Which, in the NS16K/NS32K's case was unfortunate, because the architecture in
other ways, i.e. at a high level (i.e. ignoring the instructions), was the
best of the whole lot. Notably, it attempted to provide real segmentation
support, perhaps the only chip of that group to do so.
Although of course once Unix took over the world, that was irrelevant.
(Much as I dearly love(d) V6 for how it got an incredible amount of power out
of a very small machine, it's pretty clear that the basic approach of Unix
was inferior to that of the single level store systems [e.g. Multics]; Unix
really was - and in many ways remains - a toy operating system, considered
from a larger viewpoint.)
Noel
1 Dec
1 Dec
10:03 p.m.
On 12/01/2014 11:32 AM, Noel Chiappa wrote:
but my sense
now, looking back, was that it was one of that wave of machines (the VAX being
the other notable one) that went down the CISC road just before RISC arrived,
and showed that CISC was not really the way to go; those systems were all
dinosaurs.
It was certainly a CISC design, and probably not as clean as
the VAX architecture
(although the number of addressing options on the VAX may
have gone off the
deep end also).
Jon
2 Dec
2 Dec
12:13 a.m.
On Mon, Dec 1, 2014 at 8:03 PM, Jon Elson <elson at pico-systems.com> wrote
[about NS32K]:
It was certainly a CISC design, and probably not as
clean as the VAX
architecture
(although the number of addressing options on the VAX may have gone off the
deep end also).
You haven't seen "off the deep end" CISC until you look at the Intel iAPX
432,
which makes the VAX architecture look lean and mean.
For that matter, VAX was far simpler than x86 and x86_64 have become.
And I wouldn't argue that it's CISC, but even the ARMv8 architecture manual is
over 2000 pages.
11:51 a.m.
On 12/01/2014 11:13 PM, Eric Smith wrote:
On Mon, Dec 1, 2014 at 8:03 PM, Jon Elson <elson at
pico-systems.com> wrote
[about NS32K]:
Yes, I do KNOW about the iAPX
4/32, and know somebody who
worked on one. Glacially
slow. It was an ambitious project, and if object-oriented
machine language was your
thing, it was what you needed. But, as for a practical
computer, it didn't make it.
It was certainly a CISC design, and probably not
as clean as the VAX
architecture
(although the number of addressing options on the VAX may have gone off the
deep end also).
You haven't seen "off the deep end" CISC until you
look at the Intel iAPX 432,
which makes the VAX architecture look lean and mean. For that matter, VAX was far simpler than x86 and
x86_64 have become.
Far cleaner, too! The PDP-11 instruction set was quite
good, the VAX had to move all
3-bit fields up to 4 bits, so they had to come up with 16
addressing modes. I suspect
some of them were so rarely used most programmers who even
worked in assembly
language didn't quite know what some of them did. The x86
is just a mess, like king
Ludwig's castle.
And I wouldn't argue that it's CISC, but even
the ARMv8 architecture manual is
over 2000 pages.
I use the Beagle Board and Beagle Bone. The TI manual on
the OMAP processors
is VERY badly organized, and vastly larger than it really
needs to be. For instance,
where they have 100 essentially identical registers for GPIO
configuration, they
have them described on 100 nearly identical pages. One page
with a description
of how the addressing applies to the banks of registers
would have been a LOT
better.
Jon
2:14 p.m.
On Tue, Dec 2, 2014 at 9:51 AM, Jon Elson <elson at pico-systems.com> wrote:
I'm not talking about a manual for a specific chip with a bunch of I/O.
Those are routinely over 1000 pages, and don't include the CPU
architecture.
What I'm referring to is the manual for *only* the ARMv8 CPU architecture,
and it is 2000 pages, with little of the redundancy of SoC manuals.
On 12/01/2014 11:13 PM, Eric Smith wrote:
Now you know two people who worked with them.
You haven't seen "off the deep end"
CISC until you look at the Intel iAPX
432,
which makes the VAX architecture look lean and mean.
Yes, I do KNOW about the iAPX 4/32, and know somebody who worked on one. Glacially slow.
"Glacially" is overstating it. It was slow. If it had shipped two years
earlier, as originally intended, the performance would have been
somewhat more in line with expectations.
and if object-oriented machine language
was your thing, it was what you needed.
Not really. It turned out not to be what anyone needed for anything. That
resulted in the P7 RISC design, still with some object-oriented features.
The P7 ultimately became the i960. (Note that Intel has reused the "P7"
designation for other things since.)
And I
wouldn't argue that it's CISC, but even the ARMv8 architecture
manual is
over 2000 pages.
I use the Beagle Board and Beagle Bone. The TI manual on the OMAP
processors
is VERY badly organized, and vastly larger than it really needs to be. 
2:28 p.m.
On 12/02/2014 11:14 AM, Eric Smith wrote:
(IRT: i432)
"Glacially" is overstating it. It was slow.
If it had shipped two years
earlier, as originally intended, the performance would have been
somewhat more in line with expectations.
Not so much slow, but incredibly expensive for the delivered
performance. We got regular pitches for the "soon to be real" i432 as
the answer to our 16 bit queries (this was about 1978). After awhile,
the mentions became less and less frequent and we were put on the i80186
pre-production customer base. The odd thing was that almost no mention
was made of the 8086. At that time, the only reaction from "fast Eddie"
our Intel sales rep, was a roll of the eyeballs.
--Chuck
3520
days inactive
3521
days old
5 comments
4 participants
participants (4)
-
cclist＠sydex.com -
elson＠pico-systems.com -
jnc＠mercury.lcs.mit.edu -
spacewar＠gmail.com