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
