Date: Thu, 21 May 1998 07:56:58 +1000 (EST) From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: hackers@FreeBSD.ORG Subject: Intel vs the rest (was `Original PC' and `talk') Message-ID: <199805202156.HAA15942@gsms01.alcatel.com.au>
next in thread | raw e-mail | index | archive | help
On Wed, 20 May 1998 10:43:54 +0200 (CEST), Oliver Fromme <olli@dorifer.heim3.tu-clausthal.de> wrote:
>There was also an 68000-8 with external 8 bit bus.
As I remember, the 68008 came out much later. The only thing I can think
of that used it was the Sinclair QL - which was mid-80's.
On Wed, 20 May 1998 10:42:12 +0100, Karl Pielorz <kpielorz@tdx.co.uk> wrote:
>Is it me or is basically everyone here either a) Not a big fan of Intel
>(strange considering what FreeBSD runs on ;-)
Possibly as a result of having to work with the architecture :-)
>b) Prefers the Motorola? (I certainly do!), and / or c) Largely used to own,
>program, hack on Amiga's? - or at least want FreeBSD to work as well as the
>Amiga did <g>
Agreed on all three. It's worth noting that Windoze-95 gave PC users
the same capabilities that the Amiga had when it came out (PnP was part
of the original Amiga spec).
On Wed, 20 May 1998 19:58:48 +0930, Greg Lehey <grog@lemis.com> wrote:
> but nowadays the register model isn't very important to
>anybody except compiler writers.
The register model _does_ directly affect performance (admittedly, only
marginally). Also, the overall architecture has a substantial impact
on the complexity/performance tradeoffs.
The major effect is that having more registers means that local
variables are less likely to spill onto the stack - where they'll be
slower to access(*), result in larger code and may trigger further
spills to provide work registers in the absence of orthoganal mem-mem
instructions. (More registers also increase the instruction size,
reducing code density where the registers aren't needed).
As an example of the impact of an architectural decision on
complexity: The 68k included a clear split between (non-modifiable)
instructions and (modifiable) data, the x86 didn't (and early
applications often used self-modifying code). This means that the x86
needs a unified cache, whilst the 68k uses a split cache - which gives
it two immediate advantages: The I-cache is also somewhat simpler (no
need for dirty bits or the write-{through,back} logic), allowing more
of it for the same complexity. Dual caches allow parallel I and D
accesses - ie effectively doubling the cache <-> CPU bandwidth (dual-
porting the cache can be done, but entails a substantial increase in
complexity). (The downside is that a unified cache will adjust to
different code vs data footprints - giving somewhat better hit rates
for a given total cache size).
Have a look at the performance vs transistor counts for things like
Chuck Moore's MuP21.
(*) The stated instruction timings may be the same but when you account
for all the caveats on memory accesses, it'll be slower in reality.
Peter
--
Peter Jeremy (VK2PJ) peter.jeremy@alcatel.com.au
Alcatel Australia Limited
41 Mandible St Phone: +61 2 9690 5019
ALEXANDRIA NSW 2015 Fax: +61 2 9690 5247
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805202156.HAA15942>