That's a great write up, Tristan. I need to figure out a way to debug scenarios requiring user input. I'm currently using the same USB connection for connecting OpenOCD to the board, so I can't run serial I/O while I'm debugging. I'm guessing there isn't any simple solution that won't require a separate debug connection, I just haven't figured out how to do that yet. The best workaround I could think of is to simulate input by preloading the TIB with the content I'd type in, although that's fairly cumbersome. Currently I just code up the scenario I want to debug in the turnkey word and throw an XT_HALT word in there somewhere (halt just invokes wait-for-interrupt instruction which isn't quite a halt instruction but does the job while I'm not really using interrupts for anything), and then reset the board under debugger.
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
