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

Reply via email to