From: Alan W. I. <ir...@be...> - 2005-04-09 05:49:00
|
The recent AMD-64 fortran troubles were caused by a mismatch between the long type of PLINT (64 bits on AMD-64) and fortran integer*4 which is 32 bits on AMD-64 as well as IA-32, and from its name I believe it is always going to be 32 bits on all platforms. To make sure such mismatches do not happen on any platform, I think what we need is to define PLINT as a 32-bit integer on all platforms. Assuming you all agree with this change, should we implement 32-bit integers following what is currently done for PLUNICODE? The proposed new code would look like this. #if defined(HAVE_STDINT_H) #include <stdint.h> /* This is apparently portable if stdint.h exists. */ typedef uint32_t PLUNICODE; typedef int32_t PLINT; #else /* A reasonable back-up in case stdint.h does not exist on the platform. */ typedef unsigned int PLUNICODE; typedef int PLINT; #endif Arjen and Andrew Roach, I presume for windows that stdint.h does not exist and we would fall through to typedef int PLINT for that case. Do you see any windows issues for such a solution? Maurice, I would appreciate your discussion as well since you probably have the most cross-platform Unix and fortran experience here. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Andrew R. <aro...@ya...> - 2005-04-09 05:55:50
|
At 10:48 PM 8/04/2005 -0700, you wrote: >Arjen and Andrew Roach, I presume for windows that stdint.h does not exist >and we would fall through to typedef int PLINT for that case. MingW has it. I cant speak for VC++ though. -Andrew |
From: <mj...@ga...> - 2005-04-10 07:45:52
|
Alan W. Irwin writes: > The recent AMD-64 fortran troubles were caused by a mismatch between the > long type of PLINT (64 bits on AMD-64) and fortran integer*4 which is 32 > bits on AMD-64 as well as IA-32, and from its name I believe it is always > going to be 32 bits on all platforms. > > To make sure such mismatches do not happen on any platform, I think what we > need is to define PLINT as a 32-bit integer on all platforms. > > Assuming you all agree with this change, should we implement 32-bit integers > following what is currently done for PLUNICODE? The proposed new code would > look like this. > > #if defined(HAVE_STDINT_H) > #include <stdint.h> > /* This is apparently portable if stdint.h exists. */ > typedef uint32_t PLUNICODE; > typedef int32_t PLINT; > #else > /* A reasonable back-up in case stdint.h does not exist on the platform. */ > typedef unsigned int PLUNICODE; > typedef int PLINT; > #endif And thus ends the (nearly) half-year experiment of using PLINT==long. :) You posited at the time that I'd reversed myself on the issue at least once -- I frankly couldn't remember at the time but now consider it likely that it did have something to do with 64 bit architectures. I've been back in 32 bit land for the last few years so it didn't occur to me this time around. Anyway, this looks like a fine way to go, and as vendors increasingly include stdint.h, it should be a no-brainer (aside: stdint.h is part of the C99 standard, but I've read that conformance has been rather slow to arrive). And if vendor-specific treatment is required, it can just be added to the #else stanza as needed. Apparently the following typedefs are guaranteed, for a conforming stdint.h: typedef signed char int8_t; typedef signed int int16_t; typedef signed long int32_t; typedef unsigned char uint8_t; typedef unsigned int uint16_t; typedef unsigned long uint32_t; Also I found the following article to be informative: http://www.embedded.com/shared/printableArticle.jhtml?articleID=17300092 -- Maurice LeBrun mj...@ga... |
From: Andrew R. <and...@us...> - 2005-04-15 11:46:45
|
On Sun, Apr 10, 2005 at 01:39:59AM -0500, mj...@ga... wrote: > Alan W. Irwin writes: > > And thus ends the (nearly) half-year experiment of using PLINT==long. :) > > You posited at the time that I'd reversed myself on the issue at least once -- > I frankly couldn't remember at the time but now consider it likely that it did > have something to do with 64 bit architectures. I've been back in 32 bit land > for the last few years so it didn't occur to me this time around. > > Anyway, this looks like a fine way to go, and as vendors increasingly include > stdint.h, it should be a no-brainer (aside: stdint.h is part of the C99 > standard, but I've read that conformance has been rather slow to arrive). And > if vendor-specific treatment is required, it can just be added to the #else > stanza as needed. > > Apparently the following typedefs are guaranteed, for a conforming stdint.h: > typedef signed char int8_t; > typedef signed int int16_t; > typedef signed long int32_t; > typedef unsigned char uint8_t; > typedef unsigned int uint16_t; > typedef unsigned long uint32_t; > > Also I found the following article to be informative: > http://www.embedded.com/shared/printableArticle.jhtml?articleID=17300092 I've only just picked up this thread having been away. To me it seems this is the way to go though. Using stdint.h should also avoid possible problems with other 64 bit issues in the future. I can for example think of issues to do with metafiles which might not be portable. For now I suggest a configure check for stdint.h. At least for 64bit AMD / itanium systems we can be reasonably sure of a modern C compiler. For other systems the current status quo is probably sufficient. Andrew |
From: <mj...@ga...> - 2005-04-15 14:27:49
|
Andrew Ross writes: > I've only just picked up this thread having been away. To me it seems > this is the way to go though. Using stdint.h should also avoid possible > problems with other 64 bit issues in the future. I can for example think > of issues to do with metafiles which might not be portable. What issues are those? I designed metafiles to be 100% portable from the outset and AFAIK there are no problems. All integers are written out as a specified number of bytes in a specified order, and floats are written out according to the IEEE standard. And both read in exactly as written, of course. There are limits, typically 2^15 for number of polylines, color indices, etc, but those are/should-be enforced in other parts of the code as well. -- Maurice LeBrun mj...@ga... |
From: <mj...@ga...> - 2005-04-15 14:35:18
|
mj...@ga... writes: > Andrew Ross writes: > > I've only just picked up this thread having been away. To me it seems > > this is the way to go though. Using stdint.h should also avoid possible > > problems with other 64 bit issues in the future. I can for example think > > of issues to do with metafiles which might not be portable. > > What issues are those? I designed metafiles to be 100% portable from the > outset and AFAIK there are no problems. All integers are written out as a > specified number of bytes in a specified order, and floats are written out > according to the IEEE standard. And both read in exactly as written, of > course. There are limits, typically 2^15 for number of polylines, color grr.. I mean't number of lines in a [given] polyline. > indices, etc, but those are/should-be enforced in other parts of the code > as well. -- Maurice LeBrun mj...@ga... |
From: Andrew R. <and...@us...> - 2005-04-15 19:41:43
|
On Fri, Apr 15, 2005 at 08:21:42AM -0500, mj...@ga... wrote: > Andrew Ross writes: > > I've only just picked up this thread having been away. To me it seems > > this is the way to go though. Using stdint.h should also avoid possible > > problems with other 64 bit issues in the future. I can for example think > > of issues to do with metafiles which might not be portable. > > What issues are those? I designed metafiles to be 100% portable from the > outset and AFAIK there are no problems. All integers are written out as a > specified number of bytes in a specified order, and floats are written out > according to the IEEE standard. And both read in exactly as written, of > course. There are limits, typically 2^15 for number of polylines, color > indices, etc, but those are/should-be enforced in other parts of the code > as well. OK. That's fine then. I was just thinking off the top of my head of the kind of things that might cause problems. I should have checked the source first. No slur on the metafile design intended. Andrew |
From: Alan W. I. <ir...@be...> - 2005-04-10 08:54:41
|
On 2005-04-10 01:39-0500 mj...@ga... wrote: > Alan W. Irwin writes: > > The recent AMD-64 fortran troubles were caused by a mismatch between the > > long type of PLINT (64 bits on AMD-64) and fortran integer*4 which is 32 > > bits on AMD-64 as well as IA-32, and from its name I believe it is always > > going to be 32 bits on all platforms. > > > > To make sure such mismatches do not happen on any platform, I think what we > > need is to define PLINT as a 32-bit integer on all platforms. > > > > Assuming you all agree with this change, should we implement 32-bit integers > > following what is currently done for PLUNICODE? The proposed new code would > > look like this. > > > > #if defined(HAVE_STDINT_H) > > #include <stdint.h> > > /* This is apparently portable if stdint.h exists. */ > > typedef uint32_t PLUNICODE; > > typedef int32_t PLINT; > > #else > > /* A reasonable back-up in case stdint.h does not exist on the platform. */ > > typedef unsigned int PLUNICODE; > > typedef int PLINT; > > #endif > > And thus ends the (nearly) half-year experiment of using PLINT==long. :) > > You posited at the time that I'd reversed myself on the issue at least once -- > I frankly couldn't remember at the time but now consider it likely that it did > have something to do with 64 bit architectures. I've been back in 32 bit land > for the last few years so it didn't occur to me this time around. > > Anyway, this looks like a fine way to go, and as vendors increasingly include > stdint.h, it should be a no-brainer (aside: stdint.h is part of the C99 > standard, but I've read that conformance has been rather slow to arrive). And > if vendor-specific treatment is required, it can just be added to the #else > stanza as needed. > > Apparently the following typedefs are guaranteed, for a conforming stdint.h: > typedef signed char int8_t; > typedef signed int int16_t; > typedef signed long int32_t; > typedef unsigned char uint8_t; > typedef unsigned int uint16_t; > typedef unsigned long uint32_t; > > Also I found the following article to be informative: > http://www.embedded.com/shared/printableArticle.jhtml?articleID=17300092 Thanks, Maurice, for reminding me of that old correspondence on the previous change. Reviewing that, it looks like the current typedef long PLINT was driven by python/numeric integer array needs. So I believe it will take some additional work to make python/numeric integer arrays compatible with the planned typedef int32_t PLINT for the C library. I don't have time at the moment, but I hope to do that work sometime within the next month. Meanwhile, I will leave things as they are (even though it causes problems for fortran on AMD-64). Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |
From: Arjen M. <arj...@wl...> - 2005-04-11 06:25:53
|
"Alan W. Irwin" wrote: > > The recent AMD-64 fortran troubles were caused by a mismatch between the > long type of PLINT (64 bits on AMD-64) and fortran integer*4 which is 32 > bits on AMD-64 as well as IA-32, and from its name I believe it is always > going to be 32 bits on all platforms. > > To make sure such mismatches do not happen on any platform, I think what we > need is to define PLINT as a 32-bit integer on all platforms. > > Assuming you all agree with this change, should we implement 32-bit integers > following what is currently done for PLUNICODE? The proposed new code would > look like this. > > #if defined(HAVE_STDINT_H) > #include <stdint.h> > /* This is apparently portable if stdint.h exists. */ > typedef uint32_t PLUNICODE; > typedef int32_t PLINT; > #else > /* A reasonable back-up in case stdint.h does not exist on the platform. */ > typedef unsigned int PLUNICODE; > typedef int PLINT; > #endif > > Arjen and Andrew Roach, I presume for windows that stdint.h does not exist > and we would fall through to typedef int PLINT for that case. Do you see any > windows issues for such a solution? Maurice, I would appreciate your > discussion as well since you probably have the most cross-platform Unix and > fortran experience here. > Hello Alan, I can confirm that MSVC/C++, version 6.0, does not include a stdint.h header file. There is apparently no alternative header file either defining such integral types. Something that has me worried a bit is whether there is a difference on the AMD64 between a FORTRAN 77 integer and a FORTRAN 77 integer*4 - the first is a default integer, the latter is more or less guaranteed to be a 4 bytes integer. This means that a program using integer*4 or integer variables (or a mixture thereof) could get into trouble! Hans, can you confirm whether there is a difference between integer and integer*4 on your platform? Probably easiest to see with: integer i,j i = 2*31 j = 2*i if ( j .gt. i ) then write(*,*) 'Integer type is large enough' else write(*,*) 'Integer type seems equal to integer*4' endif or some such program. Regards, Arjen |
From: Hans K. <Han...@kv...> - 2005-04-11 07:14:58
|
1) I changed typedef long PLINT; ==> typedef int PLINT in include/plplot.h and now the f77 example code works fine. 2) I run your test below with the result that (j.gt.i) i.e. 'integer type is large enough' Regards, Hans > > Hans, can you confirm whether there is a difference between integer > and integer*4 on your platform? Probably easiest to see with: > > integer i,j > i = 2*31 > j = 2*i > if ( j .gt. i ) then > write(*,*) 'Integer type is large enough' > else > write(*,*) 'Integer type seems equal to integer*4' > endif > > or some such program. > > > Regards, > > Arjen > -- |
From: Arjen M. <arj...@wl...> - 2005-04-11 06:34:57
|
"Alan W. Irwin" wrote: > > > > > Also I found the following article to be informative: > > http://www.embedded.com/shared/printableArticle.jhtml?articleID=17300092 > > Thanks, Maurice, for reminding me of that old correspondence on the previous > change. Reviewing that, it looks like the current typedef long PLINT was > driven by python/numeric integer array needs. So I believe it will take > some additional work to make python/numeric integer arrays compatible with > the planned typedef int32_t PLINT for the C library. I don't have time at > the moment, but I hope to do that work sometime within the next month. > Meanwhile, I will leave things as they are (even though it causes problems > for fortran on AMD-64). > Perhaps this issue can be resolved via the C-FORTRAN interface layer? It would require information from the FORTRAN side as to how long a typical integer is and it may be complicated by things like integer != integer*4 (see my previous post), but it seems a workable solution to me - at least on this early monday morning, with the sun shining brightly :) Regards, Arjen |
From: Arjen M. <arj...@wl...> - 2005-04-11 07:27:24
|
Hans Karlsson wrote: > > 1) I changed > typedef long PLINT; ==> typedef int PLINT > in include/plplot.h and now the f77 example code works fine. > > 2) I run your test below with the result that > (j.gt.i) i.e. 'integer type is large enough' > > Regards, > Hans > > > > Hans, can you confirm whether there is a difference between integer > > and integer*4 on your platform? Probably easiest to see with: > > > > integer i,j > > i = 2*31 > > j = 2*i > > if ( j .gt. i ) then > > write(*,*) 'Integer type is large enough' > > else > > write(*,*) 'Integer type seems equal to integer*4' > > endif > > > > or some such program. > > Aaargh, I should have tested it first :( Change the line "i = 2*31" into: "i = 2**30" (The ** is crucial) Regards, Arjen |
From: Hans K. <Han...@kv...> - 2005-04-11 07:52:35
|
Ok, output for i=2^30 and j=2*i Result: i= 1073741824 j= -2147483648 integer type seem equal to integer*4 /Hans On Mon, 2005-04-11 at 09:26 +0200, Arjen Markus wrote: > Hans Karlsson wrote: > > > > 1) I changed > > typedef long PLINT; ==> typedef int PLINT > > in include/plplot.h and now the f77 example code works fine. > > > > 2) I run your test below with the result that > > (j.gt.i) i.e. 'integer type is large enough' > > > > Regards, > > Hans > > > > > > Hans, can you confirm whether there is a difference between integer > > > and integer*4 on your platform? Probably easiest to see with: > > > > > > integer i,j > > > i = 2*31 > > > j = 2*i > > > if ( j .gt. i ) then > > > write(*,*) 'Integer type is large enough' > > > else > > > write(*,*) 'Integer type seems equal to integer*4' > > > endif > > > > > > or some such program. > > > > > Aaargh, I should have tested it first :( > > Change the line "i = 2*31" into: "i = 2**30" > > (The ** is crucial) > > Regards, > > Arjen > -- |
From: Arjen M. <arj...@wl...> - 2005-04-11 08:08:11
|
Hans Karlsson wrote: > > Ok, output for i=2^30 and j=2*i > Result: > i= 1073741824 > j= -2147483648 > integer type seem equal to integer*4 > Great, this simplifies the issue quite a bit :) So: we do not have to worry about integer versus integer*4 declarations. Instead it seems that your FORTRAN compiler is using 32-bits integers. Regards, Arjen |
From: Alan W. I. <ir...@be...> - 2005-04-15 17:10:01
|
On 2005-04-15 12:46+0100 Andrew Ross wrote: > For now I suggest a configure check for stdint.h. At least for 64bit AMD > / itanium systems we can be reasonably sure of a modern C compiler. For > other systems the current status quo is probably sufficient. I have now implemented the original solution I proposed (which takes advantage of a configuration check already in place). So for systems with stdint.h PLINT will be int32_t, and otherwise it will be int. This is quite a change from the "long" version of PLINT that was originally motivated by python needs. However, those python needs seem to have appeared last year with one Debian version of python, but they now have gone away again. Anyhow, the solution I just committed seems not to generate any python problems on Debian testing with python version 2.3.5-1. Alan __________________________ Alan W. Irwin email: ir...@be... phone: 250-727-2902 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 Yorick front-end to PLplot (yplot.sf.net); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ |