Floating-point calling conventions

[samr7]

When attempting to use floating-point code in native programs on an A780, I persistently hit problems with invalid results. After digging around and comparing generated code with the EZX libraries, it would appear that my gcc built as per Leprechaun's instructions uses slightly different floating point calling conventions than the gcc used by Motorola. The same is true of a gcc built independently with the softfloat patch and crosstool-0.38.

Anybody notice similar problems?

The discrepancy appears to have something to do with alignment within registers. A function like:

void func1(double d);

will have d passed as r1:r0. This works. However, a function like:

void func2(int a, double d);

highlights the discrepancy. With either compiler, a will be in r0. With gcc built from public sources, d will be in r2:r1. The compiler Motorola used seems to pad it up to an 8-byte *register* boundary and place d in r3:r2. WTF?

The Bessel functions jn and yn from libm are nice clear examples. The printf() routine with doubles in even parameter slots exhibits the problem as well. There are quite a few more examples in the Qt library.

So, does anybody have any clues what's wrong and how to fix it?
Thanks...

[alebm]

Try building a toolchain based on gcc 3.4.2 for iwmmxt plataform, since gcc 3.3.x doesn't support this it may lead to weird errors.
I am using 3.4.2 against glibc 2.3.2 for a few days and it appears to be more stable with softfloat things.

[samr7]

Try building a toolchain based on gcc 3.4.2 for iwmmxt plataform, since gcc 3.3.x doesn't support this it may lead to weird errors.
I am using 3.4.2 against glibc 2.3.2 for a few days and it appears to be more stable with softfloat things.

I tried that with GCC 3.4.3, and also had success with FP. GCC 3.4.x seem to come with libstdc++.so.6. Unfortunately the Motorola libqte is linked aganst libstdc++.so.5, and my secret agenda is to link against Motorola's Qt with all open-source stuff and have everything work. Perhaps the old libstdc++ could be made to work with GCC 3.4? Ugh.

As you point out, the calling convention changes certainly seem to be part of the iwmmxt CPU support. I took a crack at backporting a year-old GCC-trunk iwmmxt patch to GCC 3.3.2. The result can't even seem to build its own libgcc without an ICE or two.

Without delving into any copyright-protected Montavista code, a good GCC 3.3.x iwmmxt patch would really hit the spot now...

[cyph]

Could you try to get to the bottom of this? It seems that this might be causing all the instability in OPIE (esp. with qpdf).

[alebm]

Just open opie calc hehe things are very weird.
At this time i'm compiling all my c++ stuff static... I think that for future developments(or not need to be compatible with moto libs), gcc 3.4.x have to be used.
Modifying libstd can be a way to make it compatible but I guess that it will need dedication hehe, last time I tried these weird compatibility scenarios I almost smashed my head in the keyboard

[samr7]

I took another shot with the iwmmxt backport on 3.3.6, tried applying some of the more important bug fixes from the main line, and eventually came up with a seemingly stable, working toolchain that gets the calling conventions right. Temporarily posted below:

http://lsb.blogdns.net/ezx-crosstool

[f0x0r]

Nice write-up samr7!