Re: [cc65] Floating point support?

On 27 Sep 2004, at 10:35, Ullrich von Bassewitz wrote:

> I was talking about the *compiler*, not one of the targets. The 
> compiler must
> be able to evaluate floating point expressions in exactly the same 
> format as
> the target platform, otherwise expressions evaluated by the compiler 
> would
> have other results than the ones evaluated by a program running on the 
> target.

Ah, ok - I misunderstood.

>> Yes, and rightly so. Still, it would perhaps be a good idea to add
>> supports for 4-byte floats first, then based on the experience look
>> towards a 6 (or even 8) byte double.
>
> That's not really an option, because it means doing most of the work 
> twice.

Well, most of the "thinking work" would be quite similar... But still, 
yes, there would be quite a bit of work to be done twice.

>> That's fine. As a starting point, I think it would be convenient if at
>> least the basic operations were available (addition, subtraction,
>> multiplication, division, and comparison operators - am I missing any
>> out?), this would at least allow people to do basic FP stuff using
>> function calls for now, and these will suffice later on for providing
>> compilation ability.
>
> Yes, but as I said already: Not in the near future. What you call 
> "basic
> operations" requires most of the real work to be done.

You are referring to what i called step (4) in my previous email, I 
think. This is indeed by far the most work. However, if a 
function-based interface would already be present, one could already do 
some floating-point stuff without actual compiler support (by calling 
the functions).

>> I propose to settle on IEEE-754 single-precision for now. We should be
>> able to use these as a base for a widened implementation later on.
>
> I don't agree with the latter. As I said above, changing horses is not 
> really
> an option, because it means doing most of the work twice. So, *if* we 
> agree on
> the 32 bit IEEE format, we will have to do that knowing that it will 
> be the
> only format, and that it doesn't meet the requirements of the C 
> standard,
> meaning that some code requiring more precision (which is guaranteed 
> by the
> standard for a conforming implementation) will not to run. Please note 
> that I
> don't vote against the 32 bit format. I just want to show the 
> consequences of
> the decision. Maybe we should consider a 6 byte format, just to see 
> what that
> would mean. The data type REAL implemented by Turbo Pascal was a 6 
> byte data
> type, and it was quite fast. But then, the platforms where it was 
> implemented
> had 16 bit registers ...

Ok. If it's a given that we are going to support just one FP-type (and 
now that I think about it this makes a lot of sense), I would agree 
that indeed the natural choice is between a 4-byte and a roll-your-own 
6-byte type.

As to the Turbo Pascal type, it looks like this (assuming you are using 
a fixed width font ;-)):

  47     40 39 38                                 0
   .-----------------------------------------------.
   | 8 bits |s|msb         39 bit mantissa      lsb|
   `-----------------------------------------------'
        |    |                  `------------  mantissa
        |    `-----------------------------  sign bit
        `--------------------------------  biased exponent (80h)


Compared to the IEEE formats, the sign bit is in a different place - 
but there is much to be said for this scheme (the exponent byte now 
being in a separate byte). The 39-bit mantissa guarantees 11 decimal 
digits which would be compliant to ISO C requirements. I am not sure 
whether TP used an implicit '1' in its mantissa, and how (if at all) it 
handled non-normalized numbers.

On a related note: do you have strong feelings about whether or not to 
fully support IEEE-754 notions such as Not-A-Number, Infinity, rounding 
modes? If we'd go for the 4-byte implementation it may we worth 
considering (since we'd then be confirming to a well-established 
standard), but for an artificial 6-byte format it might be just too 
much of a hassle.... No-one in his right mind is going to use a 6502 
for heavy-duty number-crunching anyway, it would come at a cost in 
terms of performance, complexity, and code size, and there's nothing in 
the C standard that demands it (since annex F of C99 is 
non-normative)...

Regards,

  Sidney

----------------------------------------------------------------------
To unsubscribe from the list send mail to majordomo@musoftware.de with
the string "unsubscribe cc65" in the body(!) of the mail.