🚀 go-pugleaf

From article <16900@mentor.cc.purdue.edu>, by hrubin@pop.stat.purdue.edu (Herman Rubin):
> 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;
> [...]
> 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.

Oh.  I _still_ misunderstood what you were after.  well, how about this:

   Type int_overlay
      int.32 :: field
   End type int_overlay

   Int.32 :: y(0:Number_of_elements-1)
   int.8  :: x(0:3*Number_of_elements)

   map x as int_overlay

   do i = 0,Number_of_elements-1
      y(i) = x(3*i).field
   end do

Remember what I have said before that mapping is a _storage_ associated
operation.  This code picks up a four byte field every three bytes through
the X array and stores these values in the Y array.  Assuming that 32 bits
is a word alignment, this does one unaligned load of a whole word and one
aligned store of that word per trip through the loop.

> [...]                   It will not work on all machines, but it will be
> much faster on the ones on which it works.

I prefer using portable features whenever possible.  Which is why I
support the addition of features like mappings to existing languages
(or new ones for that matter).  If mappings were available in your
language, the above code would port everywhere.  To be sure, the code
might be very inefficient on hardware which _really_ penalizes unaligned
memory traffic - but your pointer version would be too AND it wouldn't
port everywhere.

J. Giles