Re: Re: MLton codegen combines divison on arm

On Sun, Nov 14, 2010 at 4:36 AM, Adam Goode <[email protected]> wrote:
> These kinds of decisions are really system-wide and ABI-changing.
> And the standard ARM ABI doesn't require rounding modes.

Yes, this is the main problem.

> After hacking around with GCC, you would then need to recompile
> your OS, since libgcc is statically linked on ARM by default.

Well, as long as your program doesn't change the rounding mode, you
would be able to mix the two types of arithmetic in a single
executable. IEEE floats behave the same way regardless of the
implementation you're using (as long as you use soft-fp calling
convention anyway). Not the cleanest solution, I'll grant.

> At that point, you might as well only compile for the newer ARMv7-A
> processors and just do something like:
> http://wiki.debian.org/ArmHardFloatPort

Yes, I'm aware of that project. As VFP becomes more and more common,
the faster calling convention will certainly be attractive. However,
for arm without VFP, a solution is still needed.

> By the way, this shouldn't be silently failing for you
> ... unless of course you are running on a system that actually has
> hardware VFP and then you are hitting the glibc bug

As arm systems with 1GB of RAM tend to also have a VFP, I've only ever
built MLton where this bug is in effect.