Path: utzoo!attcan!uunet!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.arch Subject: Re: Self-modifying code Message-ID: <4324@cbmvax.UUCP> Date: 25 Jul 88 23:38:31 GMT References: <1988Jul22.164129.5495@utzoo.uucp> <4912@killer.DALLAS.TX.US> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 73 In article <4912@killer.DALLAS.TX.US> elg@killer.DALLAS.TX.US (Eric Green) writes: >in article <1988Jul22.164129.5495@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) says: >> Uh, using what for memory bandwidth? A good implementation of BitBlt, >> whether in software *or* hardware, will run the memory flat out, leaving >> nothing for "servicing other processes". > >But the 68000 (uncached) version would use 3/4ths of that bandwidth >to fetch INSTRUCTIONS. Also note that the bandwidth of modern 100ns >memories is much greather than a 8mhz 68000 can take advantage of... >even >when the 68000 is on the bus 100% of the time that it can be, you >still have half that memory bandwidth left for blitter operations etc. >(a fact that the designers of the ST use to do their video refresh). Also, remember that there are more than one memory busses out there, and even if cycles are tight in video ("chip") memory, the processor can run flat out from rom or expansion ram. >> If your CPU is sitting there waiting for memory, it might as well be doing >> the BitBlt itself. Don't forget, the 68000 doesn't have the BFEXTU instruction, so the inner loop of a BitBlit isn't as tight as on a 68020. >> the sort of thing an amateur knocks off in an evening. The techniques are >> not that well known (especially in the micro community, which is notorious >> for its ignorance of the state of the art -- the people at Commodore most >> likely had no idea it was even possible to do a fast software BitBlt). Excuse me, I have a paper in front of me published in EUUG last fall by a researcher at AT&T on optimized software BitBlits in C on an 68020. If you want to insult people please do it to the XYZZY-clone makers and the people who write software for them. >> Note that some of the earlier Suns had quite a bit of hardware BitBlt >> assist, and the newer ones don't. Sun learned. Commodore will, someday. > >Earlier Suns were based upon 68000/68010 techynology, where hardware >bitblt's make a lot of sense. Later Sun's, based upon 68020s, don't >need the hardware assist (see the beginning of this message). Hardware BitBlit is still useful in a lightwieght process architecture where you have divided memory spaces (and thus much higher effective band- width). >Unfortunately, Commodore probably will retain their blitter even when >they move into 68020/68030 machines, for backward-compatability >reasons (there's a helluva lot of programs out there, mostly games, >directly accessing that blitter).BTW, games programmers are known for >their dedication to speed... and most of the games programmers that I >know have made extensive use of the blitter whenever it made sense >(when moving large amounts of data, when setup time is no longer the >dominating factor). Actually, a number of the assembler hacker-types who write games for the amiga ignore the blitter, because if you bypass the system software it's a pain to set up, or because in their precise setup they can do things faster because of various restrictions. The blitter is still great for general purpose stuff. Other nice things done by our blitter are things like line draws and area fills. Fast software implementations of BitBlit tend to be 2 sources, 1 destination blits (therefor 16 operations). If you expand them to 3 sources, 1 destination (256 operations), they tend to take up a LOT of code/ROM space, or they slow down a lot, or both. 3 sources are VERY useful for animation, since it lets you do "cookie cutter" blits, with an object that is masked onto the destination, without destroying the areas in the rectangle but outside the mask. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup