C R Bond's calc65 floating point arithmetic and transcendental function package:
http://www.crbond.com/calc65.htm
Uses 8 bytes and BCD to give 12 decimal digits and 3 exponent digits.

Via posting by "Repose" on CSDb forum
http://csdb.dk/forums/?roomid=11&topicid=91763

Edit: attached an archive to help anyone having trouble with the download:

Thanks for frequently posting this kind of thing. It's always good to pubicize the availability of resources like this. I just added it to my links page.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

Yes, thanks BigEd and Charles R. Bond..
Excellent write-up by Charles on his CBA65. Hashing mnemonics is the most interesting chapter in the .pdf. I'll read this .pdf many times as I would like to eventually tackle an assembler/disassembler for the 65Org16.b. There are many clues here.

Looks like Bruce used a similar technique for C'mon. Still reading...

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Ah yes, he's Charles - also Chuck - I couldn't find a name yesterday!

It's worth keeping an eye on "Repose" on that other forum, presently pursuing fast multiplication routines.

I read it, it's a novel idea.

But, really. Maybe if you're going to implement it on "heritage hardware" that kind of optimization will offer some value. It's not particularly space efficient, for example. It's 56 unique mnemonics on a 6502, and they're really short. But save on the slowest hardware I wonder how truly noticeable the benefit of the hashing function is.

I have modern hardware (well, 6 years modern hardware). My assembler assembles the Fig Forth listing, 4000 lines, 104K source file. It reads, does both passes, writes the listing and generates the 18K Intel Hex output in <2 seconds. And this is in routine Java, not a system famous for its lightning fast startup times. It barely has time to JIT anything up.

I think the impact of improved instruction lookup to the overall assembly process is low. If you don't have the memory for a hash, a binary search would do you just fine. Assemblers tend to be dominated by I/O, modern memory sizes are good at fixing that problem.

You mean Chuck who posts on our forum? Very cool!


Hmmm, Whartung you have a point there with modern systems that have large amounts of RAM. But think of a 'modern system' on a single FPGA. Block memory inside the FPGA is somewhat limited, so any program that is smaller is better. Not to mention most likely faster! We've gotten the best 6502 cores to speeds in excess of 100MHz.

BTW, good luck with your Fig-Forth project. It's interesting to follow your progress.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

Hashing and trees and caches for improving Forth compilation speed is discussed in the "dictionary hashing" topic under "Forth" at viewtopic.php?f=9&t=555 . The same stuff applies.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

No, not ChuckT. Just that there's a doc on his site where he refers to himself as Chuck.
Cheers
Ed

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Sure, but a Forth has an ever expanding, dynamic vocabulary that can reach in to the hundreds (if not more) of variable length words. Plus the typical word list is fragmented across memory (not an issue with 6502s per se). Finally, Forths tend to (but not necessarily as we all know) be hosted on the target, slow, low resource machine, not cross-compiled off a workstation.

But for a static list of 56, 3 character opcodes -- 168 bytes? I don't think the hashing will have that dramatic of an impact on overall performance of an assembler, especially on a 32 bit machine rated in several MHz. This hash happens to perfectly distribute the opcodes across 255 potential buckets. However, its not extensible. Add a new opcode, and the entire algorithm may need to be redone because it causes a conflict. Who knows.

Back in the day, three of the criteria that C compilers were judged were compiler speed, executable speed, and executable size. But once the PC/AT machines came out, much less the 386s, and we started pushing past 12Mhz, compiler speed fell off the map, mostly because it was dominated by slow I/O, and new faster CPUs with faster hard drives. Folks were more interested in debuggers and IDEs by that point anyway.

But optimizing opcode lookup? On a 32 bit machine?? And long word aligning the source code to make mnemonics fit properly in a long?? He still needs to look up pseudo ops, and possibly macros as well.

Smells of a pre-optimization to me. Sort the list and binary search it and be done if you're memory starved.

Like I said, mundane Java, large source file, <2s including startup and the full listing. No doubt it consumes several MB of RAM during run, but not enough to even kick off the garbage collector before its finished. I can assure you I will not be optimizing this assembler for performance any time soon.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes, my '816 Forth has many hundreds of primitives alone, not including secondaries.


but interestingly that makes them faster for development, because you don't need to re-compile the whole application every time you make a little change and transfer it to flash or whatever and re-start the target, etc.. You can type as little as a single line, or even just a word, and send it to the target and have it act on it immediately without necessarily even pausing a background job it's doing. I've even changed an ISR between interrupts that were coming at over 40,000 per second on my 6502 workbench computer, not pausing the interrupts. (To do that you get the new ISR ready and then change the vector to point to the new one.) Even a fast PC can't do that.

I definitely agree that assemblers and compilers running on modern PCs are plenty fast for what they do. I was just linking to a good discussion on various techniques for speeding up compilation on a not-so-fast machine, where I really liked the cache idea. (I have not implemented it yet though.)

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?

If I may interject. This does sound impressive... But 'fast PC' is a very subjective term. There must be a point where a PC can do that, just for arguments sake.

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Yes, it's assembly source. Try saving to disk and viewing as a text file (when viewed in-browser the line-ends are not rendered):