SoftFloat is broken in several ways (eg. bug 543144, bug 543633, a couple of others I haven't got round to filing bugs for yet). SoftFloat is also annoying from a Nanojit-developer point of view. It's lots of code that is only relevant on half a platform, including four softfloat-only opcodes (including the spectacularly grotesque LIR_callh). Furthermore, it appears that neither Adobe nor Mozilla have any test coverage for it. Which would explain why it's broken, and AFAICT has been broken for ages. I've started working towards getting some very basic test coverage (bug 530754, bug 543401). But if it's been broken for ages and nobody has complained, that indicates it's not important. So why do we support it? Any clarifications would be welcome!

It's my understanding that we require this feature for at least some Windows Mobile devices. I may be mistaken, though.

Vlad, do you have anything to add about Windows Mobile? I find it odd that we "need" any feature that isn't currently (AFAIK) shipped and has been broken for ages without anyone noticing.

Not my call, really; cc'ing Stuart and Brad. The problem is that we've had two classes of devices in the past, all of them Windows Mobile, which we care less about: 1) Those with really no VFP (very rare) 2) Those with hardware VFP, but disabled in the OS (very common -- the CE kernel by default disables VFP, and manufacturers need to do extra work to enable it) We could just draw a line and say that we'll only support ARMv6+VFP or higher (with the majority of our interesting devices being ARMv7), but I'm quite surprised that Adobe hasn't run into this problem with Flash on CE... then again, the devices where they can get a decent flash experience are probably all at least ARMv6+VFP, which are coincidentally the devices where I think we can get a decent browsing experience.

I'd be glad to get rid of the soft-float stuff. Things to consider: • Linux distributors will get upset if we mandate something above their baseline. I think Debian support ARMv4, for example, but at the moment they work around our ARMv5 requirement by simply disabling the JIT. If they can use the same technique to compile Firefox (without the JIT) for ARMv4T, they should be happy. • It's worth noting that Ubuntu 10.04 will have an ARMv7+VFPv3 baseline, so we aren't likely to upset that crowd. I could be wrong, but I think 9.10 has an ARMv6+VFP(v2) baseline. • An ARMv6+VFP baseline for Trace Monkey sounds attractive. There are some Marvell platforms (and probably some others too) that have ARMv5+VFP; these are fast enough that someone might reasonably want to run a browser on them: http://en.wikipedia.org/wiki/SheevaPlug Those devices are already not available to users of Ubuntu 9.10 and above. • There were problems with WinCE emulators when we made the decision to drop ARMv4 support. I don't use WinCE myself, but we need to ensure that the ARMv6+VFP stuff will be supported. Taking all that into consideration, and assuming that the WinCE stuff isn't too badly affected, I'd be happy to see the soft-float stuff go, and raising the bar to ARMv6 also feels like a good move; the fewer configurations we have to support, the better. It's not my decision, of course, but that's my opinion.

Adobe still needs softfloat, for at least a while longer. We want to move to hw FP everywhere but some device vendors are considering softfloat + JIT configurations for the Player. Softfloat builds will be online in the build system within the next week. Also, my understanding is that the four "softloat op codes" are not soft float specific, they're just used heavily by softfloat code. Tamarin tracing used these opcodes extensively. Anyway, we can start a discussion on whether those opcodes should get the boot but it's a separate question from softfloat support.

(In reply to comment #5) > some device vendors are considering softfloat + JIT > configurations for the Player. It's hard to imagine such a configuration being a good experience. > Also, my understanding is that the four "softloat op codes" are not soft float > specific, they're just used heavily by softfloat code. Recent changes have made them softfloat-only.

Adobe is currently testing the ARM builds on windows mobile (with softfloat, not passing -Darm_vfp) but only on release builds, so the assertion is not happening. This is done by the winmobile-emulator builder: http://tamarin-builds.mozilla.org/tamarin-redux/waterfall I honestly do not fully understand exactly what is happening, but on release builds the full acceptance suite passes without passing -Darm_vfp. We are working to get additional testing online for both softfloat and vfp.

(In reply to comment #5) > Adobe still needs softfloat, for at least a while longer. We want to move to > hw FP everywhere but some device vendors are considering softfloat + JIT > configurations for the Player. Does Adobe have any influence over those device vendors? If Adobe said "we won't support softfloat because the performance will be terrible" would they unconsider? I'd like to avoid introducing a maintenance headache if we can avoid it.

Bug 542326 made this situation simpler -- all SoftFloat code is now segregated behind a #if NJ_SOFTFLOAT_SUPPORTED. I'm unassigning myself this bug, and while I won't deliberately break the SoftFloat code, I won't test it myself when making Nanojit changes, nor try to improve it, unless circumstances change.

Mozilla dropped investment in Firefox on Windows Mobile/CE, and that was our last potential softfloat holdout. We don't really care about softfloat at this point -- if we're ever able to port to Windows Phone 7, I have to assume that they'll have figured out how to enable vfp support by now.

Tamarin build system is running acceptance tests using softfloat on arm-linux for Release (test phase) and Debug (deep phase) on beagleboard hardware. Shell is compiled with VFP support (--enable-arm-neon) but we are not enabling VFP support in the jit via commandline switches. You must enable VFP support by specifying -Darm_vfp [-Darm_arch N] nanojit assumes ARMvN architecture (default=5) [-Darm_vfp] nanojit uses VFP rather than SoftFloat Test -> test.linux-arm-test.Release-softfloat (running acceptance WITHOUT passing -Darm_vfp) Debug -> deep.linux-arm-deep.Debug-softfloat (running acceptance WITHOUT passing -Darm_vfp)

Closing this as WONTFIX because Adobe needs softfloat still. If that ever changes, please reopen this bug (or file a new one) ASAP! :)