On Thu, Feb 12, 2009 at 04:14:57PM -0800, Alan Irwin wrote: > 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?
The real problem is that PLUNICODE was defined as a unsigned 32-bit integer. Many languages, including fortran do not have unsigned types, and so we only have 31 bits available for the value. The fact that the top bit is always set in an fci character means that we can never represent these numbers using a 32-bit integer. Of course we can try various tricks casting unsigned integers to a signed integer - which is what you did, but obviously this doesn't work. It is also potentially confusing for the user who queries the value of an fci and doesn't get the value they expect. We chose to go for 64-bit integers for these languages to ensure the values fitted. With hindsight a safer choice would have been to make PLUNICODE an signed 32-bit int, but it's a bit late for that now. > 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? It sounds like your approach would work for at least gfortran and probably ifort. It is not particularly nice, but neither is the current solution. We need to make it clear that fci is only to be thought of as a 4 byte bit pattern. We may run into problems with other compilers at some stage. We will also need to bodge example 23 to print out the fci value correctly. I'm happy for you to give it a try. Andrew > 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 > ------------------------------------------------------------------------------ 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
