dxa's development was a little more colourful. This started with a file that didn't disassemble correctly (Paradoxon BASIC from 64'er, as it happens) because apparently d65 was never able to handle files that stretched riiiiiiiiiiiight up to the very last addressible byte ($ffff), let alone files that overflowed the addressing space or were bigger than 64K. However, even with that problem fixed, this particular test file also caused dxa to emit completely nonsense branches with unpossible displacements and even jumps to non-existent labels. This violates its core guarantee that you should be able to take dxa's output, feed it back into xa and get the binary you started with. It turns out that this is due to some weird C casts used for interpreting relative branches, so I made them more explicit, plus changes in the C preprocessor that caused the macro to check if a label exists to evaluate to true in one place and false in another. I think this file made a great test vector, so now dxa has a test suite too (make test; xa is naturally required) using it and a DOS wedge routine, and I'll probably throw in more exemplar code in the future. This new test suite is already earning its keep: it found a new bug when dxa is compiled with clang, which required even more reworking of the same section and some nearby code. Interestingly, even though now the test suite passes on all the same platforms as xa, dxa-built-with-clang generates subtly different output than dxa-built-with-gcc despite the fact the assembly files they both generate will yield bitwise identical binaries. Most of this seems to circulate around detecting vectors; clang flavour finds this in some places that gcc doesn't and vice versa. It's deterministic and predictable, but I'm not sure which one of them is "doing it right," so for now it'll be a curiosity until I can dig more into the differences.
Both xa and dxa are available under the GNU Public License v2.
0 Comments