Thanks for replying! Ullrich von Bassewitz wrote: > > And, having two implementations makes it easier to find problems, > because you can check the results against each other. > Good point! > > The real work is getting support into the compiler, and > writing all the library extensions for the 6502 (think about printf ...). > Trust me, I have (at the expense of some sleep)! printf is a mountain of a function. :-) > > A standards compliant double needs 34 bits in the mantissa (10 digits of > precision), so it needs 64 bit IEEE floats or some non standard format. > Is performance and space economy the main argument against 64-bit doubles, or is there something else? As soon as a programmer knowingly makes a decision to use a double instead of a float on a 6502, they probably have pondered the consequences. If one knows the consequences yet proceeds to do it anyway, it is probably safe to say that performance *really* takes a back seat to precision on the particular problem they are tackling. A 40-bit or 48-bit double might be a good compromise for performance, but is it really worth the trouble of designing and documenting a non-standard format, knowing how rarely it'll be used? While a custom-tailored format (e.g. byte-aligned exponent, etc.) might ease some of the implementation troubles, any format is going to be painful to implement, isn't it? Dropping the design and documentation burden might reduce the net amount of insanity. ;-) In summary, I like the idea of 32-bit floats and 64-bit doubles. That said, down the road if the floating point project materializes, I'd be willing to help out... Kevin ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Thu Apr 8 22:19:22 2010
This archive was generated by hypermail 2.1.8 : 2010-04-08 22:19:24 CEST