Path: utzoo!utgpu!water!watmath!clyde!att!ucbvax!pasteur!ames!killer!elg From: elg@killer.DALLAS.TX.US (Eric Green) Newsgroups: comp.arch Subject: Re: Self-modifying code Message-ID: <4912@killer.DALLAS.TX.US> Date: 25 Jul 88 00:04:23 GMT References: <1988Jul22.164129.5495@utzoo.uucp> Organization: The Unix(R) Connection, Dallas, Texas Lines: 77 in article <1988Jul22.164129.5495@utzoo.uucp>, henry@utzoo.uucp (Henry Spencer) says: > 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". 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). Given the cost constraints, and the state of technology in 1984, it made a lot of sense to have a hardware blitter. The fact that the Blit terminal did fast blits without a blitter probably has more to do with the fact that a) the machine was designed before modern high-speed DRAMs, when 250ns RAMs were fast, and b) the machine had a much higher resolution screen than the Amiga, meaning that much more bus bandwidth was taken up with video refresh (thereby improving the desirability of caching the loop, since you couldn't do data accesses any faster anyhow). > If your CPU is sitting there waiting for memory, it might as well be doing > the BitBlt itself. At least with the 68000 and modern DRAMs, the memory spends most of its time waiting for the CPU! > 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. Memory-bound? Yes, if you're using a 68020 or 68030 with a tight loop that'll fit into their internal cache. But the 68000 would spend half of that bandwith simply fetching instructions, not moving bits.... > 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). True, the majority of the micro world thinks multitasking is a neat idea, message passing is what secretaries do, etc. But first time I ever heard the designers of the Amiga accused as such (the Amiga, BTW, was NOT designed by Commodore). Considering that they implemented such nifty state-of-the-art ideas as a message-passing multi-tasking OSetc. (only to ruin it all by commissioning a cruddy filesystem), and considering that they all had Suns on their desktops when they were designing it, it sounds like you're being harsh for no good reason, considering the design constraints (512K RAM, under-$1500 price, etc. > 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). 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). -- Eric Lee Green ..!{ames,decwrl,mit-eddie,osu-cis}!killer!elg Snail Mail P.O. Box 92191 Lafayette, LA 70509 PC Pursuit: Or, How to Eat the Typist's Echo in Three Words or Less.