Copyright considerations

[drogon]

BruceRMcF wrote:

One approach is to look to a fractional number format that would be less work to implement, such as a 3+1 byte rational number format, with 24 bit numerator and 8 bit denominator.

Or simply look at the documents for IEEE 754 floating point and write an implementation from scratch...

-Gordon
(No emphasis on the word simply

[BruceRMcF]

drogon wrote:

BruceRMcF wrote:

One approach is to look to a fractional number format that would be less work to implement, such as a 3+1 byte rational number format, with 24 bit numerator and 8 bit denominator.

Or simply look at the documents for IEEE 754 floating point and write an implementation from scratch...

-Gordon
(No emphasis on the word simply

Or find a C reference implementation like SoftFloat -- http://www.jhauser.us/arithmetic/SoftFloat.html -- and port it -- but porting from C to 6502 assembly language does not appear to be enough like having fun for anyone to have done so yet.

[BillG]

drogon wrote:

BruceRMcF wrote:

One approach is to look to a fractional number format that would be less work to implement, such as a 3+1 byte rational number format, with 24 bit numerator and 8 bit denominator.

Or simply look at the documents for IEEE 754 floating point and write an implementation from scratch...

Been there, still trying to do that...

[BillG]

BruceRMcF wrote:

Or find a C reference implementation like SoftFloat -- http://www.jhauser.us/arithmetic/SoftFloat.html -- and port it -- but porting from C to 6502 assembly language does not appear to be enough like having fun for anyone to have done so yet.

Someone could compile it and hand optimize the generated code?

[BruceRMcF]

BillG wrote:

BruceRMcF wrote:

Or find a C reference implementation like SoftFloat -- http://www.jhauser.us/arithmetic/SoftFloat.html -- and port it -- but porting from C to 6502 assembly language does not appear to be enough like having fun for anyone to have done so yet.

Someone could compile it and hand optimize the generated code?

An advantage of that approach is that if someone gets it to compile for a 6502 target and then hand-optimizes it so it is "small enough and fast enough" for their purposes, others could pick up the ball and hand optimize it further.

My guess is it would be a grind, but if someone finds that kind of grind with 6502 assembly language to be a good way to escape from the turmoil of a busy week, maybe.

[gfoot]

I'm not sure that standard IEEE formats are the right choice for a 6502. Splitting the exponent over two bytes is very awkward, and I think there's a reasonably good argument for storing the significand in signed two's complement form.

My own floating point routines use a similar format to Acorn's, but narrower, and I think it helps efficiency compared with IEEE float formats.

I write things like this from scratch partly because I enjoy (and learn from) reinventing wheels, but also because I don't want to be encumbered by any licensing requirements, even for free software, such as preserving credit notices and so on - I don't mind giving credit in principle, but I don't have time to be legally obliged to do so.

I also don't want anyone to feel barred from using anything I've shared for these reasons, so I explicitly use the Unlicense in general.

[jgharston]

Hey, if anybody wants 8+32 floating point arithmetic for the PDP11, you're welcome to use it.

I've found that the really nice thing about 5-byte floating point is the ability to also hold an integer over the whole range of values, encoded with the exponent being zero.

In any floating format, a floating zero is an exception, and is usually coded exp=00,man=00,00...., so just extend that and if the exponent is zero, the mantissa is an integer. 5-byte floats allows you to hold a full 32-bit integer as 00,xxxxxxxx. Other sizes, such as 4-byte floats, don't give you enough "space" in the bits.