Path: utzoo!utgpu!attcan!uunet!mcvax!enea!diab!pf
From: pf@diab.se (Per Fogelstr|m)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <401@ma.diab.se>
Date: 28 Jul 88 08:35:15 GMT
References: <5254@june.cs.washington.edu> <76700032@p.cs.uiuc.edu> <480@m3.mfci.UUCP>
Reply-To: pf@ma.UUCP (Per Fogelstr|m)
Organization: Diab Data AB, Taby, Sweden
Lines: 19

In article <480@m3.mfci.UUCP> colwell@mfci.UUCP (Robert Colwell) writes:
>I think it comes down to what Henry already said -- if your blit is
>already saturating memory bandwidth, you don't need hardware (hard to
>believe that the CPU is going to get anything useful done if no
>memory bandwidth is available, so the co-processor rationale is a
>weak one when memory is shared).  But at least in my case, memory
>bandwidth could not possibly be saturated by just the CPU.
>
I disagree !  If a specialized "hardware" can do a BitBlit at least twice
as fast (and propably even faster) than the CPU you will always have 50%
or more CPU time left than if the cpu was doing the job itself. Note that
a good designed Blit can saturate the memory bandwidth with no problem.
The design i'm working with right now Blits 80-90 kpixels (depth unlimited)
per second with a 16 bit bus and 100ns dynamic rams. This means it can scroll
a 1024 x 1024 screen in 10ms, less than one display time, and it can move
windows on the screen in real time as the Intel GPC does with hardware
windows. Do that with the CPU. Even with external hardware the CPU will not
be able to generate the addresses fast enough. (You have to generate a new
address each 50-100ns).