The Woz FP routines

[drogon]

For a little project I need a single precision/4-byte solution. (It has to be 4 bytes for other reasons).

I'm probably going to just use the Woz routines, but was wondering if there is any merit in coding an IEEE-754 solution, given the recent thread. The numbers won't be exported in anything other than on-screen so a compatible binary format isn't required.

It's not for anything vaguely critical, just a little interpreter for a bit of fun.

So just wondering if anyone has used/is using the Woz routines on a daily basis if if they're happy with them..

Cheers,

-Gordon

[BigEd]

I haven't used them, but I would use them! I lack the sense of impending joy from implementing my own. In other words, I'd say it's worth implementing a floating point package if you really want to implement a floating point package. But not worth it as a means to an end. This is of course only my take on it!

[Chromatix]

For simple purpose, the Woz routines do work - after all, they shipped in millions of Apple ]['s. They have similar theoretical range and precision to IEEE-754 single precision - with some caveats.

Caveat 1: AFAIK, the Woz routines have no guard digits, and thereby have only a primitive treatment of rounding error. This could seriously hurt practical precision in some cases.

Caveat 2: the Woz format has no support whatsoever for Infinities or NaNs, so must treat overflow, range or other errors with exception traps instead of returning an interpretable value. Conversely, it does have a slightly extended dynamic range for representing finite values.

It would probably be good practice to design your interpreter in such a way that the Woz routines can be swapped out for something else later, in case you find a need or use for something more capable.

[granati]

Just as suggestion: why don't use the Microsoft 5 bytes f.p. implementation as in commodore line?

[drogon]

Chromatix wrote:

For simple purpose, the Woz routines do work - after all, they shipped in millions of Apple ]['s. They have similar theoretical range and precision to IEEE-754 single precision - with some caveats.

Yes, they were, but I don't know anything that actually used them - Applesoft used a 5-byte format (from Microsoft I presume)

Chromatix wrote:

Caveat 1: AFAIK, the Woz routines have no guard digits, and thereby have only a primitive treatment of rounding error. This could seriously hurt practical precision in some cases.

Caveat 2: the Woz format has no support whatsoever for Infinities or NaNs, so must treat overflow, range or other errors with exception traps instead of returning an interpretable value. Conversely, it does have a slightly extended dynamic range for representing finite values.

It would probably be good practice to design your interpreter in such a way that the Woz routines can be swapped out for something else later, in case you find a need or use for something more capable.

Noted, thanks, however hopefully it's not an issue to start with - I just need something get get going with and If needed I can change to something else later. The only caveat I have is that it needs to be 4 bytes storage.

Thanks,

-Gordon

[drogon]

granati wrote:

Just as suggestion: why don't use the Microsoft 5 bytes f.p. implementation as in commodore line?

Everything is optimised for 4 bytes of storage. Integers, floats, pointers...

Cheers,

-Gordon

[BigEd]

Note this fix needed for Woz and Rankin's LOG:
viewtopic.php?p=63993#p63993

[BigEd]

BTW, Microsoft's Basic came in a 4 byte version as well as the more commonly seen 5 byte version:
https://www.pagetable.com/?p=46

[granati]

drogon wrote:

granati wrote:

Just as suggestion: why don't use the Microsoft 5 bytes f.p. implementation as in commodore line?

Everything is optimised for 4 bytes of storage. Integers, floats, pointers...

Cheers,

-Gordon

in an 8 bit micro this is important?

[Chromatix]

I imagine there are code size/complexity/speed advantages if all objects are the same size.

[drogon]

granati wrote:

drogon wrote:

granati wrote:

Just as suggestion: why don't use the Microsoft 5 bytes f.p. implementation as in commodore line?

Everything is optimised for 4 bytes of storage. Integers, floats, pointers...

Cheers,

-Gordon

in an 8 bit micro this is important?

It makes life easy in some cases and actually this is ultimately aimed at the 65816 when doing stuff like (virtual machine) register to register move might be more efficient to do in 16-bit chunks. It's a 32-bit vm running on a 16-bit machine with 8-bit memory... It won't be the fastest thing on the 65xxx planet, but that's not my aim.

Cheers,

-Gordon

[drogon]

BigEd wrote:

BTW, Microsoft's Basic came in a 4 byte version as well as the more commonly seen 5 byte version:
https://www.pagetable.com/?p=46

Thanks, I'll have a look at that. Also seen the errata and have the original Apple II "Red Book" and "Wozpack ][" too which gives good insight into using them.

Cheers,

-Gordon

[barrym95838]

Also, be aware of this thread:

viewtopic.php?f=1&t=3633

[BigEd]

It looks like there's also a 4-byte floating point package in the 6502 Software Gourmet Guide & Cookbook:
http://www.classiccmp.org/cini/books/Sc ... okbook.pdf
(Chapter 5, page 93 of the PDF)

(There's no text layer in this PDF! So lots of typing ahead, or some OCR and proof-reading.)

Edit: also at the Internet Archive, with text layer, here.

[whartung]

BigEd wrote:

It looks like there's also a 4-byte floating point package in the 6502 Software Gourmet Guide & Cookbook:
http://www.classiccmp.org/cini/books/Sc ... okbook.pdf
(Chapter 5, page 93 of the PDF)

(There's no text layer in this PDF! So lots of typing ahead, or some OCR and proof-reading.)

Unrelated to the topic, but specific to the book.

If you look at the code, the author does a curious thing.

You see a lot of this:

Code: Select all

    LDX #LBL1
    STA PAGE0, X

or, simply:

Code: Select all

    LDX #LBL1
    STA $0,X

It's like the 6502 he was using (or perhaps the assembler!) didn't know about Zero Page. i.e. why not just "STA LBL1".

Very odd.