Tim,
Some observations:
1) The "%VAL( CNF_PVAL( IPBIN ) + IPIBN )" approach would probably be the
faster to implement since it has no implications for the configure
system.
2) No work on the configure system == less work for Norman == TimeFrame
available sooner!
3) There are many other places in several packages where this sort of
pointer arithmetic is performed. The ones I've come across use the
%VAL( CNF_PVAL( IPBIN ) + IPIBN )" approach. To change to the FPOINTER
approach consistently would require a lot of work.
4) You're right that the FPOINTER approach is neater. Maybe we should look
to adopt this approach consistently when time is not so pressing. The
only comment is that it looks odd that PSX converts C pointers to F77
integers, and the FPOINTER approach would immediately turn them back into
C pointers. Maybe we should add a tuning parameter to PSX saying whether
we want the memory allocation routines to return F77 integers or C
pointers?
So, overall, given the pressures we are under at the moment, I would
probably go for the least effort approach, which is probably the
%VAL( CNF_PVAL( IPBIN ) + IPIBN ) approach.
Doing a grep for "VAL__NB" shows that POLIMAGE also suffers from this
problem. Grepping in KAPPA shows that MEM2D has serious problems of
this kind (kapsub/kps1_memcp.f). MLINPLOT did suffer from this problem,
but I fixed it the other day, using the %VAL( CNF_PVAL( IPBIN ) + IPIBN )
approach. The other fortran applications look clean, so it looks like I am
the sole perpetrator of this crime!
Not really knowing how the Figaro "dynamic_mem" thing works, I'm not sure
about figaro, but I did come across things like:
work2 = work1 + ni*val__nbr
call gen_nfillf(ni,dynamic_mem(work2))
which look suspicious.
David
On Mon, 22 Nov 2004, Tim Jenness wrote:
>
> David,
>
> Just realised that the CNF_PVAL-ification of POLBIN doesn't work at all.
> The problem is that it uses pointer arithmetic extensively whilst storing
> the answers to that pointer arithmetic in INTEGER*4.
>
> I started fixing up POLBIN to store the offsets in the variables that
> were previously treated as pointers (eg IPI and IPX) and this will work
> except there are a lot of them and the code isn't going to be very neat
> when I'm done, or as flexible (since the subroutines will need to be
> called with both the base pointer and the offset so switching data arrays
> may require if blocks on both the base and the offset).
>
> ie things such as
>
> IF( CIRC ) THEN
> CALL PSX_CALLOC( NBIN*2, '_REAL', IPBIN, STATUS )
> IPIBN = IPBIN
> IPVBN = IPBIN + NBIN*VAL__NBR
> NSTOKE = 2
> STOKES = 'IV'
> ELSE
> CALL PSX_CALLOC( NBIN*3, '_REAL', IPBIN, STATUS )
> IPIBN = IPBIN
> IPQBN = IPBIN + NBIN*VAL__NBR
> IPUBN = IPBIN + 2*NBIN*VAL__NBR
> NSTOKE = 3
> STOKES = 'IQU'
> END IF
>
> become
>
> IF( CIRC ) THEN
> CALL PSX_CALLOC( NBIN*2, '_REAL', IPBIN, STATUS )
> IPIBN = 0
> IPVBN = NBIN*VAL__NBR
> NSTOKE = 2
> STOKES = 'IV'
> ELSE
> CALL PSX_CALLOC( NBIN*3, '_REAL', IPBIN, STATUS )
> IPIBN = 0
> IPQBN = NBIN*VAL__NBR
> IPUBN = 2*NBIN*VAL__NBR
> NSTOKE = 3
> STOKES = 'IQU'
> END IF
>
> CALL BLAH( %VAL( CNF_PVAL( IPBIN ) + IPIBN ),
> %VAL( CNF_PVAL( IPBIN ) + IPQBN ))
>
> The neatest approach would be to edit POLBIN so that it uses
> a "FPOINTER" type in the decalrations and then make sure that
> sed or cpp pre-process the file to convert FPOINTER to either INTEGER*8
> or INTEGER*4. Then the only edit will be to change the code above to
> read something like
>
> CALL PSX_CALLOC( NBIN*3, '_REAL', IPBIN, STATUS )
> IPIBN = CNF_PVAL( IPBIN )
> IPQBN = CNF_PVAL( IPBIN ) + NBIN*VAL__NBR
> IPUBN = CNF_PVAL( IPBIN ) + 2*NBIN*VAL__NBR
>
> since PSX_CALLOC won't be returning a pointer.
>
> David, which approach is preferred by you? ["ignore 64bit" is not an
> option :-)]
>
> I've given this a wide audience since if the pre-processing approach is
> adopted we really should agree on the notation for "FPOINTER" and have
> a standard way of dealing with this in configure.
>
> --
> Tim Jenness
> JAC software
> http://www.jach.hawaii.edu/~timj
>
>
|