Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!samsung!noose.ecn.purdue.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.misc
Subject: Re: Pointers vs. arrays
Summary: This does not umay not be as efficient
Message-ID: <16900@mentor.cc.purdue.edu>
Date: 20 Nov 90 13:35:09 GMT
References: <2742@l.cc.purdue.edu> <6291@lanl.gov>
Sender: news@mentor.cc.purdue.edu
Lines: 53

In article <6291@lanl.gov>, jlg@lanl.gov (Jim Giles) writes:
> From article <2742@l.cc.purdue.edu>, by cik@l.cc.purdue.edu (Herman Rubin):
> > [...]
> > 	*y++ = *x++;
> >         decrease x, treated as a byte pointer, by 1;
> 
> Ok.  I see now.  I interpreted your initial request differently.
> The equivalent non-pointer version is (including the declarations
> you left out):
> 
>       bit.32 :: y(Number_of_elements)
>       bit.24 :: x(Number_of_elements)
>       ...
>       do i=1,Number_of_elements
> 	 y(i) = x(i)
>       end do
> 
> > [...]
> > This uses one unaligned read and one aligned write, as compared to
> > three reads and writes.
> 
> So does my version.  At least, assuming that 32-bit numbers are
> aligned.  (Note: 'bit' data types are unsigned; for signed integers,
> the declaration is 'int'.  Your use of pointers is thus seen as
> an example of needing to get around restrictions caused by inadequate
> control over data types.)

Your version may be far less efficient, depending on the hardware.  At
least on some hardware, an unaligned read is not that much slower than
an aligned read.  Also, the instruction sequences are different.  Mine
says to take 4 bytes at a particular location and move them to another,
and then change the pointer for the source location.  Yours says to form
a 3 byte unit at a given location, and move them into the three bytes
at the destination.

As far as the result, there is no important difference.  But as far as
the implementation, there will be.  Yours would be interpreted as taking
those 3 bytes only, and moving them to the destination, with some convention
about the 4-th byte at the destination.  Mine will take 4 bytes, and just
move them to the destination.  It involves no processing, other than getting
and putting the bytes.  It will not work on all machines, but it will be
much faster on the ones on which it works.

Now conceivably something could be added to the language to allow the
unaligned read/aligned write procedure if the hardware will permit it.
But it still takes the programmer to let the compiler know this.  There
are other situations calling for unaligned reads/writes if they can be
done.  Pointers allows the user who understands the hardware to implement
them.
--
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)