Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ll-xn!mit-eddie!jbs
From: jbs@eddie.MIT.EDU (Jeff Siegal)
Newsgroups: comp.arch
Subject: Re: RISC is a nasty no-no!
Message-ID: <8332@eddie.MIT.EDU>
Date: 1 Mar 88 03:49:01 GMT
References: <179@wsccs.UUCP: <696@nuchat.UUCP: <284@scdpyr.UUCP> <25699@linus.UUCP> <11199@duke.cs.duke.edu> <25723@linus.UUCP>
Reply-To: jbs@eddie.MIT.EDU (Jeff Siegal)
Organization: MIT, EE/CS Computer Facilities, Cambridge, MA
Lines: 35

In article <25723@linus.UUCP> bs@gauss.UUCP (Robert D. Silverman) writes:
>In article <11199@duke.cs.duke.edu: dfk@duke.cs.duke.edu (David Kotz) writes:
>:Multiplication is not necessary to access 2-D arrays if the array is
>:set up like most arrays in C, where each row is a typical vector and
>:the 2-D array is just a vector of pointers to each row vector. Then
>
>This isn't intended as a flame but your response is too 'language dependent'.
>Not all code is written in a language that has pointers. 

There is nothing language dependant about row vector representation of
2-d arrays.  It is an implementation tool (i.e. the compiler writer,
library writer, or software archetecture designer deside such a
thing).  Once implemented in the system innards, the programmer need
not be concerned with it (i.e. you still reference a[x][y] or a[x,y]
or whatever).  Of course, C gives you the ability to represent your
"arrays" this way even when the built-in array representation doesn't.

Even without doing any pointer dereferencing, it is easy to avoid
doing any multiplication by having the compiler set up a table giving
the address offset of each row of the array.  So a[x][y] is found at
address:

a + offset[x] + y

>Please. We are discussing hardware, not software. Let's not introduce
>language dependencies. Your solution also fails to address those numerical
>problems that have multiplies in them.

True, there is no answer that is going to address this problems short
of specialized hardware.  I think it's pretty obvious that for
applications which primarily multiply, you want fast hardware support
for multiplication.  Machines without such support are compromising
multiply performance for better performance at (hopefully) more common
operations like register loads and stores, comparisons, adds, etc. 

Jeff Siegal