On Mon, 6 Jun 2005, Malcolm J. Currie wrote:
> > 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.
>
> So if astronomers continue to programme with DYN_ELEMENT instead of
> %VAL/CNF_PVAL, they'll come unstuck on 64-bit machines, unless they
> switch the 32-bit compiler option. That's fine with me.
And me, although it's a little trickier than that. They will require
a complete development tree built using -m32. That'll teach them.
> I made a start converting the many DYN_ELEMENT calls to %VAL/CNF_PVAL,
> and changing some private workspace calls to invoke DSA_GET_WORK_ARRAY
> to accept normal pointers instead of elements in DYN_ELEMENT. In some
> places I did this sometimes multiple times rather than doing address
> arithmetic in the application code. The TWODSPEC code will need
> changing so its dynamic elements passed through a COMMON block are
> traditional pointers.
OK, didn't appreciate you'd started that. I'll move the work below up a
notch.
> Testing this stuff is a concern.
Too right.
> Does anyone have a test suite/data for TWODSPEC? There is a SPECDRE
> demo from an AstroFest a decade ago that might be adapted to exercise
> its modified code, now part of Figaro.
No.
> > > 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.
>
> Yes I know there's nothing in Fortran 77, just thought that there might
> have been a modern extension in keeping with the DOUBLE PRECISION over
> REAL*8.
Well in Fortran 90+ you can ask for a KIND that can handle a given range
of data values (SELECTED_INT_KIND(R), with range -10**R to 10**R), but
that still lacks an explicit type with a double sized INTEGER by default.
> > 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).
>
> Well I'm sure you prefer that over changing hundreds of DYNAMIC_MEMORY
> calls and other related changes. There were more than I thought because
> some people wrote lower case Fortran code.
No arguments there.
Cheers,
Peter.
|