Mecrisp Forth’s memory use

Added by tve about 2 months ago

The one thing that has bothered me the most about the way mecrisp (and forth in general) works is that I can't redefine a word in-place. That single issue kills a lot of the interactivity for me because most of the time, while testing, I need to fix a word that is used by other words. Just redefining that word interactively doesn't help anything because the other words continue to use the old incorrect version. So then I have to reload the whole pgm anyway, making the difference to a compiled system rather small. I wish there was some way to patch a word. One possible way would be to have mecrsip erase and rewrite the flash block. Perhaps the simplest would be for the new definition to be compiled as usual but then to patch the old implementation with a jump instruction into the new def. All this would actually be pretty simple when definitions are in RAM, which is usually the case for the stuff I'm hacking on.

Replies (2)

RE: Mecrisp Forth’s memory use - Added by jcw about 2 months ago

(for reference: link to weblog article)

Yes, this is an issue. Classic Forths have a defer word which can be used to define words later. This appears not to be possible with the flash-based Mecrisp Forth, and it's really unfortunate, IMO.

But... once you know you need to tinker and mess with a word, say blah, then perhaps you can temporarily replace ": blah ... ;" with:

' nop variable 'blah
: blah 'blah @ execute ;

... and then later, while trying stuff out, even in RAM, define the missing code:

: (blah) ... ; ' blah 'blah !

(there's probably a more elegant way to do this using <builds and does>)

It requires a little preparation up front, and you'll need to clean up once it's done, but IMO it's at least a way out.

What I tend to do, is move the troublesome word down in the source code as far as I can, and then put everything before it in a separate file, which can then be compiled to flash. Often (not always), that ends up being enough to fit the trouble-spot in RAM. Also, sometimes you don't need to run everything to exercise a buggy word, so another approach is to just leave everything in flash, and then override the bad word plus a small ad-hoc set of test words, just to figure out the problem and get things working.

RE: Mecrisp Forth’s memory use - Added by jcw about 2 months ago

Maybe the profile.txt or trace.txt code from here can be used to construct a more after-the-fact-hackable setup?