Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!killer!tness7!tness1!nuchat!sugar!ficc!peter
From: peter@ficc.UUCP (Peter da Silva)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <1090@ficc.UUCP>
Date: 14 Jul 88 15:18:46 GMT
References: <5254@june.cs.washington.edu> <76700032@p.cs.uiuc.edu>
Organization: SCADA
Lines: 28

In article <76700032@p.cs.uiuc.edu>, gillies@p.cs.uiuc.edu writes:
> 1.  Simple programs that need OPTIMAL speed, and would be outrageously
> expensive on ANY machine.  The major example is BITBLT, a subroutine
> with about 10-15 parameters that does a massive amount of linear-time
> work.  If the BITBLT subroutines generates the machine code expressly
> for the particular arguments, you can save a factor of 3 or more in
> speed.  This is very important for interactive graphics.

You can save an even greater factor by building the BitBlt into the
hardware. This is what the Commodore Amiga does, using a chip called
the Biltter. I'm pretty surprised that a chipset this good that's cheap
enough to be put in a consumer machine hasn't been picked up (or
emulated) by the big boys. It makes a significant difference to the
speed of the machine.

And you could cut that ugly self modifying code out of BitBlt. Instead
you just:
	Wait for the blitter to be free (lock it).
	Set up its parameters (it can take 3 source bitmaps and one
		destination bitmaps, with any minterm)
	Blit (at DMA speeds, up to one word per clock).

You can even return to the caller before the blit's finished, if the
locking is in hardware or if the blitter can generate an interrupt to
clear the semaphore.
-- 
Peter da Silva  `-_-'  Ferranti International Controls Corporation.
"Have you hugged  U  your wolf today?" (uunet,tness1)!sugar!ficc!peter.