Author Topic: The floating-point thing (Read 4565 times)

Windrose · « **on:** November 19, 2004, 10:14:44 am »

Just to test my understanding here, it's the case that if I choose to use the snazzy Open Zaurus rom on my SL5600, I'll never be able to run software such as Hancom Sheet or NeoCal that is compiled against a hardware floating-point library?

Windrose

zenyatta · « **Reply #1 on:** November 19, 2004, 10:37:01 am »

Correct. All "legacy" applications involving floating-point applications will behave erratically. Technically, it's not a "hardware floating-point library" but an older, incompatible library for emulating a floating-point co-processor.

z.

Windrose · « **Reply #2 on:** November 19, 2004, 10:46:22 am »

Quote

Technically, it's not a "hardware floating-point library" but an older, incompatible library for emulating a floating-point co-processor.

And there's no way to "compat" that by some sort of fake lib that intercepts the call to the old lib and redirects it to the software floating-point lib?

W

zenyatta · « **Reply #3 on:** November 20, 2004, 03:32:03 am »

Well, I don't quite see into it but I believe there is some compiler voodoo going on whereby the lib is invoked whenever the source code contains an expression with floating-point operands. You write "x = x + 3.0" and the lib gets called transparently. So it is not a straight, explicit library call - which probably makes it very hard or impossible to intercept. This might also explain why you get numerical errors instead of "missing library" complaints. It's all about expression evaluation more than function calls. Mickey or someone could probably explain this more thoroughly.

Mickeyl · « **Reply #4 on:** November 20, 2004, 08:08:00 am »

It's like that: hard-float means you just compile floating point instructions into the binary, no matter whether your CPU has a FPU or not. Stumbling over such an instruction, the CPU then raises an exception, the kernel gets active and calculates the expression for you (in place of a "real" FPU) and hands it back to the application layer. This is slow.

soft-float more or less means that the glibc and the gcc work together in substituting floating point instructions on the fly w/ the appropriate emulation. This is faster because no exception and kernel is involved.

zenyatta · « **Reply #5 on:** November 20, 2004, 02:57:01 pm »

Mickey: from your explanation it would seem that hard-float and soft-float should be able to happily coexist. Why is it not so? Has the exception-handling part been removed from the present kernel? Sorry if I'm missing something obvious.

Mickeyl · « **Reply #6 on:** November 20, 2004, 04:51:07 pm »

*sigh* You and your quest for understanding

For simplicity I omitted that hard-float and soft-float have different calling conventions on the binary level - this is what makes them more or less incompatible. For more details you would need to dig into some ugly glibc and gcc internals where even I feel like digging in the dark

Windrose · « **Reply #7 on:** November 20, 2004, 10:14:01 pm »

Well foop. I thought software was supposed to improve my life.
w

Windrose · « **Reply #8 on:** November 22, 2004, 04:18:14 pm »

On the Zaurus Users listserv, the estimable Robert Longbottom mentions in passing:

Quote

(I'm using xmms on OZ 3.5.1 -ish on an SL5500 self-built with soft float disabled so that I can run HancomSheet)

Is it that "easy"? Snarf the kernel source feed and rebuild it with a setting changed??
W

acpkendo · « **Reply #9 on:** November 22, 2004, 06:23:45 pm »

I too would be very interested if this works. . . maybe even interested enough to try my hand at compiling a kernel using OE. I have been meaning to install it anyway in order to package some binaries (the Hancom apps among them, per Mickeyl's suggestion). . .

lardman · « **Reply #10 on:** November 23, 2004, 04:59:26 am »

Quote

Is it that "easy"? Snarf the kernel source feed and rebuild it with a setting changed??

Yes it is that easy afaik. One line needs to be changed in the local.conf file.

However you need to create a new rom image too, not just the kernel, as libc is involved in the fp handling iirc (and everything is linked against libc).

That said, it's still pretty easy.

Si

acpkendo · « **Reply #11 on:** November 23, 2004, 09:45:39 am »

Quote

However you need to create a new rom image too, not just the kernel, as libc is involved in the fp handling iirc (and everything is linked against libc).

So, in other words, I'm waiting until I build my home server. My lappie has neither 512MB RAM nor 5GB disk space to space. . .

ninsei · « **Reply #12 on:** November 26, 2004, 09:15:48 pm »

so if i recompile an app that uses floating point with the gcc 3.3.2 toolchain i got when i was using OZ 3.3.6 (i think that was the OZ ver), and run it on OZ 3.5.1, it STILL wont work right (doesnt seem to)? Must i compile it with the gcc 3.4.2 toolchain?

lardman · « **Reply #13 on:** November 27, 2004, 06:12:08 am »

Quote

so if i recompile an app that uses floating point with the gcc 3.3.2 toolchain i got when i was using OZ 3.3.6 (i think that was the OZ ver), and run it on OZ 3.5.1, it STILL wont work right (doesnt seem to)?

Why not compile said app with OE, then it will work with OZ3.5.1 and will also use -soft-float?

Si

ninsei · « **Reply #14 on:** November 27, 2004, 07:50:34 am »

the learning curve for OE seems longer than i expected. so i was looking for a shortcut ;-)

News:

Author Topic: The floating-point thing (Read 4565 times)