Path: utzoo!attcan!uunet!yale!mfci!colwell
From: colwell@mfci.UUCP (Robert Colwell)
Newsgroups: comp.arch
Subject: Re: Self-modifying code
Message-ID: <480@m3.mfci.UUCP>
Date: 26 Jul 88 12:50:26 GMT
References: <5254@june.cs.washington.edu> <76700032@p.cs.uiuc.edu>
Sender: root@mfci.UUCP
Reply-To: colwell@mfci.UUCP (Robert Colwell)
Organization: Multiflow Computer Inc., Branford Ct. 06405
Lines: 43

In article <1152@ficc.UUCP> peter@ficc.UUCP (Peter da Silva) writes:
>I suppose that if *all* your emmory is on the same bus as your display
>drivers, then this statement is true:
>
>In article ... henry@utzoo.uucp (Henry Spencer) writes:
>> I agree that it's possible to break the hardware in such a way that a
>> software BitBlt is inherently slow.  I prefer unbroken hardware myself.
>
>On the other hand, at a given speed a 68030 can only go so fast. If you
>can let it do other things while another processor is doing the display,
>then why not? Then the statement becomes:
>
>  "I agree that it's possible to break the hardware in such a way that a
>   hardware BitBlt is inherently slow.  I prefer unbroken hardware myself."
>
>I have always been uncomfortable with the idea of having your main CPU
>throwing all those display bits around anyway... hell, given the price
>of the 68030 it might pay Sun to stick an extra one in there to unload
>*all* of the display management from the main CPU.

My blit knowledge is now dated, but when I designed a color version
of the Perq workstation (you remember them, sure you do) I had to
keep the same basic architecture that the Perq already had -- CPU and
display shared main memory.  To get the bandwidth to what I needed I
had to make the display fetch 256 bits at a time from main memory.

Now never mind whether it's a good idea to make CPU and display share
a common memory.  If you *have* 256 bits/fetch, and your rasterop can
handle that, I think it made good sense to provide rasterop hardware.
I couldn't see making the CPU data paths that wide just for pushing
display bits.

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.

Bob Colwell            mfci!colwell@uunet.uucp
Multiflow Computer
175 N. Main St.
Branford, CT 06405     203-488-6090