From: Spiro Trikaliotis (spiro.trikaliotis_at_gmx.de)
Date: 2003-03-07 07:26:46
Hello, Ullrich von Bassewitz wrote on Friday, March 07, 2003 12:20 AM: > * ...standard violating. The standard requires that the compiler uses the > same rules as the target platform when calculating floating point results. > The result of > > double a = 1.0 / 3.0; /* Evaluated at compile time */ > > must be the same as > > double a = 1.0; > double b = 3.0; > ... > double c = a / b; /* Evaluated at runtime */ > > So either the compiler would reimplement all ROM routines for all existing > platforms or it would violate the standard. Well, the standard even requires that compilation with and w/o optimizations returns the same values. As even gcc on an iA32 fails to do that, I think it would not be so bad if CC65 would violate it "a little", too. ;-) The problem with gcc on iA32: The iA32 FP unit does every calculation with 80 bit, but stores are in 32 (float) or 64 (double) bit. If intermediate results are stored in memory, the processor rounds them. As the storage is different in optimized (-O2) and not optimized code (-O0), you sometimes get very different results. Anyway trying to tell me that this is a problem of the architecture and not of the compiler: MS VC++ (for sure) and the Intel compiler (I think) don't have that problem, they produce the same results with and without optimization. This does not apply if you use long double (80 bit) on gcc, btw. Anyway, your argument on the different formats which the compiler must generate is truly a valid one. Regarding the IEEE 754 standard, I think you have possibilities to reduce your code size. As fas as I know (never have seen that standard, only books speaking of it), the denormalized numbers are not required. Processing of the different "error codes" (+/-NaN, +/-infinity, ...) could be "unified", ... Although I would find it interesting, I surely would not be the person to do that - but the people wanting this feature might try to implement some basic functions (add, sub, mul and div) and I'm almost sure that Uz would not add support in the compiler as soon as these routines prove to be usefull. Wanting him to add support when the functions are not there is not a good idea, as it would take his time, and as we all know, it is not that likely that someone would fill in the gap of the routines, except Uz himself. Spiro. ---------------------------------------------------------------------- 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 : 2003-03-07 07:31:21 CET