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.