Commander X16

Sure is.

Any idea about a suitable hash function?

No, not really... All good string hash functions use multiplications and we can't do that on the 6502 and also still keep it fast...

Maybe it's worth looking at CRC-16 and CRC-32.

Probably not ideal, but seems to be easily calculated. Is it good enough for your purpose?

One implementation is found here (without lookup tables): http://www.6502.org/source/integers/crc-more.html

And another here (with tables): http://www.6502.org/source/integers/crc.htm

22 hours ago, desertfish said:

No, not really... All good string hash functions use multiplications and we can't do that on the 6502 and also still keep it fast...

The question is what you are aiming for with the hash. A hash that AIMS to avoid collisions, so collisions are a special case, is one approach, another is to just accelerate things compared to a sorted linked list or binary tree by having more but substantially smaller linked lists or trees, so that they do not get bogged down to the same extent as the wordspace grows.

Then something as simple as the bottom four bits of the XOR of the bytes in the name may serve well.

The current symbol table implementation is simplistic but should be easily replaceable with a different smarter one. Because it has a very basic interface to the assembler logic itself. I don't think I have the time to build a smarter symboltable myself, so hopefully someone else can jump in, who knows ?

On 2/28/2021 at 7:07 AM, Stefan said:

Sure is.



Any idea about a suitable hash function?

https://en.wikipedia.org/wiki/Linear-feedback_shift_register#Galois_LFSRs

https://github.com/eternal-skywalker/cx16-lib/blob/main/lfsr.s

David Murray mentioned using an LFSR to generate random maps in a game instead of manually creating and storing them.

A hash function needs more than this, but it is something to start with.

 

Updated the assembler, added the feature to save the assembled program to disk.

(note that assembling is still done into system memory first as intermediary step, this is something that will be changed in a future version to allow to assemble larger programs)

Updated again to cache the source file in memory, resulting in a large speedup because the file doesn't have to be read twice anymore.

For now, source file size is now limited to 62 Kb because of this change.

Update again with new file load routines. Note that a patched V39 ROM is required to run this correctly because it depends on the kernal's LOAD routine to work correctly across ram banks.

The framework for loading multiple files is now in place and we have ample RAM to store them into - we're now using hiram banks so we can store hundreds of kb of source files.

So the next thing to do in the next version is to implement some sort of .INCLUDE "file.asm" directive to be able to read from multiple source files.

Hi!

I tried your new version. After some fiddling, not properly reading the instructions, and so on, I got it to work.

I wrote a simliar test hello world program to yours, and it worked great. I could also restart the assembler without reloading it from disk after compiling, loading and testing the assembly program.

Very nice job so far!