OESF Portables Forum
Everything Else => Zaurus Distro Support and Discussion => Distros, Development, and Model Specific Forums => Archived Forums => Angstrom & OpenZaurus => Topic started by: 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
-
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.
-
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
-
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.
-
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.
-
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.
-
*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
-
Well foop. I thought software was supposed to improve my life.
w
-
On the Zaurus Users listserv, the estimable Robert Longbottom mentions in passing:
(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
-
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). . .
-
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
-
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. . .
-
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?
-
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
-
the learning curve for OE seems longer than i expected. so i was looking for a shortcut ;-)
-
the learning curve for OE seems longer than i expected
This is not the aim of the OE framework. One of the core aims is AFAIK to keep developers heads free from toolchain troubles and pains. Once you have OE running you will have a very powerful framework and can concentrate on developement.
Cheers,
Sam