On Mon, 6 Jun 2005, Tim Lister wrote:
> > ------- Additional Comments From [log in to unmask] 2005-06-06 17:08 -------
> > Hi Tim,
> >
> > what you need to do is wrap your %VAL calls like this:
> >
> > call acc_vignet( xaxis,yaxis,nx,ny,%val(cnf_pval(imgptr))
> >
> > you get the CNF_PVAL declaration from:
> >
> > include 'CNF_PAR'
> >
> > This performs the magic of expanding the value stored in imgptr
> > (which can only be 32bits wide) into the proper address. It's not
> > needed on 32 bit platforms as imgptr is the address.
>
> Ok, does this evaluate to a no-op on 32bit machines ? I don't want to
> break the rest of the SW consortium's reductions as I'm currently the
> only one mad^H^H^Hdaring enough to try things on 64bit and I don't want
> 2 groups of people accusing me of breaking things !
Hi Tim,
yes, CNF_PVAL is a noop on 32 bit, so it's safe to change all your %VAL
calls to use it.
> > That should be all that's needed, unless you're playing complicated
> > games with memory addresses, like determining your own offsets.
> >
> > Mark's document describes how we intended to move completely to 64 bits,
> > including accessing memory well in excess of 2Gb, but we've never
> > actually implemented any of it (beyond CNF_PVAL address handling), so
> > use it with caution. The only other official explanation of how to
> > handle address width problems is in SUN/209 (CNF), but that's probably
> > a little fullsome for most people.
>
> The code in question takes a lot of memory (it reads a cube of
> flatfields in) but I hope it won't need more than 32bit memory
> support...
Well, if you do find it needs more, then clearly you'll need to take more
care with how it handles memory, but you may run into problems with
NDF/HDS before that happens (depends on the size of your images and how
you access them and use temporary files). We are developing a 64bit
version of the HDS data file format to fix that.
Cheers,
Peter.
|