Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!crdgw1!crdos1!davidsen
From: davidsen@crdos1.crd.ge.COM (Wm E Davidsen Jr)
Newsgroups: comp.arch
Subject: Re: World's Cheapest Unix Engine
Message-ID: <2333@crdos1.crd.ge.COM>
Date: 10 Jul 90 15:18:10 GMT
References: <78-3JC2@ggpc2.ferranti.com> <2748@skye.ed.ac.uk> <31093@cup.portal.com> <457@bench.sublink.ORG> <2329@crdos1.crd.ge.COM> <3115@psueea.UUCP>
Reply-To: davidsen@crdos1.crd.ge.com (bill davidsen)
Organization: GE Corp R&D Center, Schenectady NY
Lines: 28

In article <3115@psueea.UUCP> yeung@eecs.UUCP (Woodrow Yeung) writes:

| I sure hope the SX is only 10% more expensive to make.  It would be pretty
| silly for Intel to put any more engineering effort in making the 386SX than
| to disable some 16 line on the 386. Thus, the 386SX chip is a more expensive
| chip, Cost = 386 + lobotomy.  

  Since the logic is in the DX bus interface unit to build 32 bit
fetches from 8 and 16 bit datapaths, I think all that's needed (more of
less) is to set the 16 bit datapath line active. That much is true.

  However, note that most other chip manufacturers have not put logic in
the BIU to work with narrow data paths or offset addresses. If you try
to fetch 32 bits starting at a location not a multiple of four on a
SPARC you get a bus error.

  This is a matter of design philosophy: should the chip do what I say,
even if it isn't fast, or should the chip leave out logic to allow me to
do what I want, so that there will not be slow instructions.

  Note that the 68k chip in a Sun3 also allows offset addressing, while
several mainframe systems don't. This is not a CISC vs RISC issue, since
some CISC systems restrict addressing. Since it's easier to not handle
anything except bus access in a single read, I don't see where a chip
which allows more complex bus access modes is inferior.
-- 
bill davidsen	(davidsen@crdos1.crd.GE.COM -or- uunet!crdgw1!crdos1!davidsen)
            "Stupidity, like virtue, is its own reward" -me