Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rutgers!sri-spam!mordor!styx!ames!oliveb!sun!david
From: david@sun.uucp (David DiGiacomo)
Newsgroups: comp.sys.m68k
Subject: 68020 bitblt (was 386 vs 020 and big benchmarks)
Message-ID: <17320@sun.uucp>
Date: Fri, 24-Apr-87 12:27:10 EST
Article-I.D.: sun.17320
Posted: Fri Apr 24 12:27:10 1987
Date-Received: Sat, 25-Apr-87 20:44:06 EST
References: <930@intsc.UUCP> <513@omen.UUCP> <933@intsc.UUCP> <866@oakhill.UUCP> <650@desint.UUCP> <875@nrcvax.UUCP>
Organization: Sun Microsystems, Inc. - Mtn View, CA
Lines: 29

In article <875@nrcvax.UUCP> ihm@minnie.UUCP (Ian Merritt) writes:
>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.

Shorter yes, faster -- probably not.  Using the bitfield instructions
cuts instruction count at the expense of memory cycles.  Since the 68020
always has an I cache it's reasonable to burn a few extra instructions
to minimize memory accesses.

However, the biggest disadvantage of the bitfield instructions is that
it's impossible to use them effectively from C.  The current Sun bitblt
(libpixrect.a:mem_rop.o) is close to 26K of object code -- there's no
way I could have written that in assembly language!

Aside from clock rate, data bus width, and the I cache, the 68020's
biggest advantage over the 68010 for bitblt is its barrel shifter.  On
the 68010 a 16 bit bitblt is generally better than a 32 bit version
because the reduced average shift count makes up for the increased
instruction count.

I agree with the other posters that the 386 doesn't have enough
registers for bitblt.  The 10 registers I get with the Sun 680x0
compiler are almost enough, although I could make good use of 6-10 more.
(It always bugs me that architecture and compiler people ignore graphics
code when deciding how to build systems...)

-- 
David DiGiacomo, Sun Microsystems, Mt. View, CA sun!david david@sun.com