Article View: comp.arch
Article #21410Re: 80486 vs. 68040 code size [really: how many regs]
From: John Mashey
Date: Mon, 22 May 1989 05:51
Date: Mon, 22 May 1989 05:51
81 lines
4864 bytes
4864 bytes
In article <18549@cup.portal.com> bcase@cup.portal.com (Brian bcase Case) writes:
>>How about some facts on the 32bit version of the NOVIX, Phil Koopman's
>>WISC chip, and Johns Hopkins Labs stack oriented chip. All of these
>>chips were faster (more MIPS per Mhz) than the ...(680xx, 80x86) in '87 -
>>using fairly old technology.
>Not hard to do. The same (old technology) could be said of the MIPS and
>SPARC implementations of the time.
>>Did the big name chip developers miss something here? Why didn't any
>>of them develop a dual (4?) stack chip, zero (ok 1 or 2) addressing
>>modes, harvard architecure (3 data paths), 16 (or 32) intructions...
>However, have you considered the fact that the implemenations of commercial
>RISCs are constrained by, for example, virtual memory? Or the need to
>support many different kinds of languages?
Brian gives a pretty good set of answers here. I'd add a couple more:
1) Research chips are designed to explore some ideas, and they should be
designed, evaluated, and then (if desired) thrown away to go try the next
one. In order to do them at speed, they may well ignore all sorts of
issues in order to explore whatever it is they're researching.
Good examples are the Stanford MIPSs and Berkeley RISC chips (including
SOAR, SPUR, etc). These were important and worthy research efforts,
but I can't IMAGINE taking any of them, as is, straight into the commercial
market (note that although SPARC certainly resembles the RISC II/SOAR
chips, it of course addressed many additional issues).
2) Chips designed to be commercial, but special-purpose (like NOVIX),
have a different set of constraints. They have to be designed to be
testable, manufacturable, reasonably scalable into new technologies;
they might have to obey various interfacing constraints; they might make
unusual tradeoffs to do an excellent job at whatever they're aimed at.
Neither of the 2 above need to do what the 3rd class does:
3) Chips designed to be general-purpose chips covering a wide
range of languages and target environments not only need to be testable,
manufacturable, etc, but they need to have good performance and usability:
a) over a range of languages
b) over a range of operating systems
c) over a range of hardware-system design points
d) over a range of technologies, both at one time, and over time,
i.e., when you design the very first one, you'd probably better
have an idea where the technology is going, and what later
implementations might look like, to avoid mistakes.
All of this means tradeoffs: even with a million transistors on a chip,
you STILL have to make tradeoffs....
As a result, one can almost always pick a very specific set of choies,
and then make tradeoffs to produce a processor that will be better at that
one thing than are any of the general-purpose ones. On the other hand,
computing history tells us, that "that one thing" better have a large
market, i.e., large enough that the special-purpose processor gets the
investment to track the technology advances, and volume enough to keep
the costs low enough to stay competitive. There clearly are niches
where this is possible: for example, digital signal processors, or
some graphics chips.
One must take care not to compare apples and oranges amongst the 3
classes: all 3 are important, but they sure are different.
Finally, maybe somebody can set me straight, or provide some real DATA:
I have a vague memory of seeing something claiming that NOVIX had gone
out of business in the last few monthns. Can anybody either confirm
that, or the inverse?
And while I'm at it, there are rumors on the
street of Chapter-11 time for Edgecore(?) (used to be Edge). Anybody
have any data on that one? There's an interesting architectural
connection: Edge's business is selling very-high-end
68K-compatible boxes built from (I think) CMOS gate arrays, i.e.,
boxes OEMed to cover the high end of your line, if you're 68K-based.
(i.e., this is a strategy somewhat similar to NexGen's for the 386,
I think). Any postings of data might be useful.
--
-john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com
DDD: 408-991-0253 or 408-720-1700, x253
USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
Technical Details
Message-ID:
<20149@winchester.mips.COM>Path:
arc1-ca.pugleaf.net!utzoo!attcan!uunet!husc6!bbn!apple!versatc!mips!mashReferences:
<950@aber-cs.UUCP> <25651@amdcad.AMD.COM> <4228@ficc.uu.net> <18549@cup.portal.com>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!husc6!bbn!apple!versatc!mips!mash From: mash@mips.COM (John Mashey) Newsgroups: comp.arch Subject: Re: 80486 vs. 68040 code size [really: how many regs] Message-ID: <20149@winchester.mips.COM> Date: 22 May 89 05:51:58 GMT References: <950@aber-cs.UUCP> <25651@amdcad.AMD.COM> <4228@ficc.uu.net> <18549@cup.portal.com> Reply-To: mash@mips.COM (John Mashey) Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 81