How is it related to the development approach that you're are using for zeptoforth?

I must admit that a Forth-native assembler (and disassembler) would be an asset. Due to the modified STC in STM8 eForth I rarely felt the need for a disassembler (I used uCsim when I needed it - but it turned out to be a bug in uCsim that created that need).

I'm now questioning whether a Forth-native Thumb-2 disassembler is a good idea, simply in numerical terms; I am only on 'BL' and 'BLX' right now, and yet there are ~650 lines of code despite my trying to reuse code whenver possible. If each of these lines was a 16-bit Thumb instruction,  that would mean that that would add up to 1.3K  of memory, but that is not true, there are almost certainly more bytes per line than that, even taking comments and blank lines into account.

Sometimes the logic of instruction encoding his difficult to "factor". The last partial disassembler I wrote was for a C167 (alias ST10), and the only one that was kind of complete was for the 6502 (maybe 35 years ago ;-) ).

I have been thinking of ways to factor it more. It turns out that the Thumb-2 instruction set reuses the same fields for different things a lot. Therefore, if a field is used in many places, I can factor out the whole field access (and for the sake of efficiency do some rather un-Forthy things such as returning inputs), reducing the number of bytes needed in the code.