Array Descriptor Update

Paul Thomas paul.richard.thomas@gmail.com
Fri Sep 26 12:29:00 GMT 2008


Daniel,
> If I understand you correctly, we would have one type of descriptor 
> that would be used for allocated arrays as well as allocatable scalars 
> and CLASS pointers/pointees, so that would be "the" place to store the 
> runtime type token?
That's what I was suggesting. This is such a descriptor, based on Intel's.

typedef struct
{
  size_t extent;       ! No of elements
  size_t stride;       ! distance between elements in bytes
  size_t lbound;       ! lower bound
}
gfc_dimension;

typedef struct
{
  type *data;          ! base address
  size_t size;         ! size of an array element in bytes
  void *offset;        ! offset to the start of the array
  size_t flags;        ! allocated/can be deallocated/contiguous
  size_t rank;         ! 0-7
  size_t type_key;     ! key based on type name + module name
  gfc_dimension *dimension;  ! [rank]
}
gfc_array_descriptor;

I have proposed size_t for consistency with Intel.... as I understand it:-)
>
> As you mentioned character lengths, maybe we should think about length 
> type parameters in general for this project?  But that's just an 
> associative thought, I've no idea at the moment about what length type 
> parameters really impose on the compiler.
The above descriptor could, in principle, represent character arrays and 
scalars.
> I can't answer your original question, but I believe this information 
> is not really "needed" as the type is compile time known and gfortran 
> can insert the appropriate handling for the type at compile time; I 
> guess that's why we don't need it...  But with your proposal for 
> polymorphic entities, we would want to carry a runtime type.  I guess 
> we could probably drop the static type information (for CLASS(t) it 
> would be "t") and replace it by the dynamic one (the runtime type).
At present, the DTYPE field is only long enough to allow for the 
intrinsic types.  Also, I suspect, it is assiduously written and copied 
but then not used .... that was my question.
> What I heard from the talk about 4.3 ABI breakage, I got the idea that 
> in the past each major version of gfortran broke it anyways (maybe 
> except the upcoming 4.4 now?).  So for a descriptor rework in favor of 
> new features like allocatable scalars or CLASS, I would see it 
> reasonable to simply go along and do the best of design we can come up 
> with, not introducing any kludges to try preserving the ABI.  But 
> that's of course only my personal opinion, as someone who didn't 
> really use any Fortran for large projects yet and does not have any 
> compiled code lying around...
I suppose that we could, horror of horrors, have a 
-fuse-oldtime-descriptors???

The task of conversion is going to be big and this will be an 
industrial-scale regression causer.  That said, I think that it would be 
worth it, as you say.  I guess, in addition, that we should change to 
TREE-SSA array types whilst we are about it?

Cheers

Paul





More information about the Fortran mailing list