[Numpy-discussion] Can we assume both FPU and ALU to have same endianness for numpy ?

Francesc Alted faltet at pytables.org
Tue Mar 10 12:56:13 EDT 2009


A Tuesday 10 March 2009, David Cournapeau escrigué:
> Francesc Alted wrote:
> > A Tuesday 10 March 2009, David Cournapeau escrigué:
> >> Hi,
> >>
> >>     While working on portable macros for NAN, INF and co, I was
> >> wondering why the current version of my code was working
> >> (http://projects.scipy.org/numpy/browser/trunk/numpy/core/include/
> >>num py/npy_math.h, first lines). I then realized that IEEE 754 did
> >> not impose an endianness, contrary to my belief. The macros would
> >> fail if the FPU and the ALU were using a different endianness. Is
> >> this still a possibility on the architectures we want to support ?
> >
> > Could you be more explicit?  Currently, there is only a part of the
> > processor that does floating point arithmetic.  In old systems,
> > there was in a FPU located outside of the main processor, but in
> > modern ones, I'd say that the FPU is always integrated in the main
> > ALU.
>
> I am asking whether we can assume that both integer and floating
> point representation uses the same endianness for all architectures
> we want to support. I thought IEEE 754 imposed everything to be big
> endian, but then discovered this was wrong.

Well, provided that most modern processors have the FPU and ALU 
integrated in the same die, I'd say that it is safe to assume that the 
both must have the same endianness.  When/if NumPy starts to support 
GPUs, then it would probably be a good time to ask again about this ;-)

>
> > At any rate, having an ALU and FPU with different endianess sounds
> > *very* weird to my ears.
>
> According to wikipedia, it is (was ?) possible:
>
> http://en.wikipedia.org/wiki/Endianness#Floating-point_and_endianness
>
> Now, whether this happens with current architectures, I don't know. I
> have tested my code on ppc, x86, x86_64 and sparc, and all of them
> share the same endianness for ALU and FPU. But maybe some other don't
> (ARM ? ARM is maybe the platform I am the less familiar with, but is
> potentially one of the most interesting - with things like ARM-based
> netbooks and other low-power devices; we can wait a while before idl
> or matlab to be ported on ARM, I think :) ).

Yeah, exactly :)

-- 
Francesc Alted



More information about the NumPy-Discussion mailing list