Re: New 64 Bit Big Endian architecture

[Karim BELABAS <Karim.Belabas@math.u-psud.fr>]

On Mon, 10 Dec 2001, Oliver Paukstadt wrote:
> First thing is, that config/endian.c is ugly and wrong.

Ugly, possibly; wrong, I don't think so.

> I'm not sure, what you really want to find out, but ia64 (64 bit
> LittleEndian) and s390x (64 bit BigEndian) have the same output.
> Imho float representation is independent from byteorder of integer values.
> If you have special assumption for floats please put it into another test.

We want to find out "double endianness", i.e one detail about internal
floating point representation, which is not significant for 64bit
architecture (hence the identical answer for ia64 and s390x). The current
development releases, only available through our CVS server, has the
following short "explanation" text in the Configure script:

  For 32-bit architecture, PARI needs to know the format of your 'double' type.
  PARI assumes doubles are stored in IEEE754 format [ (sign, exponent, mantissa
  high) on one word, (mantissa low) on another ]; assuming a
    union { double d; ulong l[2]; } x;
  are the double exponent and sign stored on x.i[0] (0) or on x.i[1] (1) ?

This is (I think and hope) exactly what the endian.c code was testing. It
_used_ to test for ordinary endianness with code analogous to yours, but we
recently noticed that this was not at all what was needed in the PARI code,
which only used "endianness" in the dbltor/rtodbl conversion routines (float
to t_REAL).  As we figured out the hard way (broken binary on ARM), the
internal format of floating point numbers is independant of endianness.
Endianness in the ordinary sense is not needed at all in PARI.

It was a quick change for the 2.1.2 stable update, not properly documented
there.  The current version [bugfix update 2.1.3, soon to be released] is
more satisfactory: output values are simply 0/1, - (not needed), and "not
IEEE" (fail), and do not twist the meaning of the standard endianness
conventions (1234, etc).

Sorry about the misleading name endian.c. It basically is due to the fact
that CVS is very bad at keeping track of filename changes. So I'd rather
stick to the current name.

> I have a test-prg based on det-endian.c of glibc which works correct for
> 32 and 64 bit endian detection.
>
> s390 requires -fPIC for shared code.
>
> All test seem to be successful, except nfields.
> If you want the diffs please ask for it.

I'd like the diffs, if you please.

> Here are the inital s390x patches (If the mailer destroys them, ask for a
> attached patch-file).
> -snip---
> diff -Nur pari-2.1.2/Configure pari-2.1.2.work/Configure
[...]
> +    linux-s390*) DLCFLAGS=-fPIC;
> +                 OPTFLAGS="$OPTFLAGS -mno-backchain";;

I'll include this. Thanks.

    Karim.
-- 
Karim Belabas                    Tel: (+33) (0)1 69 15 57 48
Dép. de Mathematiques, Bat. 425  Fax: (+33) (0)1 69 15 60 19
Université Paris-Sud             Email: Karim.Belabas@math.u-psud.fr
F-91405 Orsay (France)           http://www.math.u-psud.fr/~belabas
--
PARI/GP Home Page: http://www.parigp-home.de/