scotws
commented
4 years ago Thanks for all of this, again.
I think you're right with a new branch, and this might be the time to sit down and think about how to restructure the repo so there is no confusion. I've been look at something like https://gist.github.com/digitaljhelms/4287848 with stable and master, but in our case we have two assemblers.
Right now, I'll just call this master-64tass I'll need to sit down when I'm wide awake and carefully make sure I don't screw this part up :-).
Long term, the question is if it would make more sense to have stable-ophis (current Tali) and master-ophis (Tali in Ophis for bug fixes), and then stable and master as the 64tass stuff. I'm not sure, however, if that would mess up people who just want to stay with Ophis and are happy with simple bug fixes. This should probably be discussed as an issue.
I highly recommend that you create a new branch for this and merge into that, as there are still supporting materials (like the documentation) that need to be updated before merging it into your master.
What you get: A version of Tali that assembles with 64tass and passes all tests. I've updated the generate_wordlist.py utility because 64tass uses a different format for it's lablelmap file. I removed all scoping, although please note that 64tass considers labels that begin with an underscore to be local between the two normal labels they appear between - this works for many cases but had to be cleaned up in a few spots (see ed.asm, for example). I updated all of the existing platform files, but could only test the py65mon and sbc platforms.
Still left to do: Update the documentation - include how to get/compile 64tass as it's not available as a package on all systems. Consider upgrading all local and anonymous labels to full labels. Update the code_statistics.py utility as anonymous lables can be + or - instead of just *.