On Monday 31 October 2005 14:36, Paul Mundt wrote: > Some versions of the ARM9 support VFP, which allows for partial hardware > FP support for some basic single and double precision opcodes, and traps > for the rest (it however does not offer a IEEE754 compliant interface in > hardware, and requires quite a bit of help from software to do so). OMAP > 2420 supports this, OMAP 1710 does not. As such, we presently use > in-kernel NWFPE.
As I understand, trapping happens if you want the VFP to signal if it's results are inaccurate or non-IEEE. The logic appears to be, that for most users it is more important to have a fast fpu than high quality math results. It would need some more investigating to find out how bad the inaccuracies are, and if you can use it as the fpu for off-the-shelf software expecting IEEE semantics, or if it's usefullness is limited to code written specifically for it. From Debian/Alpha experiences, I would bet for the latter. Especially considering that pre-EV6 alpha fpu did not suck - it was just not perfectly IEEE compatible.. > This is not necessarily true either, and is one of the bigger reasons for > pushing EABI. It makes sense to use VFP for what it supports natively, > most of the rest of it is better left to something like soft-float. > Kernel FP emulation is slow by definition. Agreed. Even if VFP turns out to be really fast and usefull, most arm cpu's will still be fpuless for a long time from now. _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://maemo.org/mailman/listinfo/maemo-developers
