 |
 |
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.