zeptoforth

This release fixes two issues with the disassembler, the first being that disassembling 16-bit PC-relative LDR instructions was causing the disassembler to crash, the second being that if multiple B instructions pointed at the same address, separate entries were being created in the branch table for each of them (but only the first would be used later, resulting in missing branch target numbers).

Numbered local labels have been added to the disassembler to support labeling B instructions, rather than simply providing a target address and nothing more (especially since this is not the normal type of syntax used by assemblers). With this, when used in "gas mode", the generated assembly should be able to be fed into an assembler. The only caveat is that if this code were inserted into the codebase of zeptoforth, the naming conventions used within the zeptoforth kernel do not match those generated by the disassembler as the disassembler labels instructions based upon the Forth names of the words in question, which in "gas mode" are modified to fit the conventions expected by an assembler.

This is a patch-level release that includes revamped documentation (now using py.sphinx and recommonmark for conversion to HTML), along with line labels being added to generated assembly and the addition of bit@/hbit@/bbit@, for aiding the development of automatically generated hardware interface code from CMSIS.

This is a patch-level release which adds DISASSEMBLE-FOR-GAS and SEE-FOR-GAS, which are like DISASSEMBLE and SEE, but are meant for having their output fed into an assembler (e.g. gas) rather than it being meant for human consumption.

Release 0.5.0 is out! This release contains the disassembler, which is invoked via SEE and DISASSEMBLE (the former takes a word name, the latter takes an address range). There may still be bugs in it, but it is functioning well enough at this point that I figured that it should be officially released as part of the zeptoforth_full-$VERSION.bin binaries rather than having to be manually loaded and compiled by the user.

I have now added a working SEE word to the disassembler, to enable the user to disassemble whole words, both compiled from Forth source code and built into the zeptoforth kernel. There are still a few kernel words that include instructions not decoded by the disassembler, but these are very few. I will soon produce a new release including the disassembler. Considering the size of the flash on the MCU's I am targeting, it does not make sense to make separate binaries with and without the disassembler, particularly with how padding out flash for the purposes of implementing CORNERSTONE works on the STM32F407 (which currently results in significant quantities of wasted flash space that could be taken up, in part, by the disassembler).

I 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).

The initial coding phase of work on the disassembler is now complete. Now I just have to get the bugs out... (of which there certainly are many; right now it will not even decode a BL instruction properly). The disassembler turned out to weigh in at about 20K, smaller than I expected, but that is probably because of how aggressively I excluded instructions not used by zeptoforth.

Progress is being made on the disassembler; going in alphabetical order, I am now at MOV. Note that many instructions not used within zeptoforth are being omitted, and even then it will almost certainly be very large in memory footprint (it will likely have to be compiled to flash, as if it fits in RAM in the first place it will likely take up a good portion of it).

A Thumb-2 disassembler is in the works for zeptoforth. It will be quite some time until it is ready - the Thumb-2 instruction set is rather complex - but work has started on it. Note that there will be a slowdown in work on other new features, since my spare time will be taken up by work on the disassembler.