[PATCH, gfortran] Re: Cray Pointers

[Mike Kumbera]

On Fri, Aug 12, 2005 at 04:01:26AM +0100, Paul Brook wrote:
> > >POINTER (p,d)
> > >DOUBLE PRECISION d, e(5)
> > >
> > >p = loc(e(1)) + 1
> > >
> > >Will this point to e(2)?  The portland group compiler and your
> > >implementation think otherwise (they will make p point to the byte
> > >following e(1) instead of e(2)), which I wouldn't expect form the
> > >documentation I've read in other places.  From what I've read, I would
> > >expect this to make p point either to the byte 4 bytes behind e(1) or to
> > >e(2) (which lies 8 bytes after e(1)).  If the convention is really to use
> > >byte-sized increments, the documentation should definitely make this
> > >explicit.
> >
> > The convention is to use byte-size increments.  I don't think it's
> > possible to do anything else.  For example, the following is valid:
> 
> My understanding was this this depended which machine you were using. I'm sure 
> I read that the original cray implementation used word (ie. type size) 
> addressing, but later implementations use byte addressing.

That is because the first cray could not address bytes. Later versions of the
compiler generated code to mask and shift words in the Cray to allow byte
addressing. Even when the hardware didn't support it directly.
 
> > integer(4) buffer(1024)
> > real(8) rarray(512)
> > integer(4) iarray(1024)
> > pointer (ipt, rarray)
> > pointer (ipt, iarray)
> > ipt = loc (buffer)
> 
> Really? On many machines buffer might only have 4-byte alignment, so accessing 
> it as an 8-byte float will cause alignment faults.

It's safer to change the first line of the previous example to read:
integer(8) buffer(512)

> I would expect accessing pointees that do not match the pointed-to object type 
> to break aliasing rules. You say that pointees may not alias pointed to 
> objects. What about two different pointees?
> 
> I'm fairly sure the current optimizers will assume that pointees of different 
> types do not alias.
> 
> Is it really legal to declare two pointees with the same pointer? It seems a 
> strange thing to do.

Yep, strange but legal. Here is a small code block from an application that has
use Cray Pointers for 30+ years. It didn't work on ONE commercial compiler in
that time. (That vendor has since fixed their compiler.)

      PROGRAM HELLO
      IMPLICIT  real*8 (d)
      pointer(ipp, d(100))
      pointer(ipp, id(100))
      END

This allows me to use the same memory to access 100 double's or 100 ints in the 
same allocated memory block. (There are times we only at runtime what type/size
the data will be.) This ends up acting a bit like a C union.


> I'd really like to have as much of this covered as possible so we can say what 
> is expected to work, what is explicitly not supported (ie. the user should 
> expect the world to end if they do that), and what is not really supported 
> but should work if you disable optimization.
> 
> > So there's no way to know the size of the data type pointed to by a
> > Cray pointer.
> 
> There's no foolproof way of knowing, but if you assume all arithmetic is done 
> on the pointer directly it should be possible to implement type-size 
> arithmetic. In fact you could implement cray pointers internally as C 
> pointers rather than as integers.

All the codes I have seen assume that arithmetic is done at the byte level.
They increment by sizeof(data_type) because the programmer is the only one
that can know what type of data was really stored in the pointer... 

> 
> However this is something that can be implemented as a followup if there is 
> demand for it.
> > + tree
> > + gfc_conv_cray_pointee(gfc_symbol *sym)
> > + {
> 
> This function needs a comment. So does the if statement it contains. It's not 
> clear what the two different cases are for.
> 
> <in loc1.f90>
> > ! (This was originally in craytest.f90, but was put in a separate file
> 
> This comment can be removed. craytest.f90 never existed in CVS either.
> 
> 
> Have you tested cray pointers and pointees in modules?
> If this is hard to implement it may be acceptable to simply prohibit mixing 
> cray pointers and modules.
> 
> Paul