💾 Archived View for librehacker.com › gemlog › tech › 20211013-0.gmi captured on 2024-05-10 at 11:37:01. Gemini links have been rewritten to link to archived content
-=-=-=-=-=-=-
One of the things I like about Punyforth is that it seems to embody a lot of the classic Forth ideals. For one, it uses the interesting and elegant Indirect-Threaded Code (ITC), rather than DTC or STC. While there are arguments to be made for DTC and STC from a performance standpoint, I nevertheless find ITC more interesting and beautiful, since words all become simple lists of single-cell addresses.
Another thing is that modules in Punyforth are stored as source code in flash memory, which are then executed when you load the module, compiling words into ram. Typically you'll be loading the modules you need during chip boot, using your turnkey word, but you can also load them anytime that you are logged into the chip. Though this uses more flash memory than compiling words to flash, like in flashforth, it does allows you to do all the development from inside the chip itself, if you want to. One of the original Forth ideals was that you should be able to do all development from the target device, without needing to rely on external programming tools, and thus Forths are supposed to include a block editor that can edit persistent storage memory, and also the ability to execute code given a block address.
With Punyforth, you can do this, provided that you initially load punyforth using the --block-format option, which adds space-padding to the source code blocks, so that they are readable when listing ("viewing") a block. Again, this requires more flash memory space, but on the ESP-12E you've got 4MB of flash to work with. You could also condense multiple word-definitions to a single row in a block if you got desperate for space, though that seems unlikely to happen in a typical Forth program.
Then you find a free block or blocks. This can be done by looking at the block map in block 81, using the list word from the FLASH module. Then edit and flush the block(s). Then edit block 81 to include a name and address for your module, so you won't have to remember the block number from then on.
Of course, you might be nervous about having all your source code stored on one flash chip with no backups. However, with esptool, it is easy to run a read_mem that will dump all the flash memory to a disk file - i.e., a snapshot backup.
I've create an asciinema recording which demonstrates what I have described above:
Asciinema recording demonstrating development with flash block editing
The part where I am running read_mem takes several minutes — you might want to skip through that part of the recording. Press space bar to pause, hold down the period key, and then press space bar again to continue playing the recording at normal speed. More information about asciinema is available here:
Sorry, you'll get a little confused in the recording if you pay close attention to the code and block numbers I used: In my mind I had confused block 148 with block 181 which I had been working with earlier outside the recording, so I was sort switching back and forth between the two in a confusing way. 😳