Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!apple!amdahl!amdcad!rpw3
From: rpw3@amdcad.AMD.COM (Rob Warnock)
Newsgroups: comp.arch
Subject: Re: Register usage
Message-ID: <25635@amdcad.AMD.COM>
Date: 15 May 89 18:27:15 GMT
References: <259@mindlink.UUCP> <8104@killer.Dallas.TX.US> <25633@amdcad.AMD.COM>
Reply-To: rpw3@amdcad.UUCP (Rob Warnock)
Organization: [Consultant] San Mateo, CA
Lines: 33

In article <25633@amdcad.AMD.COM> tim@amd.com (Tim Olson) writes:
+---------------
| In article <8104@killer.Dallas.TX.US> elg@killer.Dallas.TX.US writes:
| | (for one thing, the idea of kludging in byte-fetch logic externally
| | probably turned off potential system designers). 
| This is something that we have changed -- Revision 'C' Am29000's have
| fully-implemented byte and half-word loads and stores, with both signed
| and unsigned versions of loads.
+---------------

And it was done in a fully upwards-compatible way. Old code continues to run
correctly on new chips. And the C compiler can still be told to generate any
of the flavors of old, old-but-with-byte-write, or new code.

Anyway, the compilers have always handled 29k byte-load and byte-store on
word-only memory just fine [LOAD/EXTRACT or LOAD/INSERT/STORE]. All the
published performance numbers (until Rev.C) were for *no* hardware byte
support. And Unix doesn't care (both 4.3 & S5r3 run). I suspect the real
reason you don't see 29k-based Unix workstations is that it just wasn't
quite there during the window that a bunch of people were choosing their
RISC/Unix CPU. "Missed the wave", as it were.  [Who knows, it may see
some Unix use yet, by those who'd rather not compete directly with other
SPARC/MIPS/88k vendors.]

Still, it makes a neat embedded controller...


Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403