On Fri, 3 Jun 2005, Malcolm J. Currie wrote:
> 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.
Hi Malcolm,
the function has to return an INTEGER, as that's what all the variables
that use its result expect. If we wanted a 64 bit friendly solution, we
would indeed need to change this to return INTEGER*8, along with
DYN_INCREMENT and DSA_TYPESIZE (and maybe more?) and change all the
references to them (and uses of the result) to use INTEGER*8. I stopped at
that thought and decided throwing DYN_ELEMENT in the bin and using
%VAL/CNF_PVAL was a better idea.
(Another killer thought is that in FIGARO the DYNAMIC_MEMORY array is
declared BYTE and indexed by an INTEGER, so any FIGARO program that used
the DYN_ELEMENT scheme can never address memory more than +/-2Gb away from
the base address of DYNAMIC_MEMORY, so even making it return INTEGER*8
isn't quite as useful as you might expect).
> 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?
As Mark said, nope, INTEGER*8 is an extension.
> > > 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.
Err, thanks. Since we probably want some backwards compatibility, we'll
need a new function to do this job. I'll have a closer look at this
(sometime soon).
> 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.
Indeed, this should all be based on the PRM contants.
> Meanwhile the %VAL changes are 85% done.
Good.
|