Page 1 of 1
The Woz FP routines
Posted: Tue Oct 30, 2018 2:27 pm
by 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
Re: The Woz FP routines
Posted: Tue Oct 30, 2018 3:00 pm
by 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!
Re: The Woz FP routines
Posted: Tue Oct 30, 2018 6:29 pm
by 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.
Re: The Woz FP routines
Posted: Tue Oct 30, 2018 6:36 pm
by granati
Just as suggestion: why don't use the Microsoft 5 bytes f.p. implementation as in commodore line?
Re: The Woz FP routines
Posted: Tue Oct 30, 2018 6:46 pm
by drogon
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)
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
Re: The Woz FP routines
Posted: Tue Oct 30, 2018 6:47 pm
by drogon
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
Re: The Woz FP routines
Posted: Tue Oct 30, 2018 6:48 pm
by BigEd
Note this fix needed for Woz and Rankin's LOG:
viewtopic.php?p=63993#p63993
Re: The Woz FP routines
Posted: Tue Oct 30, 2018 6:50 pm
by 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
Re: The Woz FP routines
Posted: Tue Oct 30, 2018 6:54 pm
by granati
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?
Re: The Woz FP routines
Posted: Tue Oct 30, 2018 6:57 pm
by Chromatix
I imagine there are code size/complexity/speed advantages if all objects are the same size.
Re: The Woz FP routines
Posted: Tue Oct 30, 2018 7:05 pm
by drogon
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
Re: The Woz FP routines
Posted: Tue Oct 30, 2018 7:07 pm
by drogon
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
Re: The Woz FP routines
Posted: Tue Oct 30, 2018 10:14 pm
by barrym95838
Also, be aware of this thread:
viewtopic.php?f=1&t=3633
Re: The Woz FP routines
Posted: Wed Oct 31, 2018 8:46 pm
by 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.
Re: The Woz FP routines
Posted: Wed Oct 31, 2018 11:18 pm
by whartung
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:
or, simply:
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.