Re: State of m68k float emulation in lb1sf68.asm (muldf, divdf)

[<tm_gccmail at kloo dot net>]

On 17 Nov 2003, Jim Wilson wrote:

> On Mon, 2003-11-17 at 11:16, tm_gccmail@kloo.net wrote:
> > Uh, have you looked at fp-bit.c? It's glacially slow.
> 
> Have you looked at lb1sf68.asm?  The complaint was that it is slow
> because it is using bit-wise loops for multiplies.  fp-bit.c doesn't, it
> uses actual multiply instructions, and hence may be faster.

The gcc SH port uses fp-bit.c, and I have many users bitterly complaining
that the gcc SH floating point is slow compared to the Renesas compiler.

On Java benchmarks, the gcc sh-elf compiled code runs *3* times slower
then the Renesas compiled one.

That's 3 times slower even including all the JVM overhead, so I
suspect the actual ratio for FP only is probably something like 10x
slower.

> I agree that fp-bit.c is slower than necessary, but it is folly to
> assume that it is slower than all FP emulators.  There are some that are
> even slower, and lb1sf68.asm might be one.

I could probably write slower code, but I wouldn't bet on it...

> > GMP isn't IEEE754 compatible, iirc. It's an arbitrary precision bignum
> > library, and therefore unsuitable for as an fp-bit.c replacement.
> 
> You missed the point.  This discussion is about how to do the 108-128
> bit multiply that muldf3 needs.  That is exactly what GMP was designed
> for, and it will likely do it better than any hand written m68k code
> will.

GMP would still be compiled with gcc, so it's utterly dependent on the gcc
m68k codegen quality. When I was doing the sun3-linux port, I looked at
a lot of gcc-m68k output, and I recall not being very impressed with it.

Toshi