Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!ncar!ico!rcd
From: rcd@ico.ISC.COM (Dick Dunn)
Newsgroups: comp.arch
Subject: Re: Self-modifying code (and bitblt)
Summary: What to do while waiting for the bitblt?
Message-ID: <7439@ico.ISC.COM>
Date: 22 Jul 88 00:08:13 GMT
References: <5254@june.cs.washington.edu> <76700032@p.cs.uiuc.edu> <302@laic.UUCP>
Organization: Interactive Systems Corp, Boulder, CO
Lines: 30

> > >You can save an even greater factor by building the BitBlt into the
> > >hardware....
> > No.  You can save a large factor over *poor* software implementations of
> > BitBlt...
> However, a hardware BitBlt using DMA can be operating while the CPU is
> servicing other processes, with no slowdown in CPU speed...

First, that's only true if either the bitblt is being done to *and* from
memory not accessed by the CPU, or the memory bandwidth is high enough to
handle both the CPU and the bitblt DMA cycles.  I'd guess that's rare; we
seem to be afflicted with memory-bound CPUs in a lot of systems.

But more importantly, in many cases you can't do anything else because
either (a) there's only one process running or (b) you can't afford the
context-switch time.  Unless you get a bitblt operation that takes longer
than *two* context switches (out and back), it costs more.  For the case
where you're bitblting characters (probably the most common case), you will
lose big.

> 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,
> rather than using the blitter.  So far, I haven't seen any...

Ummm...but what does this prove?  Not much, I think, until someone actually
tries it and finds out whether it's slower.  Given that the Amiga already
has a useful bitblt (of whatever form), there's no great incentive to write
another.
-- 
Dick Dunn      UUCP: {ncar,nbires}!ico!rcd           (303)449-2870
   ...Are you making this up as you go along?