Re: [MiNT] PML trouble with -m68020-60

[Vincent Rivière <vincent.riviere@freesbee.fr>]

Miro Kropáček wrote:
> Hmm, except immediate break of some still developed FPU software (we
> could print a warning message while rpm update process) I see no reason
> why to keep this bad habit of d0/fp0. So you've got one vote from me :)

I don't understand your vote.
You would like to return doubles to d0/d1 in any case, right ?

Personally, I'm torn...
- Returning to d0/d1 has the best compatibility (except with current and 
potentially broken libraries).
- Returning to fp0 is a bit faster. But since most of the stuff should 
be inlined, does it matter ?

Usually, the safer solution is the best...

>     As a result, PML for -m68020-60 has always been compiled using the
>     68000 implementation, which can be wrong because of 1). Fortunately,
>     that
>
> Damn it! I must check this but I fear you're right :-/ Yeah, this is
> real bug, no doubt.

I meant: correct code (if the implementation is full C), but FPU not 
fully used, or not used at all.

> I don't understand, what's the difference between "native" FPU version
> of pml (or any other math lib) and this inline implementations?

If I'm not wrong, only some simple math functions such as sin() can be 
inlined as a single FPU instruction. This is the purpose of 
math-68881.h. But the more complex functions still have to reside in libm.a.

The idea of math-68881.h is to avoid the overhead of a function call to 
libm when the "function" can be inlined as a single instruction. 
Usually, the equivalent libm function contains only that instruction.

I noticed these problems last year when compiling POV-Ray. The 68000 and 
ColdFire versions worked well (return to d0/d1), while the -m68020-60 
produced almost black pictures. I think it is a good testcase :-)

Vincent