Floating Point Routines by Steve Wozniak(mailp.in)
mailp.in
Floating Point Routines by Steve Wozniak
http://mailp.in/Y6WE2w8v/
10 comments
Going by the HN policy of preferring original sources, here's where this came from: http://6502.org/source/floats/wozfp1.txt
Mailpin seems to just add additional tracking to who's reading it, without adding additional value: the syntax highlighting is pretty broken.
Mailpin seems to just add additional tracking to who's reading it, without adding additional value: the syntax highlighting is pretty broken.
Mailpin has actually been astroturfing HN using separate accounts, including the OP:
https://news.ycombinator.com/submitted?id=mailpin
https://news.ycombinator.com/submitted?id=getmailpin
https://news.ycombinator.com/submitted?id=wenbinf (maybe unrelated, but odd submission patterns nonetheless)
https://news.ycombinator.com/submitted?id=mailpin
https://news.ycombinator.com/submitted?id=getmailpin
https://news.ycombinator.com/submitted?id=wenbinf (maybe unrelated, but odd submission patterns nonetheless)
That's just one of the sources, though, isn't it?
I have written two floating point packages, both before 1975.
The first was for the IBM 1401 (really!). iirc, it had a 2 or 3 digit exponent and 10 or more digit mantissa. It was just for fun, and never used for anything.
The second was for a Varian minicomputer. It was intended for an application that needed to solve a 19 x 19 system of linear equations. Since the Varian was a 16-bit machine, I used a format of 1 word (16 bits) exponent and 2 word (32 bits) mantissa. It was fun, it worked, and I was paid to do it. What more could anyone ask?
The first was for the IBM 1401 (really!). iirc, it had a 2 or 3 digit exponent and 10 or more digit mantissa. It was just for fun, and never used for anything.
The second was for a Varian minicomputer. It was intended for an application that needed to solve a 19 x 19 system of linear equations. Since the Varian was a 16-bit machine, I used a format of 1 word (16 bits) exponent and 2 word (32 bits) mantissa. It was fun, it worked, and I was paid to do it. What more could anyone ask?
That's very interesting. Why not write about those experiences?
By the way, though I know what an IBM 1401 is, I had never heard of Varian and even their Wikipedia page is only like two paragraphs long. The Internet needs more information...
By the way, though I know what an IBM 1401 is, I had never heard of Varian and even their Wikipedia page is only like two paragraphs long. The Internet needs more information...
I'd heard of Varian but didn't know much about them. It turns out that Bitsavers has some Varian-related docs: http://bitsavers.trailing-edge.com/pdf/varian/
I haven't done much assembly (barring some FPGA programming I did in an undergrad course, and writing an editor on a Motorola processor).
This code so eminently readable. Is this the norm or is it Woz working his magic writing incredibly detailed documentation. Writing easily understandable code takes effort and wisdom. Anyone who writes code for a living knows the importance of writing code which is easy to read and maintain.
This code so eminently readable. Is this the norm or is it Woz working his magic writing incredibly detailed documentation. Writing easily understandable code takes effort and wisdom. Anyone who writes code for a living knows the importance of writing code which is easy to read and maintain.
I used to write a lot of ARM code in the 90s, and, though I say it myself, I thought it was all very readable code. Of course, it was more heavily commented than code I'd write in a higher-level language, but also it's about structuring it well: subroutines and, kind of, objects even.
Of course, it helped that the ARM instruction set was very simple back then.
Of course, it helped that the ARM instruction set was very simple back then.
"This code so eminently readable. Is this the norm or is it Woz...?"
It's super easy to write spaghetti code in assembler, so if you wrote any code of any size you really needed to be super careful in structuring and documenting it. Especially since in the "old days" your selection of identifiers (labels) was also often limited.
Plus assembly is generally pretty regular in structure so you can't rely on the "shape" of the code (e.g. indenting) to find your way, and it's not dense enough to allow a complete functional unit to fit in your fovea.
As a result of that, if you didn't write like Woz did here you ended up with write only code.
Plus Woz was also a very good developer.
It's super easy to write spaghetti code in assembler, so if you wrote any code of any size you really needed to be super careful in structuring and documenting it. Especially since in the "old days" your selection of identifiers (labels) was also often limited.
Plus assembly is generally pretty regular in structure so you can't rely on the "shape" of the code (e.g. indenting) to find your way, and it's not dense enough to allow a complete functional unit to fit in your fovea.
As a result of that, if you didn't write like Woz did here you ended up with write only code.
Plus Woz was also a very good developer.
And to be nitpicking - when you worked with FPGAs, you probably didn't do assymbly code either. Unless what was implemented in the FPGA was a cpu core.
FPGA design is not writing a program with instructions that are executed by a processor. It is describing real hardware with registers, wires, memories, pins and logic gates. This description is mapped onto the actual resources in the FPGA. The result might be a CPU that can execute instructions available as bit values in a memory, but quite often it isn't.
I know this is nitpicking - but as a HW designer I really have a problem when people use the term "FPGA programming". ;-)
FPGA design is not writing a program with instructions that are executed by a processor. It is describing real hardware with registers, wires, memories, pins and logic gates. This description is mapped onto the actual resources in the FPGA. The result might be a CPU that can execute instructions available as bit values in a memory, but quite often it isn't.
I know this is nitpicking - but as a HW designer I really have a problem when people use the term "FPGA programming". ;-)
It's been a few years since I played around with this. I think the FMUL subroutine is broken and the actual implementation just bypasses it altogether. Perhaps someone else more intimately familiar can confirm.
I think it's probably the bug with the log routine that you're thinking of:
http://www.6502.org/source/floats/wozfp2.txt
That's it! From this thread on the 6502 forums, FADD and FSUB work without having to complement the sign bit but FMUL isn't so lucky: http://forum.6502.org/viewtopic.php?t=508
Nice find!
Nice find!
Could someone knowledgeable in this area point out what's so interesting or noteworthy about this?
First of all, it's another cool thing by Woz. I've read a lot about him, but I didn't know he did a floating point implementation for the 6502. Second, the code is really beautiful, eminently readable.
[deleted]
Rather stereotypical that you've got a nice implementation of IEEE 754-1985 only 9 years before the standard was finalized. And this isn't the first "put a floating point number in 32 bits" implementation (this specific code was based on some HP2100 routines per the comments)
(edited to add, what I'm getting at is sometimes the standard is written a decade after the code is in use, like web standards, sometimes its the other way around like IPv6)
Note that Briel Computing sells at least two SBCs based on the 6502 and there may be other modern 6502 boards out there. The N8VEM project sells/sold bare PCBs for a "6502 on a S100 bus". I own all of the above. There is also a N8VEM 6502 board in redesign for the ECB bus which is kinda sorta one line summary a Kontron-like DIN41612 eurocard connector bus, probably exists because a genuine S100 connector is $15 and a DIN41612 because of the eurocard standard is like $3.
(edited to add, what I'm getting at is sometimes the standard is written a decade after the code is in use, like web standards, sometimes its the other way around like IPv6)
Note that Briel Computing sells at least two SBCs based on the 6502 and there may be other modern 6502 boards out there. The N8VEM project sells/sold bare PCBs for a "6502 on a S100 bus". I own all of the above. There is also a N8VEM 6502 board in redesign for the ECB bus which is kinda sorta one line summary a Kontron-like DIN41612 eurocard connector bus, probably exists because a genuine S100 connector is $15 and a DIN41612 because of the eurocard standard is like $3.
This is a lovely little library, but it is not "an implementation of IEEE 754-1985". The most important of the innumerable major differences:
- The representation is totally different (twos-complement signed significand and exponent instead of unsigned significand, biased exponent, and sign bit), one less bit of precision, no inf/nan encodings, and support for unnormalized encodings. - No rounding. Results are chopped. - Traps instead of defined results for all computations. - No guard bit[s] for subtraction.
If you're using "IEEE 754" to colloquially refer to "floating point", we can go back considerably earlier; at least to the Z3.
- The representation is totally different (twos-complement signed significand and exponent instead of unsigned significand, biased exponent, and sign bit), one less bit of precision, no inf/nan encodings, and support for unnormalized encodings. - No rounding. Results are chopped. - Traps instead of defined results for all computations. - No guard bit[s] for subtraction.
If you're using "IEEE 754" to colloquially refer to "floating point", we can go back considerably earlier; at least to the Z3.
Sad that the code syntax highlighting doesn't work on assembly
You can syntax highlight assembly, it's just not terribly useful since the structure is so consistent and simple to begin with.
Syntax highlighting in general is kinda silly. I'm sad that people turn their noses up at code that isn't drenched in unicorn vomit.
Syntax highlighting in general is kinda silly. I'm sad that people turn their noses up at code that isn't drenched in unicorn vomit.
Haha. Definitely can relate to some screenshots looking a little too LSD inspired, but I must say I appreciate having strings stand out separately. For one, I know right away if I have too many hardcoded strings dispersed throughout the code. And it also helps to catch quote closing, although basic syntax checker would also do that.
Yeah, I agree with all of that. Dim comments, tint strings and preprocessor/template/macro stuff, and we're good. Everything else is pointless at best and annoying when it inevitably screws up (color standard library functions differently? oh look, you missed one, and now it's going to bother me every time I use it. color built-in types differently? argh, now I'm going to want to use uint8_t instead of uint8 or U8...)
i read somewhere that Woz never wrote a floating point basic , and that was left to MS. if true, i'm glad it wasn't for lack of ability.
I am (very slowly) working on including all ROMs in my AppleII emulator in source form. Most usefully, this will eventually include writing an assembler that understands multiple old-school assembler formats. I have S-C Macro Assembler syntax implemented, at least enough to assemble the S-C Applesoft disassembly. https://github.com/zellyn/goapple2/tree/master/source (This is my first-ever assembler, so the code is likely horrible. I intend to read some other assemblers for tips, but wanted to bash my way through the problem myself first.)