Re: Cross-compile (i386/ARM) question

["Mark Meijer" <meijer78@...>]

You said in the first post "I'm not really using floating point, but
the Lua's number type is the default (double)". Don't know if this is
an option for you (though I guess not, you probably already thought of
this), but can't you use Lua compiled with integer instead of double
as the number type?


2008/8/27 Bogdan Marinescu <bogdan.marinescu@gmail.com>:
> Heh.
>
> http://sourceware.org/ml/crossgcc/2005-05/msg00126.html
>
> And I quote:
>
> ======================================================================
> Hi there,
>
> a while back a had problems with with the byte order of doubles on an
> ARM9 system.
>
> Nicolas Pitre wrote me:
>
>        Yes.  On ARM, the two 32bit words of a double are themselves encoded
>        in native endian order, but the most significant word is always first.
>
>
>    And for completeness, this is true only for FPA ordering. The new
> VFP ordering uses native memory ordering which is the same as i386 for
> litle endian, or ppc for big endian, as anyone would normally expect.
>
>    The kernel FP emulators are emulating a FPA coprocessor though.
>    When soft-float is used, it can be configured to use either FPA or
> VFP ordering.
>
> ======================================================================
>
> If this is true (and I'm pretty sure it is) compiling everything with
> "-msoft-float -mfpu=vfp" should do the trick. Unfortunately
> "everything" includes the toolchain (Newlib + libgcc + other gcc libs)
> so that's a job for tomorrow. I'll post the results here.
>
> Bogdan
>
> On Thu, Aug 28, 2008 at 12:39 AM, Bogdan Marinescu
> <bogdan.marinescu@gmail.com> wrote:
>> What a mess ... thanks, at least I know where the problem is.
>>
>> On Thu, Aug 28, 2008 at 12:32 AM, Luiz Henrique de Figueiredo
>> <lhf@tecgraf.puc-rio.br> wrote:
>>>> Thanks. Hmmm, that would be strange. An endianess problem?
>>>
>>> Yes, I understand that ARM has strange endianess for floating-point,
>>> which can be selected by software. See the whole thread containing the
>>> message I cited.
>>>
>>
>