I am experimenting with FlashForth on the Atmega 328P and find it both fun and easy to use. One of the things I am doing is to convert an old Finite State Machine implementation to FlashForth. However, I am having trouble with this, getting an unexpected behavour. After some troubleshooting I have located the problem to an unexpected behaviour with the words CREATE and >BODY.
Basically, if I create a word like this:
create test-word 1 , 2 , 3 ,
and then execute:
test-word u.
' test-word >body u.
I would have expected to get the same address in both cases and be able to access the comma-ed values through that address. In both Gforth and SwiftForth the address is the same. In FlashForth, however, I get two very different addresses instead (736 and 32780, respectively, after an empty warm). Doing a memory dump, it seems that the first address is correct and that the one given by ' test-word >body is wrong. Therefore, it is difficult to access the comma-ed numbers later.
I am only using ram at the moment (but will need to create the FSM in eeprom or flash later), but still suspect that this has something to do with the different memory types supported by FlashForth and that I am doing something wrong. Can anyone explain why ' test-word >body gives the wrong address in this case and how I should do to access the correct one instead?
The FlashForth version that I am using is FlashForth 5 Atmega 328 13.01.2019.
Thanks!
Mikael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hej,
Gforth works like traditional ram based forths usually do.
The behaviour is caused by the virtualizing of the memory types.
The value in the body of the created word is a pointer to the actual data area.
This is necessary to store the address of the data area permanently in flash.
Executing a created word actually performs (in optimized machine code)
I am experimenting with FlashForth on the Atmega 328P and find it both fun and easy to use. One of the things I am doing is to convert an old Finite State Machine implementation to FlashForth. However, I am having trouble with this, getting an unexpected behavour. After some troubleshooting I have located the problem to an unexpected behaviour with the words CREATE and >BODY.
Basically, if I create a word like this:
create test-word 1 , 2 , 3 ,
and then execute:
test-word u.
' test-word >body u.
I would have expected to get the same address in both cases and be able to access the comma-ed values through that address. In both Gforth and SwiftForth the address is the same. In FlashForth, however, I get two very different addresses instead (736 and 32780, respectively, after an empty warm). Doing a memory dump, it seems that the first address is correct and that the one given by ' test-word >body is wrong. Therefore, it is difficult to access the comma-ed numbers later.
I am only using ram at the moment (but will need to create the FSM in eeprom or flash later), but still suspect that this has something to do with the different memory types supported by FlashForth and that I am doing something wrong. Can anyone explain why ' test-word >body gives the wrong address in this case and how I should do to access the correct one instead?
The FlashForth version that I am using is FlashForth 5 Atmega 328 13.01.2019.
Thanks!
Mikael
Hej,
Gforth works like traditional ram based forths usually do.
The behaviour is caused by the virtualizing of the memory types.
The value in the body of the created word is a pointer to the actual data area.
This is necessary to store the address of the data area permanently in flash.
Executing a created word actually performs (in optimized machine code)
Last edit: Mikael Nordman 2020-07-03
I have updated >BODY to return the data field address.
So now >BODY returns the same address as a created word.