Hi Tristan,
Here is a portion of my assembly listing for the CH32X033
000015aa <PFA_DOCONDBRANCH>:
15aa: 00018293 mv t0,gp
15ae: 00022183 lw gp,0(tp) # 0 <Flag_visible>
15b2: 0211 addi tp,tp,4
15b4: fe5005e3 beq zero,t0,159e <PFA_DOBRANCH>
15b8: 0811 addi a6,a6,4
15ba: c8cff06f j a46 <DO_NEXT>
000015be <XT_DOLITERAL>:
15be: 15c2 slli a1,a1,0x30
...
000015c2 <PFA_DOLITERAL>:
15c2: 1271 addi tp,tp,-4
15c4: 00322023 sw gp,0(tp) # 0 <Flag_visible>
15c8: 00082183 lw gp,0(a6)
15cc: 0811 addi a6,a6,4
15ce: c78ff06f j a46 <DO_NEXT>
15d2: 5555 li a0,-11
You can see clearly that XT_DOLITERAL structure has the link address 15c2
and the PFA_DOLITERAL was placed
at that address. This is not 32 bit aligned and triggers an exception in my
debugging session which MounStudio is able to capture.
The compiler/assembler is doing this.
On Mon, Jan 5, 2026 at 6:02 PM John Sarabacha <[email protected]> wrote:
> Hi Tristan,
> Thank you this is making more sense.
>
> John S
>
> 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
