Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sauron.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!ittatc!dcdwest!sdcsvax!celerity!sdcc6!ncr-sd!ncrcae!sauron!campbell
From: campbell@sauron.UUCP (Mark Campbell)
Newsgroups: net.micro
Subject: Re: 386 Family Products
Message-ID: <601@sauron.UUCP>
Date: Thu, 19-Dec-85 09:04:25 EST
Article-I.D.: sauron.601
Posted: Thu Dec 19 09:04:25 1985
Date-Received: Sun, 22-Dec-85 01:18:23 EST
References: <129@intelca> <4400130@uiucdcsb> <6185@utzoo.UUCP> <433@ecn-pc.UUCP> <132@ism780c.UUCP> <498@ukc.UUCP>
Reply-To: campbell@sauron.UUCP (Mark Campbell)
Organization: NCR Corp., Advanced System Development, Columbia, SC
Lines: 28

In article <498@ukc.UUCP> rde@ukc.UUCP (R.D.Eager) writes:
>
>> ...the 80386 still has too few registers....
>
>Oh yeah? What's so great about lots of registers? You're better off with
>a  nice  simple  design  (no  bits wasted in each instruction to specify
>which register) and a good fast cache. A cache is after  all  a  dynamic
>equivalent  to the attempts (often bad ones) at register optimisation by
>compilers. [...]

A cache IS NOT a dynamic (or any other type) equivalent to "attempts at
register optimization".  Named versus unnamed memory space arguments
not withstanding, caches are in most cases slower (by at least a memory
cycle) than register accesses.

>Let's keep to machines with ONE general purpose  register,  with  a  few
>extra  ones for specific purposes. [...]

You don't want an 80*86, you want a stack-based machine.  It's rather
difficult locating these, as most have had rather severe problems commercially.

>Let's stop moaning about the lack  of  general  purpose  registers...who
>needs them? Keep the compiler writer's job easy... [...]

And keep the applications slow...
-- 

Mark Campbell    Phone: (803)-791-6697     E-Mail: !ncsu!ncrcae!sauron!campbell