🚀 go-pugleaf

(I've just gotten caught up reading the news, so I'll tack all my ACE
comments on this posting. I do note that Dave seems to have read more
accurate versions of this than some of the previous posters on the topic...)

In article <21199@cbmvax.commodore.com> daveh@cbmvax.commodore.com (Dave Haynie) writes:
>>>> run for about $10k or so (monochrome, I'm sure) and should be quite speedy.
>>>A MIPS rep today told me to expect ACE machines (the compaq/microsoft etc
>>>group) at $2K to $5K in Q2 92.
I don't think anyone has announced any pricings yet.  I would observe that
can build a SS SLC-like machine with an R4000, but with less chips.
>
>Of course, the cheap-ass ACE machines, assuming they really do materialize,
>will be based on R3000A.
Quite possible; R3000As are certainly allowed.
>
>>Will ACE machines run binaries for today's MIPS machines (or is
>>that a meaningless statement because of DEC byte ordering?)  
All current MIPS chips can flip byte order dynamically.  ARC-compliant
machines (i.e., those able to run shrink-wrapped operating systems
of ODT and NT) run native little-endian.  MIPS, and others, may well
build machines that can run that, as well as OS variants that support both
the existing MIPS binaries, and the ODT binaries [this is quite feasible,
and in fact, not particularly worse than running both BSD and SV and POSIX
binaries, as we do right now.]

>The ACE committee at present consists of Compaq, DEC, and MIPS on the hardware
>side, MicroSoft and SCO on the software side.  MIPS wants to sell chips.  All
MIPS doesn't sell chips.... and it is also on the software side of this, BTW...

>>Or will they try to invent an application base from scratch?  If so,
>>will they have binary compatibility between machines which boot 
>>a MS-DOS and those which boot Unix?  Where does the support
>>announced for Intel processors come in?  
>
>I think they just mean software parity.  If you recompile code written for an
>ACE system, it should run unmodified on a corresponding PClone under the same
>OS.  I guess between OSs, you could always stick to standard function call
>interface sets, but I really doubt they're going for any cross-OS ABI here.
Also, NT on MIPS is also expected to run X86 MSDOS and Windows binaries;
they have some very clever stuff to do that. Windows binaries are
especially useful, as the interface is much cleaner, and you can jump
to high-speed native code much quicker.
1. TO SUMMARIZE THIS:
	1) There are two portable OS's being worked on:
		ODT version of UNIX
		NT (OS/2 3.0)
	2) Both of them are intended to be source code compatible at user
	level across:
		MIPS
		Intel 386 and up (but not 286)
	3) In both OS cases, the bulk of the OS code is portable.
	4) In both hardware cases, hardware that is compliant with an
	appropriate set of specs will be able to run shrink-wrapped
	binary OS's.  The MIPS version, in particular, is able to hide
	most of the hardware specificities, like choice of bus.
	5) NT will run DOS and Windows binaries, among other things.
	NT on MIPS is supposed to be able to run X86 DOS and Windows
	binaries.  ODT on MIPS will be able to run Ultrix binaries.

>The interesting thing about this ACE effort is not so much the project itself,
>which seems kind of wacky, but any effort to get a real open RISC architecture
Why wacky? There are perfectly sensible motivations for everybody involved;
the whole thing is geared around the following vision:
	IF you can make CPUs really fast, and still keep them cheap,
	you can create whole new kinds of applications, especially if
	you can get out from under some of the weirder compatibility issues
	deriving from 10-year+ old designs.
	I do a talk that ends with what you do with 50-100-mips on the
	desk or in your notebook, but if you don't believe me, you should
	hear Bill Gates' discussion on this.
However, to make it fast, but keep it cheap, you need to have, over the
	next few years:
	1) Highly-integrated processor, so that the clock scales up,
	and the manufacturing cost and difficulties kept down.  [This is
	part of the reason an R4000 is all on 1 chip.]
	2) High-volumes and multiple sources
	Bill G. says they wouldn't port NT for anything less than 1M/year
	volumes.
	3) High-volume software, in order to keep it cheap enough to
	be reasonable in this market.  And THAT implies that it might be smart
	to keep as much compatibility, at the application level for sure,
	and in the higher parts of the OS, with something that already has
	some serious volume out there.
(I.e., there is a rational reason for the Intel stuff, i.e., current
reality...  Somebody posted something rather rude about various people
lacking the courage to defy Intel ... to be polite, this was rather
uninformed...)
>system going.  Sun seems to have been trying to launch the same thing 
>themselves with SPARC, but the fact that they're a single house generating
>(at least originally) chip architecture, system software, and final product,
>they could be a scary plan to sign up for.  One of the reasons the PClones
Sun fought very hard to sign up COMPAQ, Which is surprising, since
Scott M has been saying (after ACE):
	Compaq is a subcontracting manufacturing slave to Intel/Microsoft.
	Compaq gets credit for two things: the all important interface called
	the handle on the portable PC, and the EISA bus, which he dismissed
	as another slow bus we don't need.
	Other quotes include the idea that PCs and Macs were great
	IBM Selectric replacements and great file cabinet replacements.
Needless to say, Intel fought demonically to stop this whole thing.
>
>The worst part of the PClone world was that the fool things were so hardware
>dependent, you couldn't innovate or cost reduce.  A good 90's open system
Yes, an excellent point; fortunately, we've learned a lot in the last
few years about designing things to allow for this.
-- 
-john mashey	DISCLAIMER: <generic disclaimer, I speak for me only, etc>
UUCP: 	 mash@mips.com OR {ames,decwrl,prls,pyramid}!mips!mash 
DDD:  	408-524-7015, 524-8253 or (main number) 408-720-1700
USPS: 	MIPS Computer Systems MS 1/05, 930 E. Arques, Sunnyvale, CA 94088-3650