Path: utzoo!yunexus!geac!daveb
From: daveb@geac.UUCP (David Collier-Brown)
Newsgroups: comp.arch
Subject: Blit (was Re: Self-modifying code)
Message-ID: <3089@geac.UUCP>
Date: 28 Jul 88 11:59:10 GMT
Article-I.D.: geac.3089
References: <1152@ficc.UUCP>
Organization: GEAC Computers, Toronto, CANADA
Lines: 37


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.

From article <1152@ficc.UUCP>, by peter@ficc.UUCP (Peter da Silva):
|    "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."

Ok, we have a disagreement, but not over self-modifying code...

peter continues:
|  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.

  If you will have a look at Foley & Van Dam[1], you will notice a
cycle of main cpu software -> added hardware assist -> auxiliary
special-purpose cpu -> auxiliary general-purpose cpu -> upgrading of
the auxiliary cpu to a "main" cpu and then around the circle again.

  This tends to imply that there are ***AT LEAST*** two solutions to
the cost-performance equation for graphics displays.  

  Maybe we can agree to disagree? (not that this discussion wasn't
interesting and fruitful, just that its starting to sound a little
acrimonious...)

--dave c-b
[1] A computer graphics textbook, currently setting on my shelf at
    home. Eggs expected any day now.
-- 
 David Collier-Brown.  {mnetor yunexus utgpu}!geac!daveb
 Geac Computers Ltd.,  |  Computer science loses its
 350 Steelcase Road,   |  memory, if not its mind,
 Markham, Ontario.     |  every six months.