Path: utzoo!mnetor!uunet!husc6!mit-eddie!bbn!rochester!PT.CS.CMU.EDU!IUS1.CS.CMU.EDU!edw
From: edw@IUS1.CS.CMU.EDU (Eddie Wyatt)
Newsgroups: comp.arch
Subject: Re: RISC is a nasty no-no!
Message-ID: <1047@PT.CS.CMU.EDU>
Date: 5 Mar 88 18:38:23 GMT
References: <179@wsccs.UUCP: <696@nuchat.UUCP> <284@scdpyr.UUCP> <1970@epimass.EPI.COM>
Sender: netnews@PT.CS.CMU.EDU
Organization: Carnegie-Mellon University, CS/RI
Lines: 36


   First comment about induction on loop variables.  Even if 95% of
array usage fits into this category, not all those applications
may use it (or at least not without some serious dataflow analysis).
As soon as a procedure or function call appears within the body
of a loop, one can nolonger assume nice behaviour of induction
variables or base address.  I'm refering to the problems of aliasing.

> 
> No, the compiler doesn't have to do things that way.  It can create
> an extra row of pointers to the beginning of each row:  p_foo[n],
> where p_foo[i] contains &foo[i][0].  Then foo[i][j] is at *p_foo[i] +
> j.  No multiply required, but there might be a shift or two to
> accomodate two-byte or four-byte array elements.  The old Fortran
> compiler for PDP-11's running RT-11 had an option to do this:  you're
> trading off speed for space.  They called it "array vectoring".  The
> array itself is still allocated the way you think it is, but there
> are extra pointers.

   Interesting thought there - replace the representation.  It may 
have been easy to do for fortran, but it seems to me that C may
have some features that wouldn't allow it (or at least make it
a pain in the ass).  One is the interchangablity of pointer and
array.  Currently this is permissible (and easliy done) because
the reps are the same - pointers to the data blocks.  Therefore
a array may be passed to a function that expects a pointer (and still
have reasonable things happen).  If an optional rep is used,
the problem of parameter passing becomes determining which rep is
intended to be used.  Since function discriptions currently
are not required to be within scope of the call, a correct choice
can not be made.


-- 

Eddie Wyatt 				e-mail: edw@ius1.cs.cmu.edu