Re: buildd failure for sparc - floating point encoding?
Helen Faulkner <[EMAIL PROTECTED]> writes: > As far as I can tell, there is no debian package that contains the CDF > library. There are a lot of things that have netCDF, but that is a > different thing. Oops, sorry. For Debian, I think you need three cases for FP format: IEEE BE, IEEE LE, and (I assume) IBM 360 format for the s390 target. You can use autoconf AC_CANONICAL_TARGET to test for s390 (`s390-*-linux-gnu*') and AC_C_BIGENDIAN to distinguish the IEEE cases. Otherwise you can use endian.h and whatever the relevant cpp macro is for s390. (Generally, you should also worry about VAX format, and possibly vintage Cray; Convex was subtly different, but I assume it's now dead.) See float.h if necessary. The HDF source was a useful place to look for details of such things ~10 years ago. If the CDF code is doing the same thing, you might be able to copy that directly.
Re: buildd failure for sparc - floating point encoding?
> > In short (IIRC) most modern SPARC processors implement 32 and 64 bit > > IEEE floating point operations. > All SPARCs, surely? Not sure about some of the very obscure chips such as the ones used on space craft. Then again IIRC it's in the standards so without FP it isn't really a SPARC chip. > > This is the same as some MIPS processors (I suspect the SGi > > setting), most PowerPCs (IBM-RS, Mac) and a host of other > > architectures. > The distinction is whether they're big or little endian. Probably the > majority of the architectures can actually be either. Early MIPS chips had a pin to select which it would run as. Most architectures have some opcode to handle this sort of thing (even inverse order loads) but I don't know of any other mainstream processors that really do /both/. That does make some sense given the DECStation 5000 is one of the few examples of MIPS processors using the other endian set up, > > x86 chips (and IIRC the Alpha) support 80 bit IEEE operations, which is > > (I guess) why the have their own category. > [I don't think that's true for Alpha.] OTTOMH I'm not sure. Had a feeling they did but without an Alpha or an Alpha spec book I can't prove it. Ofcourse this point is *way* OT. > > If I was responsible for this code up stream I'd go for clarifying each > > of these categories down to exactly what standard each one is rather > > than what machines implement them. But then again I'm pedantic like > > that. > As above, it's not pedantic. Autoconf should be able to determine > what the FP format is, though I don't think there's an existing test; > it can definitely tell the byte sex. I thought most folks did it at run time with fun with magic numbers et al. Cheers, - Martin -- Martin [EMAIL PROTECTED] "Seasons change, things come to pass"
Re: buildd failure for sparc - floating point encoding?
Dave Love wrote: Martin <[EMAIL PROTECTED]> writes: Given that most of the machines sold by Sun are based on SPARC chips and most of the SPARC chips sold are sold by Sun I would guess the 'sun' setting is what you are after. As daevm points out, the macros used are simply wrong. This should be __sparc__, __MIPSEB__, &c. (You can check for many cases by looking at GCC's machine files.) Macros like `sun' aren't defined in ISO C mode -- it's `__sun__' -- and don't describe the hardware, c.f. Solaris x86. I'm surprised CDF headers are that broken. So am I . However, the package shouldn't be using its own version of CDF. It should build against the Debian package, and a program doing CDF i/o shouldn't care about this at all. As far as I can tell, there is no debian package that contains the CDF library. There are a lot of things that have netCDF, but that is a different thing. If you know a debian package that provides the CDF library, please let me know :) Thanks, Helen.
Re: buildd failure for sparc - floating point encoding?
Martin <[EMAIL PROTECTED]> writes: > Given that most of the machines sold by Sun are based on SPARC chips and > most of the SPARC chips sold are sold by Sun I would guess the 'sun' > setting is what you are after. As daevm points out, the macros used are simply wrong. This should be __sparc__, __MIPSEB__, &c. (You can check for many cases by looking at GCC's machine files.) Macros like `sun' aren't defined in ISO C mode -- it's `__sun__' -- and don't describe the hardware, c.f. Solaris x86. I'm surprised CDF headers are that broken. However, the package shouldn't be using its own version of CDF. It should build against the Debian package, and a program doing CDF i/o shouldn't care about this at all. > In short (IIRC) most modern SPARC processors implement 32 and 64 bit > IEEE floating point operations. All SPARCs, surely? > This is the same as some MIPS processors (I suspect the SGi > setting), most PowerPCs (IBM-RS, Mac) and a host of other > architectures. The distinction is whether they're big or little endian. Probably the majority of the architectures can actually be either. > x86 chips (and IIRC the Alpha) support 80 bit IEEE operations, which is > (I guess) why the have their own category. [I don't think that's true for Alpha.] > Althought the later example > code doesn't seem to use this so it may be an encoding issue. Assuming this is similar to HDF -- I don't know CDF -- it's probably a question of the FP format written to binary files. > If I was responsible for this code up stream I'd go for clarifying each > of these categories down to exactly what standard each one is rather > than what machines implement them. But then again I'm pedantic like > that. As above, it's not pedantic. Autoconf should be able to determine what the FP format is, though I don't think there's an existing test; it can definitely tell the byte sex. This must be sorted by the CDF packages anyhow, and I assume they take into account the other relevant format on S390.
Re: buildd failure for sparc - floating point encoding?
Does anyone know whether sparc uses the same encoding as one of these examples? Given that most of the machines sold by Sun are based on SPARC chips and most of the SPARC chips sold are sold by Sun I would guess the 'sun' setting is what you are after. [...] Thanks very much Martin (and others)! I'm now using the sun setting, and the package is compiling, at least past the point where it broke before. I will certainly be talking to upstream about the best way to implement a fix for the problem. Helen.
Re: buildd failure for sparc - floating point encoding?
On Wed, 27 Oct 2004 00:44:56 +0100 Helen Faulkner <[EMAIL PROTECTED]> wrote: > #if > defined(sun)||defined(MIPSEB)||defined(IBMRS)||defined(HP)||defined(NeXT)||defined(mac)||defined(POWERPC) > # define FP1cpu > #endif This first define test should be "__sparc__" instead of "sun".
Re: buildd failure for sparc - floating point encoding?
> /* > * Floating-point encodings. > * 1..Sun, SGi, IBM-RS, HP, NeXT, Macintosh > * 2..DECstation, IBM-PC, Alpha (OSF/1), Alpha (OpenVMS - IEEE_FLOAT) > * 3..VAX, Alpha (OpenVMS - D_FLOAT) > * 4..Alpha (OpenVMS - G_FLOAT) > */ > > #if > defined(sun)||defined(MIPSEB)||defined(IBMRS)||defined(HP)||defined(NeXT)||defined(mac)||defined(POWERPC) > # define FP1cpu > #endif > Does anyone know whether sparc uses the same encoding as one of these > examples? Given that most of the machines sold by Sun are based on SPARC chips and most of the SPARC chips sold are sold by Sun I would guess the 'sun' setting is what you are after. Full specs on the SPARC chips support for floating point can be found on the standards body website http://www.sparc.org/ In short (IIRC) most modern SPARC processors implement 32 and 64 bit IEEE floating point operations. This is the same as some MIPS processors (I suspect the SGi setting), most PowerPCs (IBM-RS, Mac) and a host of other architectures. x86 chips (and IIRC the Alpha) support 80 bit IEEE operations, which is (I guess) why the have their own category. Althought the later example code doesn't seem to use this so it may be an encoding issue. If I was responsible for this code up stream I'd go for clarifying each of these categories down to exactly what standard each one is rather than what machines implement them. But then again I'm pedantic like that. HTH Cheers, - Martin -- Martin [EMAIL PROTECTED] "Seasons change, things come to pass"
Re: buildd failure for sparc - floating point encoding?
A couple of potentially useful observations for you:
1) A floating point encoding format appeared to be defined for Sun, as
type 1 in your code listing.
2) Modern microprocessors like SPARC, i386, etc. really should all be
using uniform IEEE 754 floating point number formats. Here is an
overview: http://stevehollasch.com/cgindex/coding/ieeefloat.html
Good luck in overcoming these development obstacles. I am sorry if this
information does not help.
--- Helen Faulkner <[EMAIL PROTECTED]> wrote:
> Please CC to me - I'm not subscribed to the list.
>
>
> I am maintaining a new package, labplot, that is failing, at its
> first upload,
> to build on sparc (among other things). Actually it hasn't gotten to
> the end of
> the sparc queue yet, but I tested it on someone's machine and it is
> broken in
> the same way as several other architectures.
>
> I believe the problem is that there is no floating point encoding
> being defined
> for sparc, which is leading to an undefined type of struct later on.
>
> The program defines the floating point encoding in the included cdf
> library like
> this (from cdf/cdfdist.h, line 437 onwards):
>
>
>
/*
> * Floating-point encodings.
> * 1..Sun, SGi, IBM-RS, HP, NeXT, Macintosh
> * 2..DECstation, IBM-PC, Alpha (OSF/1), Alpha (OpenVMS -
> IEEE_FLOAT)
> * 3..VAX, Alpha (OpenVMS - D_FLOAT)
> * 4..Alpha (OpenVMS - G_FLOAT)
>
*/
>
> #if
>
defined(sun)||defined(MIPSEB)||defined(IBMRS)||defined(HP)||defined(NeXT)||defined(mac)||defined(POWERPC)
> # define FP1cpu
> #endif
>
> #if
>
defined(MIPSEL)||defined(IBMPC)||defined(alphaosf)||defined(alphavmsI)||defined(posixSHELLalphaI)
> # define FP2cpu
> #endif
>
> #if defined(vax)||defined(alphavmsD)||defined(posixSHELLalphaD)
> # define FP3cpu
> #endif
>
> #if defined(alphavmsG)||defined(posixSHELLalphaG)
> # define FP4cpu
> #endif
>
>
> Does anyone know whether sparc uses the same encoding as one of these
> examples?
> What I am hoping is that sparc uses the same floating point encoding
> as one of
> the archs this code already works for, and that it's therefore only a
> matter of
> fixing the #if statements above to include the sparc case.
>
> The FP*cpu definition is used later, (see below, from cdf/cdflib.h,
> line 400
> onwards) to define the data structs. Hopefully one of these will
> work for sparc.
>
> If anyone can help with a suggestion, that would be great.
>
> Thank you,
>
> Helen.
>
>
>
/**
> * Floating-point structures.
>
**/
>
> #if defined(FP1cpu)
>struct fp1struct4 {
> uInt s : 1, e1 : 7, e0 : 1, m2 : 7, m1 : 8, m0 : 8;
>};
>struct fp2struct4 {
> uInt m0 : 8, m1 : 8, e0 : 1, m2 : 7, s : 1, e1 : 7;
>};
>struct fp34struct4 {
> uInt e0 : 1, m2 : 7, s : 1, e1 : 7, m0 : 8, m1 : 8;
>};
>struct fp1struct8 {
> uInt s : 1, e1 : 7, e0 : 4, m6 : 4, m5 : 8,
> m4 : 8, m3 : 8, m2 : 8, m1 : 8, m0 : 8;
>};
>struct fp2struct8 {
> uInt m0 : 8, m1 : 8, m2 : 8, m3 : 8, m4 : 8,
> m5 : 8, e0 : 4, m6 : 4, s : 1, e1 : 7;
>};
>struct fp3struct8 {
> uInt e0 : 1, m6 : 7, s : 1, e1 : 7, m4 : 8,
> m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
>};
>struct fp4struct8 {
> uInt e0 : 4, m6 : 4, s : 1, e1 : 7, m4 : 8,
> m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
>};
> #endif
>
> #if defined(FP2cpu)
>struct fp1struct4 {
> uInt e1 : 7, s : 1, m2 : 7, e0 : 1, m1 : 8, m0 : 8;
>};
>struct fp2struct4 {
> uInt m0 : 8, m1 : 8, m2 : 7, e0 : 1, e1 : 7, s : 1;
>};
>struct fp34struct4 {
> uInt m2 : 7, e0 : 1, e1 : 7, s : 1, m0 : 8, m1 : 8;
>};
>struct fp1struct8 {
> uInt e1 : 7, s : 1, m6 : 4, e0 : 4, m5 : 8,
> m4 : 8, m3 : 8, m2 : 8, m1 : 8, m0 : 8;
>};
>struct fp2struct8 {
> uInt m0 : 8, m1 : 8, m2 : 8, m3 : 8, m4 : 8,
> m5 : 8, m6 : 4, e0 : 4, e1 : 7, s : 1;
>};
>struct fp3struct8 {
> uInt m6 : 7, e0 : 1, e1 : 7, s : 1, m4 : 8,
> m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
>};
>struct fp4struct8 {
> uInt m6 : 4, e0 : 4, e1 : 7, s : 1, m4 : 8,
> m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
>};
> #endif
>
> #if defined(FP3cpu)
>struct fp1struct4 {
> uInt e1 : 7, s : 1, m2 : 7, e0 : 1, m1 : 8, m0 : 8;
>};
>struct fp2struct4 {
> uInt m0 : 8, m1 : 8, m2 : 7, e0 : 1, e1 : 7, s : 1;
>};
>struct fp34struct4 {
> uInt m2 : 7, e0 : 1, e1 : 7, s : 1, m0 : 8, m1 : 8;
>};
>struct fp1struct8 {
> uInt e1 : 7, s : 1, m6 : 4, e0 : 4, m5 : 8,
> m4 : 8, m3 : 8, m2 : 8, m1 : 8, m0 : 8;
>};
>struct fp2struct8 {
> uInt m0 : 8, m1 : 8, m2
buildd failure for sparc - floating point encoding?
Please CC to me - I'm not subscribed to the list.
I am maintaining a new package, labplot, that is failing, at its first upload,
to build on sparc (among other things). Actually it hasn't gotten to the end of
the sparc queue yet, but I tested it on someone's machine and it is broken in
the same way as several other architectures.
I believe the problem is that there is no floating point encoding being defined
for sparc, which is leading to an undefined type of struct later on.
The program defines the floating point encoding in the included cdf library like
this (from cdf/cdfdist.h, line 437 onwards):
/*
* Floating-point encodings.
* 1..Sun, SGi, IBM-RS, HP, NeXT, Macintosh
* 2..DECstation, IBM-PC, Alpha (OSF/1), Alpha (OpenVMS - IEEE_FLOAT)
* 3..VAX, Alpha (OpenVMS - D_FLOAT)
* 4..Alpha (OpenVMS - G_FLOAT)
*/
#if
defined(sun)||defined(MIPSEB)||defined(IBMRS)||defined(HP)||defined(NeXT)||defined(mac)||defined(POWERPC)
# define FP1cpu
#endif
#if
defined(MIPSEL)||defined(IBMPC)||defined(alphaosf)||defined(alphavmsI)||defined(posixSHELLalphaI)
# define FP2cpu
#endif
#if defined(vax)||defined(alphavmsD)||defined(posixSHELLalphaD)
# define FP3cpu
#endif
#if defined(alphavmsG)||defined(posixSHELLalphaG)
# define FP4cpu
#endif
Does anyone know whether sparc uses the same encoding as one of these examples?
What I am hoping is that sparc uses the same floating point encoding as one of
the archs this code already works for, and that it's therefore only a matter of
fixing the #if statements above to include the sparc case.
The FP*cpu definition is used later, (see below, from cdf/cdflib.h, line 400
onwards) to define the data structs. Hopefully one of these will work for sparc.
If anyone can help with a suggestion, that would be great.
Thank you,
Helen.
/**
* Floating-point structures.
**/
#if defined(FP1cpu)
struct fp1struct4 {
uInt s : 1, e1 : 7, e0 : 1, m2 : 7, m1 : 8, m0 : 8;
};
struct fp2struct4 {
uInt m0 : 8, m1 : 8, e0 : 1, m2 : 7, s : 1, e1 : 7;
};
struct fp34struct4 {
uInt e0 : 1, m2 : 7, s : 1, e1 : 7, m0 : 8, m1 : 8;
};
struct fp1struct8 {
uInt s : 1, e1 : 7, e0 : 4, m6 : 4, m5 : 8,
m4 : 8, m3 : 8, m2 : 8, m1 : 8, m0 : 8;
};
struct fp2struct8 {
uInt m0 : 8, m1 : 8, m2 : 8, m3 : 8, m4 : 8,
m5 : 8, e0 : 4, m6 : 4, s : 1, e1 : 7;
};
struct fp3struct8 {
uInt e0 : 1, m6 : 7, s : 1, e1 : 7, m4 : 8,
m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
};
struct fp4struct8 {
uInt e0 : 4, m6 : 4, s : 1, e1 : 7, m4 : 8,
m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
};
#endif
#if defined(FP2cpu)
struct fp1struct4 {
uInt e1 : 7, s : 1, m2 : 7, e0 : 1, m1 : 8, m0 : 8;
};
struct fp2struct4 {
uInt m0 : 8, m1 : 8, m2 : 7, e0 : 1, e1 : 7, s : 1;
};
struct fp34struct4 {
uInt m2 : 7, e0 : 1, e1 : 7, s : 1, m0 : 8, m1 : 8;
};
struct fp1struct8 {
uInt e1 : 7, s : 1, m6 : 4, e0 : 4, m5 : 8,
m4 : 8, m3 : 8, m2 : 8, m1 : 8, m0 : 8;
};
struct fp2struct8 {
uInt m0 : 8, m1 : 8, m2 : 8, m3 : 8, m4 : 8,
m5 : 8, m6 : 4, e0 : 4, e1 : 7, s : 1;
};
struct fp3struct8 {
uInt m6 : 7, e0 : 1, e1 : 7, s : 1, m4 : 8,
m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
};
struct fp4struct8 {
uInt m6 : 4, e0 : 4, e1 : 7, s : 1, m4 : 8,
m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
};
#endif
#if defined(FP3cpu)
struct fp1struct4 {
uInt e1 : 7, s : 1, m2 : 7, e0 : 1, m1 : 8, m0 : 8;
};
struct fp2struct4 {
uInt m0 : 8, m1 : 8, m2 : 7, e0 : 1, e1 : 7, s : 1;
};
struct fp34struct4 {
uInt m2 : 7, e0 : 1, e1 : 7, s : 1, m0 : 8, m1 : 8;
};
struct fp1struct8 {
uInt e1 : 7, s : 1, m6 : 4, e0 : 4, m5 : 8,
m4 : 8, m3 : 8, m2 : 8, m1 : 8, m0 : 8;
};
struct fp2struct8 {
uInt m0 : 8, m1 : 8, m2 : 8, m3 : 8, m4 : 8,
m5 : 8, m6 : 4, e0 : 4, e1 : 7, s : 1;
};
struct fp3struct8 {
uInt m6 : 7, e0 : 1, e1 : 7, s : 1, m4 : 8,
m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
};
struct fp4struct8 {
uInt m6 : 4, e0 : 4, e1 : 7, s : 1, m4 : 8,
m5 : 8, m2 : 8, m3 : 8, m0 : 8, m1 : 8;
};
#endif
#if defined(FP4cpu)
struct fp1struct4 {
uInt e1 : 7, s : 1, m2 : 7, e0 : 1, m1 : 8, m0 : 8;
};
struct fp2struct4 {
uInt m0 : 8, m1 : 8, m2 : 7, e0 : 1, e1 : 7, s : 1;
};
struct fp34struct4 {
uInt m2 : 7, e0 : 1, e1 : 7, s : 1, m0 : 8, m1 : 8;
};
struct fp1struct8 {
uInt e1 : 7, s : 1, m6 : 4, e0 : 4, m5 : 8,
m4 : 8, m3 : 8, m2 : 8, m1 : 8, m0 : 8;
};
struct fp2struct8 {
uInt m0 : 8, m1 : 8, m2 : 8, m3 : 8, m4 : 8,
m5 : 8, m6 : 4, e0 : 4, e1 : 7, s : 1;
};
struct fp3struct8
