Re: new proposal to vector intrinsics

[Tobias Burnus <burnus at net-b dot de>]

Sa Liu wrote:
> The type definition will look like this:
>
> type vec_integer (k)
>   integer, kind :: k = 4
>   integer(k) :: vec (16 / k)
> end type
>   
I like this, though I would add a PRIVATE to make the components private
- or is this not needed?

> TYPE ( VEC_INTEGER) :: a,b,c
> TYPE ( VEC_REAL) :: x,y,z
> ! initialize
> integer(4) :: va_i(4) = (/ 1, 2, 3, 4 /)
> integer(4) :: vb_i(4) = (/ 5, 6, 7, 8 /)
> equivalence (va_i, a)
> equivalence (vb_i, b)
>   
I actually think in order to make equivalence or transfer to work, one
should flip the order:

type vec_integer (k)
  integer(k) :: vec (16 / k)
  integer, kind :: k = 4 ! should come second
end type


I think one should also add an "interface assignment(=)" for this to allow:

a = (/ 1, 2, 3, 4 /)
va_i = a

Which looks neater and better defined as equivalence. How is the
assignment handled in xlf? The documentation is rather mute about this
aspect.

> But as far as I know, Gfortran doesn't support parameterized derived 
> types. If the above proposal is in the right direction to a possible 
> solution, we would like to take over the implementation of parameterized 
> derived type.
>   
Indeed, gfortran does not yet support parameterized derived types. And
of cause it it's fantastic that you offer to implement them.

Tobias

PS: What I do not understand is how I/O will be handled. If I understand
it correctly, the xlf version supports unformatted I/O. (The Fortran
2003 way of handling this would be "user-defined derived-type
input/output"; again something which gfortran does not yet support - and
something which seems to be rather complex. Robert Corbett of Sun
regards its implementation as the by far most time consuming feature of
Fortran 2003, which has according to Richard Maine [editor of the
Fortran 2003 standard] the worst cost/benefit ratio. Though, here it
would be useful.)