From: Ullrich von Bassewitz (uz_at_musoftware.de)
Date: 2002-05-23 12:49:48
Hi!
On Thu, May 23, 2002 at 12:39:03AM +0200, groepaz wrote:
> UvB> The difference is that the graphics interface is not covered by a standard
> UvB> while floating point arithmetic is.
>
> so thats the accuracy argument again? or what else? errno? ;=P
It has nothing to do with accuracy. 32 bit IEEE floats have about the same
precision as the floating point implementation in the CBM kernal, and I
expected a simple implementation to about as fast. The important word is
"standard compliance".
> yes, and like mentioned before - if you really ever need standard
> compliance you could always drop in your own standard-compliant
> routines. i am just saying that for most reallife programs (those you
> could compile using cc65 atleast) wont really suffer from the little
> differences. its just the same as using file i/o that cannot seek or
> termio that cant handle all attributes (or substitutes them for that
> matter).
There is a large difference between missing routines and routines that work
different. The former will cause some programs to compile, but those which
compile are still standard C programs. If you have a library that is not
standard compliant, it makes standard C programs fail.
> thats why i suggested using "real" (IEEE) floats in the compiler
> internally, and use IEEE for internal conversion and arithmetics, but
> apart from that let the assembler know about different targets formats
> (and also IEEE for that matter) - and then simply spill calls to a
> standard fp-emulator interface....
This is ok with me. But to get the interface right, I would like to have the
first implementation to be a IEEE one. If you want to use the ROM routines
later, and it is possible to plug them into the existing interface - ok. But
I'm convinced that using non standard routines for a start will spoil the
interface and prevent standard compliant routines later.
> - you want your compiler to act standard-compliant, and by all means
> to work as one would expect from any other "big" compiler
I would be perfectly happy with 32 bit floats for both, float and double.
Anything else would be complete overkill. This is quite some difference to a
compiler for larger machines, where mostly 64 bit floats are used.
> so the real question is, how can the user (me) use his non-standard
> libraries with your compiler without the need of adding "ugly" stuff
> to the compiler that potentially breaks the standard ?
My proposal would be to add standard compliant floating point routines (if
any). These routines need an interface, and you can then go ahead and replace
these routines with your own.
Regards
Uz
--
Ullrich von Bassewitz uz_at_musoftware.de
----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo_at_musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.
This archive was generated by hypermail 2.1.3 : 2002-05-23 12:50:25 CEST