This release reorganizes the words that related to HERE, so that by default the unmarked words using HERE now use the HERE related to the current compilation mode, and that words that use a specific HERE are explicitly marked with RAM or with FLASH. Note that this does not affect words which do not use HERE, e.g. !, CURRENT!, and FLASH! stay as is. Additionally, more documentation has been added, particularly with regard to multitasking and scheduling.
Discussions
Become a Hackaday.io Member
Create an account to leave a comment. Already have an account? Log In.
When I developed a solution to the HERE dependency I found that one easily overlooks edge cases. A bit of a challenge was VARIABLE. Are you aware of a standard or could you identify a best practice?
Are you sure? yes | no
I am not aware of any (ANS to my knowledge ignores the issues associated with flash memory). My solution was to save the future address of the VARIABLE in flash, then apply all the allotted space for the VARIABLEs at the following reboot. This has worked well for me.
Are you sure? yes | no
That's certainly a good solution for a µC with a fair amount of RAM. Does that mean that you have to erase/write Flash locations often or do you use some kind of log that's flushed every so often?
In STM8 eForth I decided to keep pointers in RAM when in NVM (Flash) mode. Some users had problems with that approach (read: lost changes until the cycle was understood).
Are you sure? yes | no
What I meant is that I precalculate the future address of the VARIABLE in RAM and write that too flash, and then when I reboot I find the last of these precalculated address and ALLOT the memory space for the variables accordingly.
Are you sure? yes | no
STM8 eForth also pre-allots memory but there is a catch: as the dictionary in RAM grows from the bottom and the stack grows from the top (with the pad in the middle), I decided to reserve some memory below the dictionary (but not by using ALLOT, which I will look into). A COLD start (or a semi-warm WIPE) then places the start address for the dictionary again above that memory area used by VARIABLE. The catch is that sometimes WIPE or COLD has to be run before using VARIABLE memory that otherwise would overlap with the (temporary) dictionary in RAM. Variables defined in RAM mode are embedded in the dictionary and can be used right away (there is a direct variant of DOVAR for RAM and an indirect one for Flash memory).
Are you sure? yes | no
I actually think how zeptoforth and STM eForth do things are quite similar here. zeptoforth allocates space for VARIABLEs allocated during flash compilation at the bottom of the main task's dictionary and only ALLOTs space for them on REBOOT. Note that VARIABLEs allocated during RAM are allocated at the top of the dictionary for the current task. Additionally USER variables are ALLOTed from the bottom of each task's dictionary when it is created, except for the main task, where it is ALLOTed after the flash-allocated VARIABLEs are ALLOTed.
Are you sure? yes | no