Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!ucla-cs!sdcrdcf!psivax!nrcvax!ihm
From: ihm@nrcvax.UUCP
Newsgroups: comp.sys.m68k,comp.sys.intel
Subject: Re: 386 vs 020 and big benchmarks (sieve)
Message-ID: <875@nrcvax.UUCP>
Date: Wed, 22-Apr-87 18:32:25 EST
Article-I.D.: nrcvax.875
Posted: Wed Apr 22 18:32:25 1987
Date-Received: Sat, 25-Apr-87 06:42:14 EST
References: <930@intsc.UUCP> <513@omen.UUCP> <933@intsc.UUCP> <866@oakhill.UUCP> <650@desint.UUCP>
Reply-To: ihm@minnie.UUCP (Ian Merritt)
Distribution: comp
Organization: The Frobboz Magic Graphics Systems Co., Inc. BitBlit Division
Lines: 40
Xref: utgpu comp.sys.m68k:370 comp.sys.intel:169

>In article <866@oakhill.UUCP> davet@oakhill.UUCP (Dave Trissel) writes:
>
>> If the 386 only supports three register variables and in this tiny benchmark
>
>As usual, Dave is right on target.  Pcc for the 386 does indeed only allow
>three register variables.  Furthermore, I am currently involved in writing
>an extremely carefully hand-coded assembly loop (bitblt, if you care) for
>the 386.  No matter what you do, you can't get more than seven registers
>for your use on the 386.  And even disregarding that, the code on the 386
>is *much* uglier than the equivalent 68k (not '020) code.  For example,
>the 386 only has one register (esi) that can do autoincrement loads, and
>one that can do autoincrement stores. 

[Lotsa really UGLY intel architectural restrictions omitted]

> [...]  I would *much* rather have
>the MMU built into the '020 than have the extra instructions you guys added
>(not that I don't like them too, but I think the MMU is much more important).
>And yes I realize that there are many applications that don't need an MMU.

Yeah, but try coding up your tight bitblit using bitfield instructions
on the '020.  I think you will find that it is MUCH shorter and faster
than the 68000 version.  I seem to recall a coworker doing exactly
this, for a general purpose bitblt, using the '86, the 68k and the
68020, (ignoring for the sake of comparison the ridiculous address
space limitations on the 80/1/286 (386 didn't exist yet), used small
model).  The hand optimized code on the '86 was something like 12
times as many instructions as for the 68K which was only about 2.5 to
3 times as large as for the '020.  I don't recall the 68000 and 68010
perfomance comparison, but the 68020 did this about 120 times as fast
as a 186.  The 286 was only about 3 times a 186, and the preliminary
numbers Intel had supplied us for the 386 were only about 3 or 4 times
the 286.

I would have prefered if the MMU was just made available sooner; not
necessarily on the same chip.  It will be interesting to see what
happens with the 68030 MMU now that it IS on chip.

Cheerz--
						--i