Travis BemannI have gotten the disassembler into such a state that it can now disassemble Forth code compiled by zeptoforth, even though it probably is not bug-free yet. There is no word SEE yet, due to issues with determining the end of Forth words; rather one must use DISASSEMBLE, which takes a starting address (equivalent to an xt) and an ending address, which unfortunately requires one to guess how long a given word is in memory.
I plan on creating a new release containing the disassembler, but I do not have time to do so tonight, and I also want to do some more testing to make sure I have gotten the bugs out before I unleash it upon the world (note however that the code is already available on GitHub if one really wants to try it out).
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
Inferring structure from code can be hard. End markers of any kind may help, e.g. the start of the next word in the dictionary, or some kind of extra code, a "boundary maker" perhaps. That's what historically worked for bringing the metaphysical idea of "boundary" into the physical world ;-)
Are you sure? yes | no
In my code, for determining the end of inlining, I put a special token at the end of inlined kernel words, namely $003F (i.e. MOVS R7, R7), which I also put at the end of Forth-compiled words. However the problem is that I did not put it at the end of non-inlined kernel words. I could use this, but I will need to go back and add it to all the non-inlined kernel words.
Are you sure? yes | no
This marker can be relied on where it is specified because it always comes after either a BX or a POP instruction, making it unlikely to be confused with inline data in practice.
Are you sure? yes | no