DO_EXECUTE:
lw x10, 0(x17) # @W, address of some executable code
addi x17,x17,4 # INC W, points now to PFA
jalr zero,x10,0 # jump to code
On Mon, Jan 5, 2026 at 5:28 PM John Sarabacha <[email protected]> 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
