[ECOS] Floating point representation with Ecos

[Andrew Lunn]

On Tue, Feb 28, 2006 at 03:42:53PM -0300, Ramiro C. Carvalho wrote:
> Hi, everybody.
> 
> I am experiencing problems exchanging floating point data between my Ecos
> target (ARM7 processor and gcc 4.0.1) and Matlab under Windows XP (which
> uses IEEE 754 standard).
> By studying the file ieeefp.h under language/c/libm/... i found that there
> are two flavours of doubles on a little endian machine, as shown by the
> fragment of code below:

I think you are wrong here. These are not two flavours on doubles on
little endian, but just two flavours depending on big/little endian.

>    struct
>    {
> #if (CYG_DOUBLE_BYTEORDER == CYG_MSBFIRST) // Big endian
>        unsigned int fraction1:16;
>        unsigned int fraction0: 4;
>        unsigned int exponent :11;
>        unsigned int sign     : 1;
>        unsigned int fraction3:16;
>        unsigned int fraction2:16;
> #else
>        unsigned int fraction3:16;
>        unsigned int fraction2:16;
>        unsigned int fraction1:16;
>        unsigned int fraction0: 4;
>        unsigned int exponent :11;
>        unsigned int sign     : 1;
> #endif
>    } number;
> 
> I could see that Matlab sends float data according to the second format
> (sign bit is the higher order)

What are you running matlab on? Solaris on SPARC is generally big
endian, where as M$ or *inx on x368 will be little endian.....

> and, so, i tried to change
> CYG_DOUBLE_BYTEORDER to CYG_LSBFIRST and rebuild ecos (i had to change it
> manually inside basetype.h file since it?s hard coded as CYG_MSBFIRST for
> ARM architecture). This did not have any effect on the representation used
> for double.

Im supprised the system ran at all. You cannot just change the endinness
of the processor like that...

> Do anyone know more about this stuff?

> - Is floating point format defined by Ecos or by gcc?

Neither and both. The C standard say nothing about how the compiler
arranges bitfields inside an structure. It would be quite legal for
the compiler to actually arrange the structure as:

        unsigned int sign     : 1;
        unsigned int fraction1:16;
        unsigned int fraction0: 4;
        unsigned int fraction3:16;
        unsigned int exponent :11;
        unsigned int fraction2:16;

However no compiler would actually do this since it breaks the
alignment. In practice gcc has always arranged bitfields consistently
from version to version, so it is possible to trust it to do what you
expect it to do.

> - Why changing CYG_DOUBLE_BYTEORDER to CYG_LSBFIRST didn?t have any effect
> on the floating point representation used?
> - Why is this define hard coded as msb for ARM architecture? There shouldn?t
> be an option on the config tool to allow changing this?

It is not as simple as this. eg fraction1 is a half word. Is this half
word little endian or big endian?

> - Is the first form of representation compatible with IEEE 754 standard?

I don't know the standard. Does it actually specify the binary format
of numbers? Or does it just say there is 1 sign bit, 11 bits of
exponent, and 48 bits of fraction? 

To be portable i suggest you do your import/export with Matlab in
plain ASCII. I beleave the ASCII representation of double is
standardised so you can rely on it.

       Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss