[Numpy-discussion] Request for review: dynamic_cpu_branch

[David Cournapeau]

Charles R Harris wrote:
>
>
> On Mon, Dec 22, 2008 at 10:40 PM, David Cournapeau <cournape at gmail.com
> <mailto:cournape at gmail.com>> wrote:
>
>     On Tue, Dec 23, 2008 at 2:35 PM, Robert Kern
>     <robert.kern at gmail.com <mailto:robert.kern at gmail.com>> wrote:
>
>     >
>     > I think he meant that it can be discovered at runtime in
>     general, not
>     > at numpy-run-time, so we can write a small C program that can be run
>     > at numpy-build-time to add another entry to config.h.
>
>     But then we only move the problem: people who want to build universal
>     numpy extensions will have the wrong value, no ? The fundamental point
>     of my patch is that the value is set whenever ndarrayobject.h is
>     included. So even if I build numpy on PPC, NPY_BIGENDIAN will not be
>     defined when the header is included for a file build with gcc -arch
>     i386.
>
>
> We can probably set things up so the determination is at run time --
> but we need to be sure that the ABI isn't affected. I did that once
> for an old project that needed data portability. In any case, it
> sounds like a project for a later release.

It cannot work for numpy without breaking backward compatibility,
because of the following lines:

#define PyArray_ISNBO(arg) ((arg) != NPY_OPPBYTE)
#define PyArray_IsNativeByteOrder PyArray_ISNBO
#define PyArray_ISNOTSWAPPED(m) PyArray_ISNBO(PyArray_DESCR(m)->byteorder)
#define PyArray_ISBYTESWAPPED(m) (!PyArray_ISNOTSWAPPED(m))

Since any code using the macro will expand it at build time, you can't
make it such as it will be correct at runtime. We would have to replace
those macro by "non inlinable" functions.

I will add a function to detect endianness, though, just to check that
the macro value corresponds to the runtime one (it will make problems on
say little endian ppc much easier to detect).

David