Hi, My suggestion is to keep in sram as much as possible, there are more advantages in doing this. Flash write cycles are limited approx 100K times, sram does not have this limitation. Also Cortex-m4 and RISCV processors have flash wait state considerations (even with caching) and sram doesn't, this impacts performance.
John S On Tue, Jan 6, 2026 at 2:01 PM Martin Kobetic <[email protected]> wrote: > Hi Tristan, > > So to get back to the variable problem and how to deal with it. Is it > possible to summarize the problem as: "DP and HERE must be in separate > memory regions." ? If so there are many ways to satisfy this constraint. We > could assign separate SRAM regions for these purposes. It's also not clear > to me why we can't put DP back into the flash memory. I don't know about > the RISC-V side but RA4M1 supports "self-programming" (chapter 44.13), so > it seems it would be just a "small matter of programming" to get it > working. Are there any other options you are considering? > > Cheers, > > Martin > > On Mon, Jan 5, 2026 at 5:40 PM <[email protected]> wrote: > > > Hi John, > > > > The notes I took at the time are at the bottom [1] and go into some > > detail. I've split out the main points below, so hopefully the full > > notes will be clearer. > > > > The key point is that variables defined in the flash dictionary when the > > svn RISC-V AmForth is assembled (using the assembler macro you found) > > work just fine. A dictionary entry for the variable is created in flash > > and points to a correctly allocated area of memory in RAM. > > > > Variables defined at the prompt are different. They use the colon word > > "variable" to dynamically generate the dictionary header and allocate > > the RAM required. At this point the RISC-V svn code is storing the > > dictionary entry in RAM, and is allocating the memory required for the > > variable from that same "block" of RAM. The existing codebase colon > > definition for variable is not set up for this. Because of this, a store > > ! to the variable defined at the prompt overwrites part of the > > dictionary header in RAM, corrupting the dictionary, which when > > accessed, results, in this case, with a hang. > > > > There are ways to deal with this, one option is explored in the link. > > There are others. I wanted to highlight some of the issues/choices > > associated with dictionary storage and RAM allocation. > > > > Best wishes, > > Tristan > > > > [1] https://tjnw.co.uk/amforth-rv/20231107/20231107.html > > > > > > On 2026-01-05 22:28, John Sarabacha wrote: > > > when a X @ sequence is entered after > > > $AABBCCDD X ! > > > The interpreter may do a XT_EXECUTE so if > > > $AABBCCDD is on tos x3 register > > > > > > CODEWORD "execute",EXECUTE > > > > > > mv x17,x3 > > > loadtos > > > j DO_EXECUTE > > > > > > this would spell trouble and give an exception, and the worst part is > > > the > > > loadtos would > > > hide the problem because now x17 is propagating an unexecutable code > > > address being on a byte boundary and a stack dump is not going to show > > > this > > > (.s) > > > This may have been planned as a feature to support the execution of > > > code in > > > ram > > > > > > This is starting to make sense. > > > John S > > > > > > On Mon, Jan 5, 2026 at 4:05 PM John Sarabacha <[email protected]> > > > wrote: > > > > > >> Hi Tristan, > > >> I tried this sequence on ESP32Forth and there were no issues. > > >> > > >> in RISCV > > >> >> variable X > > >> >> creates the structure below in ram > > >> .macro VARIABLE Name, Label > > >> HEADER Flag_visible|Flag_variable, "\Name", \Label, PFA_DOVARIABLE > > >> .word rampointer > > >> .set rampointer, rampointer+4 > > >> .endm > > >> > > >> >> $AABBCCDD X ! > > >> >> rampointer (above) is where the address where $AABBCCDD is stored > > >> > > >> CODEWORD "!", STORE # ( x 32-addr -- ) --> ( $AABBCCDD rampointer-X > > >> -- ) > > >> lw x5, 0(x4) x5 (temp reg) is loaded with > > >> rampointer-X from 0(x4) by indexing x4 (Data Stack Pointer) > > >> sw x5, 0(x3) ramponter -X is written to ram > > >> location > > >> pointed by address in tos (x3) > > >> lw x3, 4(x4) x3 tos is loaded from 4(x4) > > >> indexing of > > >> x4 (now has initial value $AABBCCDD ) > > >> addi x4, x4, 8 Data Stack Pointer is incremented by > > >> 8 > > >> NEXT > > >> > > >> This is not behaving as it's description ( x 32-addr -- ) this segment > > >> of > > >> code is leaving $AABBCCDD on tos x3 register > > >> whether this is part of the problem ??? > > >> > > >> Regards, > > >> John S > > >> > > >> On Mon, Jan 5, 2026 at 3:28 PM <[email protected]> wrote: > > >> > > >>> Hi John, > > >>> > > >>> Here is the sequence of words working correctly. The results > > >>> would be similar for any 32 bit Forth. Try it on ESP32Forth. > > >>> > > >>> |S| 1|hex > > >>> |S| 2|variable x > > >>> |S| 3|x u. > > >>> |O| 3|20000950 > > >>> |S| 4|aabbccdd x ! > > >>> |S| 5|x @ u. > > >>> |O| 5|AABBCCDD > > >>> |W| 6| > > >>> > > >>> There is no writing to or reading from a misaligned address, > > >>> so whilst it can be a major issue, it is not the issue here. > > >>> > > >>> The issue with with the svn repo code is as described in the > > >>> link. I wanted to mention it as it will raise some questions > > >>> about about flash/ram and dictionary/variable storage that I > > >>> wish I had considered earlier than I did. It seemed a good > > >>> moment given that Martin had just got a prompt on the UNO R4. > > >>> > > >>> Best wishes, > > >>> Tristan > > >>> > > >>> On 2026-01-05 17:36, John Sarabacha wrote: > > >>> > AmForth is doing exactly what it is told to do, looks like the code > > >>> > base is > > >>> > functional, the processor (Cortex-M4/RISCV) is doing what it is > > >>> > supposed to > > >>> > do. It is up to the user to supply the correct information > otherwise > > >>> > the > > >>> > processor will complain (exception out). > > >>> > > > >>> > On Mon, Jan 5, 2026 at 12:27 PM John Sarabacha < > [email protected] > > > > > >>> > wrote: > > >>> > > > >>> >> The other possibility is that it is not a valid address that the > > >>> >> processor > > >>> >> can access which could cause an exception > > >>> >> > > >>> >> On Mon, Jan 5, 2026 at 12:18 PM John Sarabacha < > > [email protected]> > > >>> >> wrote: > > >>> >> > > >>> >>> So when you execute X @ you are trying to indirectly read from > the > > >>> >>> address 0xAABBCCDD > > >>> >>> which could cause an exception > > >>> >>> > > >>> >>> On Mon, Jan 5, 2026 at 12:08 PM Martin Kobetic < > [email protected] > > > > > >>> >>> wrote: > > >>> >>> > > >>> >>>> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha > > >>> >>>> <[email protected]> > > >>> >>>> wrote: > > >>> >>>> > > >>> >>>> > Still learning forth , programmed in many other languages > (alot > > of > > >>> >>>> > assembler) > > >>> >>>> > variable X > > >>> >>>> > $AABBCCDD X ! > > >>> >>>> > X @ > > >>> >>>> > > > >>> >>>> > However tell me if I am wrong, you are creating a variable > > >>> definition > > >>> >>>> for X > > >>> >>>> > you are setting this variable X to the address $AABBCCDD and > > then > > >>> >>>> trying to > > >>> >>>> > read a value from this > > >>> >>>> > address on to the tos. > > >>> >>>> > > >>> >>>> > > >>> >>>> Almost. The second line is storing value 0xAABBCCDD at the > > address > > >>> >>>> represented by variable X. > > >>> >>>> It is the word `variable` in previous line that allocates memory > > for > > >>> >>>> the > > >>> >>>> variable and associates the corresponding > > >>> >>>> address with a new word `X` that simply pushes that address onto > > the > > >>> >>>> stack > > >>> >>>> when executed. > > >>> >>>> > > >>> >>>> In the test run I quoted above > > >>> >>>> --- > > >>> >>>> > X > > >>> >>>> ok > > >>> >>>> > .s > > >>> >>>> 5 200002B8 200002C4 200002A8 20000288 8 ok > > >>> >>>> --- > > >>> >>>> The address represented by the variable was 0x200002B8, so it > was > > >>> >>>> 8-byte > > >>> >>>> aligned, so should be ok alignment-wise. > > >>> >>>> But your hypothesis with alignment issues seems definitely worth > > >>> >>>> checking > > >>> >>>> out as well. > > >>> >>>> > > >>> >>>> Your warning about the fault interrupts is certainly worth > > heeding, > > >>> >>>> I > > >>> >>>> don't > > >>> >>>> think we do much there on the ARM side. > > >>> >>>> Another thing to follow up on. > > >>> >>>> > > >>> >>>> _______________________________________________ > > >>> >>>> Amforth-devel mailing list for http://amforth.sf.net/ > > >>> >>>> [email protected] > > >>> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > >>> >>>> > > >>> >>> > > >>> > > > >>> > _______________________________________________ > > >>> > Amforth-devel mailing list for http://amforth.sf.net/ > > >>> > [email protected] > > >>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > >>> > > >>> > > >>> _______________________________________________ > > >>> Amforth-devel mailing list for http://amforth.sf.net/ > > >>> [email protected] > > >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel > > >>> > > >> > > > > > > _______________________________________________ > > > Amforth-devel mailing list for http://amforth.sf.net/ > > > [email protected] > > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > > > _______________________________________________ > Amforth-devel mailing list for http://amforth.sf.net/ > [email protected] > https://lists.sourceforge.net/lists/listinfo/amforth-devel > _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ [email protected] https://lists.sourceforge.net/lists/listinfo/amforth-devel
