Newsgroups: comp.arch Path: utzoo!henry From: henry@utzoo.uucp (Henry Spencer) Subject: Re: Self-modifying code Message-ID: <1988Jul22.164129.5495@utzoo.uucp> Organization: U of Toronto Zoology References: <5254@june.cs.washington.edu> <76700032@p.cs.uiuc.edu> <1988Jul18.231158.19500@utzoo.uucp> <302@laic.UUCP> Date: Fri, 22 Jul 88 16:41:29 GMT In article <302@laic.UUCP> darin@laic.UUCP (Darin Johnson) writes: >... a hardware BitBlt using DMA can be operating while the CPU is >servicing other processes, with no slowdown in CPU speed... 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". (Caches help a lot on instruction fetches, but data has this annoying tendency to require real memory fetches.) If your CPU is sitting there waiting for memory, it might as well be doing the BitBlt itself. >...the Amiga blitter can do >logical operations (on three inputs) just as fast as a normal memory >copy - It'd be pretty hard to hack some 680x0 code to XOR three inputs >and write to three outputs as fast as it can move memory. True, but who cares? The overwhelmingly common cases of BitBlt are doing an operation like writing a character, where the software overhead of deciding what to do totally dominates doing it, and bulk movement of bits, where a straight copy operation can run memory-bound on a well-built box with any good implementation. >Also, the >overhead is very low compared to the overhead involved in dynamic compilation. See previous paragraph. The Blit code does not do dynamic compilation for the small cases where overhead is dominant anyway (when you're drawing a character, you are only moving a few words of data, and figuring out which words to move is much harder than actually doing it, regardless of whether the actual doing is hardware or software), only for the big ones that can amortize the overhead well. BTW, the overhead is smaller than you think. >If dynamic-compilation is that much faster, then you would have expected >someone to have written a program that does uses this technique on the Amiga, Yes. Hence my harsh words about the competence of the people involved. Note that doing a really good software BitBlt is A LOT OF WORK -- it's not 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). 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. -- Anyone who buys Wisconsin cheese is| Henry Spencer at U of Toronto Zoology a traitor to mankind. --Pournelle |uunet!mnetor!utzoo! henry @zoo.toronto.edu