Peter,
> conversation back to stardev, as I now think FIGARO is fundamentally
> flawed for working under 64bit, that is cannot be fixed without
> significant effort.
Not sure whether to smile or cry.
> The problem seems to be that FIGARO uses a non-standard trick when dealing
> with allocated memory, that essentially means that we must carry the
> offset between two memory addresses in a Fortran INTEGER. This is the same
> problem as carrying a single memory address (wishful thinking aside).
Keith admits in the "Figaro Programmer's Guide" that both DYNAMIC_MEM
and %VAL are tricks, that they can coexist, and if we really want to use
%VAL "do go ahead". Keith's main argument against %VAL is portability,
being a DEC Fortran invention. Well 15 years on, most Starlink Classic
applications use %VAL while VMS is a fleeting rosy memory, and they're
still going strong on a variety of operating systems, not just the VMS
we had at that time.
As previously indicated there are a similar number of %VAL constructs
in Figaro as DYNAMIC_MEM.
> The only solutions I can think of for this are to change FIGARO to use
> %VAL and CNF_PVAL instead of DYN_ELEMENT throughout,
It's a little more involved where address offsets are computed
(DYN_INCREMENT) and workspace is involved (DSA_GET_WORKSPACE).
> I guess the immediate question is, how is this going to impact JAC? Will
> FIGARO be used under AMD64 (I assume the SuperWASP chaps can move to
> KAPPA).
We tried to limit the Figaro usage to those applications available
nowhere else, particularly related to spectra. The exposure isn't
large.
As for the community in general, they might notice the effect of
Starlink's demise sooner rather than later, if we don't make this switch
to %VAL.
Malcolm
|