Henning Thielemann wrote:
> When working on wrappers for the FFTW library I encountered several
> problems that may require some sort of hacks ...
>
> 1. How to wrap an open C array with fix dimensionality by a Modula-3
> array?
>
> libfftw provides a function to allocate memory at SIMD friendly memory
> locations. I like to use this function and wrap the pointer to the C
array
> by a Modula-3 open array. It would be nice if this array could also be
> traced by the Garbage collector. Of course I want to use as little
> knowledge about the internals of open arrays as possible, so I searched
> the RT (runtime) modules of m3core for a function that does the
wrapping.
> But I didn't found one.
Well, I have some thoughts on this, having once looked at open array
representation.
If you are satisfied to also wrap the subscript operations, i.e.
require your user to make procedure calls to do subscripting, then you
should be able to avoid getting into the M3 RT representation. If
you want to turn these into real M3 open arrays, so that your users
can use, for example, "A^[I]" on them, I don't think you can avoid
getting into the internals.
The compilers (all of them, I think) represent open arrays by what
I will call "dope". It consists of a pointer to element [0,0,...,0]
of the actual array, followed by N words containing the element count
of each of the N dimensions. It can only be either an autonomous heap
object, or a formal parameter. (Also, maybe some tem****ary values could
exist, too). If it is a heap object, the space for the elements
always follows the dope, and is all allocated with it. Thus, the pointer
is really redundant, in this case.
If it is a parameter (or tem****ary), the elements could be somewhere
else. This could happen, e.g., if the actual parameter was a fixed
array (which has no dope) or a SUBARRAY construct, whose entire
array would either have no dope, or the wrong dope.
You could provide a procedure to construct dope for an open array,
with the element pointer pointing to the array taht libfftw allocated,
which, of course, would not be in M3's traced or untraced heap. I
think it would make sense to actually add this to some appropriate
interface in the runtime itself, since it could be generally useful.
You would have to check that such objects would not confuse the GC.
I would expect it is already capable of handling open array dope that
points outside its heap, because formals can be that way. But possibly,
it treats open array heap objects differently, and this would have to
be changed.
>
> 2. How to handle arrays of arbitrary dimensions?
>
> The functions RTType.GetNDimensions and RTHeap.GetArrayShape let me
hope
> that it is possible to manage arrays of arbitrary dimension by REFANY
> arguments. But how can I check the index and field type of an ARRAY
type?
> How to wrap the allocation function described above to work with arrays
of
> arbitrary dimension? I think the wrapper needs a TypeCode argument to be
> able to create arrays of a type that the main program knows of.
>
>
While RT routines can manage arrays of nonstatic dimension count, (indeed,
the
procedure I suggested above would be an example), M3 source code can't,
because there is nothing like that in the type system. So anything to
manipulate them would have to wrap the subscripting operations too.
Also, only reference types have typecodes (sec. 2.6.13), so you won't be
able
to detect at runtime, that the element type of an array is, say, INTEGER.
|
