On 2009-02-12 15:01-0700 Orion Poplawski wrote:
> Orion Poplawski wrote:
>> #2 0x0000000010001e84 in x23f ()
>> at /builddir/build/BUILD/plplot-5.9.2/fedora/examples/f77/x23f.f:326
>> 326 call plsfci(0)
>>
>
> This is clearly wrong. plsfci takes a 64-bit integer. The attached patch
> fixes. The x23f.f90 example uses "0_plunicode" to specify the type. I don't
> know if "PL_INT_0" is the best name, but it shows the general solution.
Hi Andrew,
I mostly address this to you since you were the pl[gs]fci implementer for
most languages (as discussed in a thread started by you last July 31). At
the time, I found a similar error to Orion's for the f95 case, and you
almost immediately found a fix. At the time we were overly focussed on just
getting something to work, but in retrospect I have some questions about the
whole approach taken to deal with the f77 bindings (and probably other
bindings as well) for pl[sg]fci.
I notice the following comment from you in bindings/f77/scstubs.c.
"Note: Fortran does not have unsigned integers so we need to use a
64 bit signed integer which corresponds to a fortran integer*8
in order to contain the number."
Could you explain that comment? My question is why is it necessary to use
the 64-bit type PLINT64 at the C level of the f77 interface (and therefore
64-bit types in all calling fortran routines) when only 32-bits are actually
required to store the unsigned bit pattern?
According to "info gfortran" typeless BOZ constants (i.e., binary, octal, or
hexadecimal bit patterns) are allowed anywhere that ordinary integers can be
used, and there is a similar statement in the Intel fortran compiler
programmer's reference. For gfortran I tried the following simple test
code:
integer*4 hello
hello = Z'80000001'
write(*,*) hello
end
That would not compile by default. It complained about an overflow. I think
that is a gfortran implementation error since the size of the BOZ constant
on the right is not larger than the size of the integer*4 on the left, and
no such error would have occurred it I had said
hello = -2147483647
instead. However, when I specified the option -fno-range-check, the above
source code compiled, and the resulting executable gave the correct result,
-2^31 + 1 = -2147483647. I assume from the writeup in the Intel Fortran
programmer's reference manual, you would get the same result from Intel
Fortran (and perhaps other modern Fortran compilers as well?). In any case,
using a typeless BOZ constant to make sure the most significant bit is set
to mark the integer as an FCI is an unlikely case which normally would not
happen since if you don't specify that FCI marker, the C code for plsfci
applies it anyway. Also, when you look at plgfci, it should just fill the
4 bytes of memory with the appropriate bit pattern, and I cannot see what
could go wrong if those 4 bytes of memory were integer*4.
Anyhow, I am tentatively concluding we should be doing absolutely nothing
special at the f77 interface level to deal with pl[sg]fci. We simply want 4
bytes sent to the C library or returned from it, and integer*4 should have
sufficient storage for the task, if we don't interfere at the interface
level to translate to 8 bytes and that back to 4 bytes again.
Andrew, do you see anything obviously wrong with the simple approach I just
outlined for transferring a 4-byte bit pattern from the f77 level to our C
library and back again?
Alan
__________________________
Alan W. Irwin
Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).
Programming affiliations with the FreeEOS equation-of-state implementation
for stellar interiors (freeeos.sf.net); PLplot scientific plotting software
package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of
Linux Links project (loll.sf.net); and the Linux Brochure Project
(lbproject.sf.net).
__________________________
Linux-powered Science
__________________________
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
