> > Not sure whether to smile or cry.
>
> Depends, if you get the job of fixing it!
I'll do it but I want to be sure that I know what I'm doing before
embarking. I only want to do edit scores of files the once. Tracking
down all those gratuitous offsets (rather than letting the
infrastructure manage the space) will take some effort.
On the DYN_ELEMENT function that you modified Peter, it's still declared
as INTEGER yet the expression used to evaluate it involves INTEGER*8
terms. I just want to be sure that it's declared correctly.
We use DOUBLE PRECISION rather than REAL*8 and so on (cf. SGP/16 Rule
2.1). Is there no generic term for INTEGER*8?
> > It's a little more involved where address offsets are computed
> > (DYN_INCREMENT) and workspace is involved (DSA_GET_WORKSPACE).
>
> Hah yes, hadn't spotted the DYN_INCREMENT, clearly that will need a bit of
> thinking about. The obvious thing is to CNF_PVAL the passed in "pointer",
> do the offsetting in INTEGER*8, then register the offset pointer with CNF
> and pass the result back...
I'll leave that to you Peter. The type lengths are hardcoded, which
surely must be OS specific. Why isn't DSA_TYPESIZE used? We surely
want to limit this OS-specific information to as few places as possible.
> Looked at DSA_GET_WORKSPACE and it call PSX, so its pointers are already
> CNF versions.
Note that there are two DSA_GET_WORKSPACE routines, one for native DSA
and one for FDA, but both use PSX.
Meanwhile the %VAL changes are 85% done.
Malcolm
|