Re: Suggestion for down-the-road designs

[Penio Penev <penev>]

On Mon, 29 May 1995 john.r.strohm@BIX.com wrote:

> Is there a way to make the "pattern vs. number" dichotomy go away?

> I understand it is there because it makes for faster hardware in certain
> pathological cases.  

It is there to make for _twice as fast_ hardware for _all_ ALU cases. And
it reduces the count of transistors (and energy dissipation) in the ALU
twice, as I understand it. I don't know whether it reduces over-all memory
width, but most definitely, it simplifies the hardware tremendously.

I don't think, that the patterns vs. numbers issue will go away in future
designs. It is plain too costly to sacrifice the die area, speed and power
dissipation for something that can be easily dealt with in software at
_compile_ time. 

And the dichotomy is not as important as one could think at a first glimpse
of the specs. 

There are two realms -- computations and I/O. As long as one stays 
within a realm, they cannot feel the other realm's representation.

If one deals with I/O only, nothing should be done. What one should Output
is what one did Input. 

If one deals with computations, 2 + 2 = 4 and that's it. PC+=offset is the
command to calculate the jump address, as usual. 

The only consideration arises, when one has to do calculations on I/O
data. One might think of the I/O data as a separate data type, which needs
separate operators to be dealt with. The notion of data types is hardly
unfamiliar to the computing industry (to the software gang at least). 

One could either use "typed" operators to perform arithmetic/logic on the
new data type, or make a type conversion (cast the data into another type)
and use regular arithmetic. (Whether the two ways to think of the problem
are different in their essence, this is up to the engineer to decide.)

Suppose one wants to draw a LINE of certain color in a certain mode (XOR,
AND, replace) at a certain position in the current window. In all cases the
routine for this calls PIXEL (or PLOT) which takes care of the frame
buffer details, so LINE and everything above it cannot even sense the
fact, that the dichotomy exists.  This view isn't very different from the
view of drawing in a VGA frame buffer, or an X-Windows frame buffer for
that matter. 

--
Penio Penev <Penev@venezia.Rockefeller.edu> 1-212-327-7423