amforth-devel — Development discussion and user support

Re: [Amforth] 32 bit amForth alignment issues

[John S. <jsa...@gm...>]

Hi Tristan,
>> The CH32X033 chip also hosts an additional eight bit RISC processor
>> (pioc)

> I didn't know about this. Interesting.

If you dig deeper you will find the embedded 8 bit RISC processor
(co-processor) appears to be a clone of the PIC16F84 in terms of
instruction set (with 32 bit register capabilities) and runs independently
from the main RISCV core at the same speed of the core 48Mhz and can be
programmed by the host processor.

https://github.com/andelf/pioc

Happy forthing,
John S

On Wed, Jan 7, 2026 at 10:11 AM John Sarabacha <jsa...@gm...> wrote:

> Hi Tristan,
> The change that made things work, in the risc-v\dict_prims.inc file:
> line 43
> #      lw x10, 0(x17) # @W, address of some executable code
>         lh x10, 0(x17) # @W, address of some executable code
>
> This works because on a CH32x033 the dictionary resides in flash below the
> 64K boundary
> addressable by a halfword (16 bits), and only has 62K of flash. By doing
> this you can also keep the dictionary more compact in flash.
> For larger flash devices where the dictionary resides is going to be a
> factor to consider, some RISCV processors may not have an issue in crossing
> 32 bit word boundaries but the one for CH32x033 does. The RISCV processors
> that don't have this issue (CH32V307?) can use the lw (load word) version
> of the instruction. The CH32V003 -> CH32V007 and CH32V203 should use the lh
> (load halfword) version.
>
> Hope this helps others who want to use amforth on smaller RISCV chips
> John S
>
> On Wed, Jan 7, 2026 at 9:35 AM John Sarabacha <jsa...@gm...>
> wrote:
>
>> Hi Tristan,
>> I had sent a couple of pictures (of this environment) that apparently is
>> being held by the sourceforge administrator for review because of the size
>> of the email.
>> The mcu uses it's own internal clock (fixed at 48Mhz) without any
>> issues,  breakout boards are also being used, the chips are soldered to the
>> break out boards using solder paste and a T-962 oven (available from
>> amazon). The breakout boards with the chip (mcu) become nodes on a network
>> (similar to a RS485 type of network). It now becomes possible to go even
>> smaller (CH32V003 ... CH32V007) but the cost these chips vs CH32X033
>> doesn't give you a better advantage (e.g size of sram and features). Where
>> amForth is useful here is programming these chips remotely and changing
>> these programs as needed. AmForth was the missing piece of the puzzle, the
>> CH32X033 is a node on a network already functional and communicating with
>> PIC16F1824 nodes and running for years without significant problems but not
>> easily re-programmable remotely. Things have changed significantly, compare
>> the cost of a CH32X033 (32 bit) chip vs PIC16F1824 (8 bit) not to mention
>> sram and flash size differences.
>>
>> Regards,
>> John S
>>
>> Regards,
>> John S.
>>
>>
>>
>>
>> On Wed, Jan 7, 2026 at 2:30 AM <ho...@tj...> wrote:
>>
>>> Hi John,
>>>
>>> A very interesting and ambitious use of AmForth! Sounds like you
>>> overcame your compiler/linker alignment issue.
>>>
>>> > The CH32X033 chip also hosts an additional eight bit RISC processor
>>> > (pioc)
>>>
>>> I didn't know about this. Interesting.
>>>
>>> > The test environment is very simple, a CH32V033 chip in a
>>> > 20 pin chip adapter connected to a WCH-LinkE and using
>>> > MounStudio v2.3.0 for programming and debugging.
>>>
>>> How are you clocking the mcu?
>>>
>>> Best wishes,
>>> Tristan
>>>
>>>
>>> On 2026-01-07 05:41, John Sarabacha wrote:
>>> > The CH32V033 is now able to execute the amForth XT words without any
>>> > problems, MounStudio with debugging allowed me to set program break
>>> > points
>>> > to see the execution of each XT code segment along with the registers
>>> > (tos,
>>> > ip, sp dp) so it looks very promising. The vendor's startup code and C
>>> > libraries are used to initialize system clocks, peripherals (usart,
>>> > GPIO...) this saves a tremendous amount of work.
>>> > The existing flash image contains the dictionary that the hifive
>>> > application used which is an overkill for what my application needs,
>>> so
>>> > the
>>> > next step is to remove unnecessary dictionary entries e.g
>>> > initialization
>>> > (commenting out the unnecessary include files) and rebuild the image.
>>> > The amForth codebase in CH32V033 will use the C library drivers for IO
>>> > (usart, gpio, pioc, networking ... ).  The CH32X033 chip also hosts an
>>> > additional eight bit RISC processor (pioc) which amForth can work with
>>> > for
>>> > high speed custom IO. To test the amForth code and dictionary a test
>>> > sequence of XT tokens will be passed to the amForth VM (execution
>>> loop)
>>> > and
>>> > monitor the results (tos ... ). The test environment is very simple, a
>>> > CH32V033 chip in a 20 pin chip adapter connected to a WCH-LinkE and
>>> > using
>>> > MounStudio v2.3.0 for programming and debugging.
>>> >
>>> > Hope this information is useful to others,
>>> > John S
>>> >
>>> >
>>> > On Tue, Jan 6, 2026 at 4:37 PM John Sarabacha <jsa...@gm...>
>>> > wrote:
>>> >
>>> >> Hi Tristan,
>>> >> Some good news,  CH32V033 is now able to run amForth co-existing with
>>> >> C
>>> >> and other inline routines. A change was made to the the execution loop
>>> >> which doesn't impact performance and the keeps image size to a
>>> >> minimum.
>>> >> Next step is to test amForth using C code to pass ascii strings to the
>>> >> interpreter to see if it works.
>>> >>
>>> >> Regards,
>>> >> John S
>>> >>
>>> >>
>>> >>
>>> >> On Tue, Jan 6, 2026 at 3:14 PM John Sarabacha <jsa...@gm...>
>>> >> wrote:
>>> >>
>>> >>> Hi Tristan,
>>> >>> This has and is being looked at. The linker appears to be the
>>> >>> problem. I
>>> >>> have tried a few
>>> >>> things like changes to the macros with some success. With these
>>> >>> successes
>>> >>> the image sizes grow.
>>> >>> The run time execution loop is able to function until it hits a
>>> >>> halfword
>>> >>> address then it exceptions out.
>>> >>> As a temporary workaround I am looking at handling the exception
>>> >>> gracefully and resuming the execution
>>> >>> loop,  this way the image size can be kept smaller. The good news is
>>> >>> that
>>> >>> it (amForth) is able to co-exist with
>>> >>> my existing application which is a mix of C and inline assembler
>>> >>> routines.
>>> >>>
>>> >>> Regards,
>>> >>> John S
>>> >>>
>>> >>> On Tue, Jan 6, 2026 at 1:53 PM <ho...@tj...> wrote:
>>> >>>
>>> >>>> Hi John,
>>> >>>>
>>> >>>> Check your compiler/assembler/linker options to see whether they
>>> >>>> allow
>>> >>>> free reign to use RISC-V compressed instructions wherever they think
>>> >>>> appropriate. Then, as a first cut, turn that off globally. There are
>>> >>>> various ways to be more selective, but it very much depends on how
>>> >>>> much
>>> >>>> their use matters to you.
>>> >>>>
>>> >>>> Best wishes,
>>> >>>> Tristan
>>> >>>>
>>> >>>> On 2026-01-06 16:33, John Sarabacha wrote:
>>> >>>> > Hi everyone,
>>> >>>> > When mixing C *.c and assembler *.s files in your amForth build
>>> you
>>> >>>> can
>>> >>>> > run
>>> >>>> > into random 32 bit alignment issues with the dictionary.  The
>>> >>>> Cortex-M4
>>> >>>> > and
>>> >>>> > RISCV on CH32V307 appears to be more forgiving than
>>> CH32X033/CH32X035
>>> >>>> > is.
>>> >>>> > Using  the -m32 switch for GCC/assembler chain doesn't help. The
>>> >>>> > strange
>>> >>>> > part is that the 32 bit mis-alignment doesn't always occur.  It
>>> only
>>> >>>> > happens for certain dictionary elements like
>>> >>>> > 000015be <XT_DOLITERAL>:
>>> >>>> >     15be: 15c2
>>> >>>> > 000015c2 <PFA_DOLITERAL>:
>>> >>>> >
>>> >>>> > Regards,
>>> >>>> > John S
>>> >>>> >
>>> >>>> > _______________________________________________
>>> >>>> > Amforth-devel mailing list for http://amforth.sf.net/
>>> >>>> > Amf...@li...
>>> >>>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Amforth-devel mailing list for http://amforth.sf.net/
>>> >>>> Amf...@li...
>>> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>> >>>>
>>> >>>
>>> >
>>> > _______________________________________________
>>> > Amforth-devel mailing list for http://amforth.sf.net/
>>> > Amf...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>
>>>
>>> _______________________________________________
>>> Amforth-devel mailing list for http://amforth.sf.net/
>>> Amf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>
>>

Re: [Amforth] 32 bit amForth alignment issues

[John S. <jsa...@gm...>]

Hi Tristan,
The change that made things work, in the risc-v\dict_prims.inc file:
line 43
#      lw x10, 0(x17) # @W, address of some executable code
        lh x10, 0(x17) # @W, address of some executable code

This works because on a CH32x033 the dictionary resides in flash below the
64K boundary
addressable by a halfword (16 bits), and only has 62K of flash. By doing
this you can also keep the dictionary more compact in flash.
For larger flash devices where the dictionary resides is going to be a
factor to consider, some RISCV processors may not have an issue in crossing
32 bit word boundaries but the one for CH32x033 does. The RISCV processors
that don't have this issue (CH32V307?) can use the lw (load word) version
of the instruction. The CH32V003 -> CH32V007 and CH32V203 should use the lh
(load halfword) version.

Hope this helps others who want to use amforth on smaller RISCV chips
John S

On Wed, Jan 7, 2026 at 9:35 AM John Sarabacha <jsa...@gm...> wrote:

> Hi Tristan,
> I had sent a couple of pictures (of this environment) that apparently is
> being held by the sourceforge administrator for review because of the size
> of the email.
> The mcu uses it's own internal clock (fixed at 48Mhz) without any issues,
> breakout boards are also being used, the chips are soldered to the break
> out boards using solder paste and a T-962 oven (available from amazon). The
> breakout boards with the chip (mcu) become nodes on a network (similar to a
> RS485 type of network). It now becomes possible to go even smaller
> (CH32V003 ... CH32V007) but the cost these chips vs CH32X033 doesn't give
> you a better advantage (e.g size of sram and features). Where amForth is
> useful here is programming these chips remotely and changing these programs
> as needed. AmForth was the missing piece of the puzzle, the CH32X033 is a
> node on a network already functional and communicating with PIC16F1824
> nodes and running for years without significant problems but not easily
> re-programmable remotely. Things have changed significantly, compare the
> cost of a CH32X033 (32 bit) chip vs PIC16F1824 (8 bit) not to mention sram
> and flash size differences.
>
> Regards,
> John S
>
> Regards,
> John S.
>
>
>
>
> On Wed, Jan 7, 2026 at 2:30 AM <ho...@tj...> wrote:
>
>> Hi John,
>>
>> A very interesting and ambitious use of AmForth! Sounds like you
>> overcame your compiler/linker alignment issue.
>>
>> > The CH32X033 chip also hosts an additional eight bit RISC processor
>> > (pioc)
>>
>> I didn't know about this. Interesting.
>>
>> > The test environment is very simple, a CH32V033 chip in a
>> > 20 pin chip adapter connected to a WCH-LinkE and using
>> > MounStudio v2.3.0 for programming and debugging.
>>
>> How are you clocking the mcu?
>>
>> Best wishes,
>> Tristan
>>
>>
>> On 2026-01-07 05:41, John Sarabacha wrote:
>> > The CH32V033 is now able to execute the amForth XT words without any
>> > problems, MounStudio with debugging allowed me to set program break
>> > points
>> > to see the execution of each XT code segment along with the registers
>> > (tos,
>> > ip, sp dp) so it looks very promising. The vendor's startup code and C
>> > libraries are used to initialize system clocks, peripherals (usart,
>> > GPIO...) this saves a tremendous amount of work.
>> > The existing flash image contains the dictionary that the hifive
>> > application used which is an overkill for what my application needs, so
>> > the
>> > next step is to remove unnecessary dictionary entries e.g
>> > initialization
>> > (commenting out the unnecessary include files) and rebuild the image.
>> > The amForth codebase in CH32V033 will use the C library drivers for IO
>> > (usart, gpio, pioc, networking ... ).  The CH32X033 chip also hosts an
>> > additional eight bit RISC processor (pioc) which amForth can work with
>> > for
>> > high speed custom IO. To test the amForth code and dictionary a test
>> > sequence of XT tokens will be passed to the amForth VM (execution loop)
>> > and
>> > monitor the results (tos ... ). The test environment is very simple, a
>> > CH32V033 chip in a 20 pin chip adapter connected to a WCH-LinkE and
>> > using
>> > MounStudio v2.3.0 for programming and debugging.
>> >
>> > Hope this information is useful to others,
>> > John S
>> >
>> >
>> > On Tue, Jan 6, 2026 at 4:37 PM John Sarabacha <jsa...@gm...>
>> > wrote:
>> >
>> >> Hi Tristan,
>> >> Some good news,  CH32V033 is now able to run amForth co-existing with
>> >> C
>> >> and other inline routines. A change was made to the the execution loop
>> >> which doesn't impact performance and the keeps image size to a
>> >> minimum.
>> >> Next step is to test amForth using C code to pass ascii strings to the
>> >> interpreter to see if it works.
>> >>
>> >> Regards,
>> >> John S
>> >>
>> >>
>> >>
>> >> On Tue, Jan 6, 2026 at 3:14 PM John Sarabacha <jsa...@gm...>
>> >> wrote:
>> >>
>> >>> Hi Tristan,
>> >>> This has and is being looked at. The linker appears to be the
>> >>> problem. I
>> >>> have tried a few
>> >>> things like changes to the macros with some success. With these
>> >>> successes
>> >>> the image sizes grow.
>> >>> The run time execution loop is able to function until it hits a
>> >>> halfword
>> >>> address then it exceptions out.
>> >>> As a temporary workaround I am looking at handling the exception
>> >>> gracefully and resuming the execution
>> >>> loop,  this way the image size can be kept smaller. The good news is
>> >>> that
>> >>> it (amForth) is able to co-exist with
>> >>> my existing application which is a mix of C and inline assembler
>> >>> routines.
>> >>>
>> >>> Regards,
>> >>> John S
>> >>>
>> >>> On Tue, Jan 6, 2026 at 1:53 PM <ho...@tj...> wrote:
>> >>>
>> >>>> Hi John,
>> >>>>
>> >>>> Check your compiler/assembler/linker options to see whether they
>> >>>> allow
>> >>>> free reign to use RISC-V compressed instructions wherever they think
>> >>>> appropriate. Then, as a first cut, turn that off globally. There are
>> >>>> various ways to be more selective, but it very much depends on how
>> >>>> much
>> >>>> their use matters to you.
>> >>>>
>> >>>> Best wishes,
>> >>>> Tristan
>> >>>>
>> >>>> On 2026-01-06 16:33, John Sarabacha wrote:
>> >>>> > Hi everyone,
>> >>>> > When mixing C *.c and assembler *.s files in your amForth build you
>> >>>> can
>> >>>> > run
>> >>>> > into random 32 bit alignment issues with the dictionary.  The
>> >>>> Cortex-M4
>> >>>> > and
>> >>>> > RISCV on CH32V307 appears to be more forgiving than
>> CH32X033/CH32X035
>> >>>> > is.
>> >>>> > Using  the -m32 switch for GCC/assembler chain doesn't help. The
>> >>>> > strange
>> >>>> > part is that the 32 bit mis-alignment doesn't always occur.  It
>> only
>> >>>> > happens for certain dictionary elements like
>> >>>> > 000015be <XT_DOLITERAL>:
>> >>>> >     15be: 15c2
>> >>>> > 000015c2 <PFA_DOLITERAL>:
>> >>>> >
>> >>>> > Regards,
>> >>>> > John S
>> >>>> >
>> >>>> > _______________________________________________
>> >>>> > Amforth-devel mailing list for http://amforth.sf.net/
>> >>>> > Amf...@li...
>> >>>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Amforth-devel mailing list for http://amforth.sf.net/
>> >>>> Amf...@li...
>> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> >>>>
>> >>>
>> >
>> > _______________________________________________
>> > Amforth-devel mailing list for http://amforth.sf.net/
>> > Amf...@li...
>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>>
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>

Re: [Amforth] 32 bit amForth alignment issues

[John S. <jsa...@gm...>]

Hi Tristan,
I had sent a couple of pictures (of this environment) that apparently is
being held by the sourceforge administrator for review because of the size
of the email.
The mcu uses it's own internal clock (fixed at 48Mhz) without any issues,
breakout boards are also being used, the chips are soldered to the break
out boards using solder paste and a T-962 oven (available from amazon). The
breakout boards with the chip (mcu) become nodes on a network (similar to a
RS485 type of network). It now becomes possible to go even smaller
(CH32V003 ... CH32V007) but the cost these chips vs CH32X033 doesn't give
you a better advantage (e.g size of sram and features). Where amForth is
useful here is programming these chips remotely and changing these programs
as needed. AmForth was the missing piece of the puzzle, the CH32X033 is a
node on a network already functional and communicating with PIC16F1824
nodes and running for years without significant problems but not easily
re-programmable remotely. Things have changed significantly, compare the
cost of a CH32X033 (32 bit) chip vs PIC16F1824 (8 bit) not to mention sram
and flash size differences.

Regards,
John S

Regards,
John S.




On Wed, Jan 7, 2026 at 2:30 AM <ho...@tj...> wrote:

> Hi John,
>
> A very interesting and ambitious use of AmForth! Sounds like you
> overcame your compiler/linker alignment issue.
>
> > The CH32X033 chip also hosts an additional eight bit RISC processor
> > (pioc)
>
> I didn't know about this. Interesting.
>
> > The test environment is very simple, a CH32V033 chip in a
> > 20 pin chip adapter connected to a WCH-LinkE and using
> > MounStudio v2.3.0 for programming and debugging.
>
> How are you clocking the mcu?
>
> Best wishes,
> Tristan
>
>
> On 2026-01-07 05:41, John Sarabacha wrote:
> > The CH32V033 is now able to execute the amForth XT words without any
> > problems, MounStudio with debugging allowed me to set program break
> > points
> > to see the execution of each XT code segment along with the registers
> > (tos,
> > ip, sp dp) so it looks very promising. The vendor's startup code and C
> > libraries are used to initialize system clocks, peripherals (usart,
> > GPIO...) this saves a tremendous amount of work.
> > The existing flash image contains the dictionary that the hifive
> > application used which is an overkill for what my application needs, so
> > the
> > next step is to remove unnecessary dictionary entries e.g
> > initialization
> > (commenting out the unnecessary include files) and rebuild the image.
> > The amForth codebase in CH32V033 will use the C library drivers for IO
> > (usart, gpio, pioc, networking ... ).  The CH32X033 chip also hosts an
> > additional eight bit RISC processor (pioc) which amForth can work with
> > for
> > high speed custom IO. To test the amForth code and dictionary a test
> > sequence of XT tokens will be passed to the amForth VM (execution loop)
> > and
> > monitor the results (tos ... ). The test environment is very simple, a
> > CH32V033 chip in a 20 pin chip adapter connected to a WCH-LinkE and
> > using
> > MounStudio v2.3.0 for programming and debugging.
> >
> > Hope this information is useful to others,
> > John S
> >
> >
> > On Tue, Jan 6, 2026 at 4:37 PM John Sarabacha <jsa...@gm...>
> > wrote:
> >
> >> Hi Tristan,
> >> Some good news,  CH32V033 is now able to run amForth co-existing with
> >> C
> >> and other inline routines. A change was made to the the execution loop
> >> which doesn't impact performance and the keeps image size to a
> >> minimum.
> >> Next step is to test amForth using C code to pass ascii strings to the
> >> interpreter to see if it works.
> >>
> >> Regards,
> >> John S
> >>
> >>
> >>
> >> On Tue, Jan 6, 2026 at 3:14 PM John Sarabacha <jsa...@gm...>
> >> wrote:
> >>
> >>> Hi Tristan,
> >>> This has and is being looked at. The linker appears to be the
> >>> problem. I
> >>> have tried a few
> >>> things like changes to the macros with some success. With these
> >>> successes
> >>> the image sizes grow.
> >>> The run time execution loop is able to function until it hits a
> >>> halfword
> >>> address then it exceptions out.
> >>> As a temporary workaround I am looking at handling the exception
> >>> gracefully and resuming the execution
> >>> loop,  this way the image size can be kept smaller. The good news is
> >>> that
> >>> it (amForth) is able to co-exist with
> >>> my existing application which is a mix of C and inline assembler
> >>> routines.
> >>>
> >>> Regards,
> >>> John S
> >>>
> >>> On Tue, Jan 6, 2026 at 1:53 PM <ho...@tj...> wrote:
> >>>
> >>>> Hi John,
> >>>>
> >>>> Check your compiler/assembler/linker options to see whether they
> >>>> allow
> >>>> free reign to use RISC-V compressed instructions wherever they think
> >>>> appropriate. Then, as a first cut, turn that off globally. There are
> >>>> various ways to be more selective, but it very much depends on how
> >>>> much
> >>>> their use matters to you.
> >>>>
> >>>> Best wishes,
> >>>> Tristan
> >>>>
> >>>> On 2026-01-06 16:33, John Sarabacha wrote:
> >>>> > Hi everyone,
> >>>> > When mixing C *.c and assembler *.s files in your amForth build you
> >>>> can
> >>>> > run
> >>>> > into random 32 bit alignment issues with the dictionary.  The
> >>>> Cortex-M4
> >>>> > and
> >>>> > RISCV on CH32V307 appears to be more forgiving than
> CH32X033/CH32X035
> >>>> > is.
> >>>> > Using  the -m32 switch for GCC/assembler chain doesn't help. The
> >>>> > strange
> >>>> > part is that the 32 bit mis-alignment doesn't always occur.  It only
> >>>> > happens for certain dictionary elements like
> >>>> > 000015be <XT_DOLITERAL>:
> >>>> >     15be: 15c2
> >>>> > 000015c2 <PFA_DOLITERAL>:
> >>>> >
> >>>> > Regards,
> >>>> > John S
> >>>> >
> >>>> > _______________________________________________
> >>>> > Amforth-devel mailing list for http://amforth.sf.net/
> >>>> > Amf...@li...
> >>>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Amforth-devel mailing list for http://amforth.sf.net/
> >>>> Amf...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>>>
> >>>
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] 32 bit amForth alignment issues

[<ho...@tj...>]

Hi John,

A very interesting and ambitious use of AmForth! Sounds like you 
overcame your compiler/linker alignment issue.

> The CH32X033 chip also hosts an additional eight bit RISC processor 
> (pioc)

I didn't know about this. Interesting.

> The test environment is very simple, a CH32V033 chip in a
> 20 pin chip adapter connected to a WCH-LinkE and using
> MounStudio v2.3.0 for programming and debugging.

How are you clocking the mcu?

Best wishes,
Tristan


On 2026-01-07 05:41, John Sarabacha wrote:
> The CH32V033 is now able to execute the amForth XT words without any
> problems, MounStudio with debugging allowed me to set program break 
> points
> to see the execution of each XT code segment along with the registers 
> (tos,
> ip, sp dp) so it looks very promising. The vendor's startup code and C
> libraries are used to initialize system clocks, peripherals (usart,
> GPIO...) this saves a tremendous amount of work.
> The existing flash image contains the dictionary that the hifive
> application used which is an overkill for what my application needs, so 
> the
> next step is to remove unnecessary dictionary entries e.g 
> initialization
> (commenting out the unnecessary include files) and rebuild the image.
> The amForth codebase in CH32V033 will use the C library drivers for IO
> (usart, gpio, pioc, networking ... ).  The CH32X033 chip also hosts an
> additional eight bit RISC processor (pioc) which amForth can work with 
> for
> high speed custom IO. To test the amForth code and dictionary a test
> sequence of XT tokens will be passed to the amForth VM (execution loop) 
> and
> monitor the results (tos ... ). The test environment is very simple, a
> CH32V033 chip in a 20 pin chip adapter connected to a WCH-LinkE and 
> using
> MounStudio v2.3.0 for programming and debugging.
> 
> Hope this information is useful to others,
> John S
> 
> 
> On Tue, Jan 6, 2026 at 4:37 PM John Sarabacha <jsa...@gm...> 
> wrote:
> 
>> Hi Tristan,
>> Some good news,  CH32V033 is now able to run amForth co-existing with 
>> C
>> and other inline routines. A change was made to the the execution loop
>> which doesn't impact performance and the keeps image size to a 
>> minimum.
>> Next step is to test amForth using C code to pass ascii strings to the
>> interpreter to see if it works.
>> 
>> Regards,
>> John S
>> 
>> 
>> 
>> On Tue, Jan 6, 2026 at 3:14 PM John Sarabacha <jsa...@gm...>
>> wrote:
>> 
>>> Hi Tristan,
>>> This has and is being looked at. The linker appears to be the 
>>> problem. I
>>> have tried a few
>>> things like changes to the macros with some success. With these 
>>> successes
>>> the image sizes grow.
>>> The run time execution loop is able to function until it hits a 
>>> halfword
>>> address then it exceptions out.
>>> As a temporary workaround I am looking at handling the exception
>>> gracefully and resuming the execution
>>> loop,  this way the image size can be kept smaller. The good news is 
>>> that
>>> it (amForth) is able to co-exist with
>>> my existing application which is a mix of C and inline assembler 
>>> routines.
>>> 
>>> Regards,
>>> John S
>>> 
>>> On Tue, Jan 6, 2026 at 1:53 PM <ho...@tj...> wrote:
>>> 
>>>> Hi John,
>>>> 
>>>> Check your compiler/assembler/linker options to see whether they 
>>>> allow
>>>> free reign to use RISC-V compressed instructions wherever they think
>>>> appropriate. Then, as a first cut, turn that off globally. There are
>>>> various ways to be more selective, but it very much depends on how 
>>>> much
>>>> their use matters to you.
>>>> 
>>>> Best wishes,
>>>> Tristan
>>>> 
>>>> On 2026-01-06 16:33, John Sarabacha wrote:
>>>> > Hi everyone,
>>>> > When mixing C *.c and assembler *.s files in your amForth build you
>>>> can
>>>> > run
>>>> > into random 32 bit alignment issues with the dictionary.  The
>>>> Cortex-M4
>>>> > and
>>>> > RISCV on CH32V307 appears to be more forgiving than CH32X033/CH32X035
>>>> > is.
>>>> > Using  the -m32 switch for GCC/assembler chain doesn't help. The
>>>> > strange
>>>> > part is that the 32 bit mis-alignment doesn't always occur.  It only
>>>> > happens for certain dictionary elements like
>>>> > 000015be <XT_DOLITERAL>:
>>>> >     15be: 15c2
>>>> > 000015c2 <PFA_DOLITERAL>:
>>>> >
>>>> > Regards,
>>>> > John S
>>>> >
>>>> > _______________________________________________
>>>> > Amforth-devel mailing list for http://amforth.sf.net/
>>>> > Amf...@li...
>>>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Amforth-devel mailing list for http://amforth.sf.net/
>>>> Amf...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>> 
>>> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] 32 bit amForth alignment issues

[John S. <jsa...@gm...>]

The CH32V033 is now able to execute the amForth XT words without any
problems, MounStudio with debugging allowed me to set program break points
to see the execution of each XT code segment along with the registers (tos,
ip, sp dp) so it looks very promising. The vendor's startup code and C
libraries are used to initialize system clocks, peripherals (usart,
GPIO...) this saves a tremendous amount of work.
The existing flash image contains the dictionary that the hifive
application used which is an overkill for what my application needs, so the
next step is to remove unnecessary dictionary entries e.g initialization
(commenting out the unnecessary include files) and rebuild the image.
The amForth codebase in CH32V033 will use the C library drivers for IO
(usart, gpio, pioc, networking ... ).  The CH32X033 chip also hosts an
additional eight bit RISC processor (pioc) which amForth can work with for
high speed custom IO. To test the amForth code and dictionary a test
sequence of XT tokens will be passed to the amForth VM (execution loop) and
monitor the results (tos ... ). The test environment is very simple, a
CH32V033 chip in a 20 pin chip adapter connected to a WCH-LinkE and using
MounStudio v2.3.0 for programming and debugging.

Hope this information is useful to others,
John S


On Tue, Jan 6, 2026 at 4:37 PM John Sarabacha <jsa...@gm...> wrote:

> Hi Tristan,
> Some good news,  CH32V033 is now able to run amForth co-existing with C
> and other inline routines. A change was made to the the execution loop
> which doesn't impact performance and the keeps image size to a minimum.
> Next step is to test amForth using C code to pass ascii strings to the
> interpreter to see if it works.
>
> Regards,
> John S
>
>
>
> On Tue, Jan 6, 2026 at 3:14 PM John Sarabacha <jsa...@gm...>
> wrote:
>
>> Hi Tristan,
>> This has and is being looked at. The linker appears to be the problem. I
>> have tried a few
>> things like changes to the macros with some success. With these successes
>> the image sizes grow.
>> The run time execution loop is able to function until it hits a halfword
>> address then it exceptions out.
>> As a temporary workaround I am looking at handling the exception
>> gracefully and resuming the execution
>> loop,  this way the image size can be kept smaller. The good news is that
>> it (amForth) is able to co-exist with
>> my existing application which is a mix of C and inline assembler routines.
>>
>> Regards,
>> John S
>>
>> On Tue, Jan 6, 2026 at 1:53 PM <ho...@tj...> wrote:
>>
>>> Hi John,
>>>
>>> Check your compiler/assembler/linker options to see whether they allow
>>> free reign to use RISC-V compressed instructions wherever they think
>>> appropriate. Then, as a first cut, turn that off globally. There are
>>> various ways to be more selective, but it very much depends on how much
>>> their use matters to you.
>>>
>>> Best wishes,
>>> Tristan
>>>
>>> On 2026-01-06 16:33, John Sarabacha wrote:
>>> > Hi everyone,
>>> > When mixing C *.c and assembler *.s files in your amForth build you
>>> can
>>> > run
>>> > into random 32 bit alignment issues with the dictionary.  The
>>> Cortex-M4
>>> > and
>>> > RISCV on CH32V307 appears to be more forgiving than CH32X033/CH32X035
>>> > is.
>>> > Using  the -m32 switch for GCC/assembler chain doesn't help. The
>>> > strange
>>> > part is that the 32 bit mis-alignment doesn't always occur.  It only
>>> > happens for certain dictionary elements like
>>> > 000015be <XT_DOLITERAL>:
>>> >     15be: 15c2
>>> > 000015c2 <PFA_DOLITERAL>:
>>> >
>>> > Regards,
>>> > John S
>>> >
>>> > _______________________________________________
>>> > Amforth-devel mailing list for http://amforth.sf.net/
>>> > Amf...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>
>>>
>>> _______________________________________________
>>> Amforth-devel mailing list for http://amforth.sf.net/
>>> Amf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>
>>

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[John S. <jsa...@gm...>]

Hi,
My suggestion is to keep in sram as much as possible, there are more
advantages in doing this. Flash write cycles are limited approx 100K times,
sram does not have this limitation. Also Cortex-m4 and RISCV processors
have flash wait state considerations (even with caching) and sram doesn't,
this impacts performance.

John S

On Tue, Jan 6, 2026 at 2:01 PM Martin Kobetic <mko...@gm...> wrote:

> Hi Tristan,
>
> So to get back to the variable problem and how to deal with it. Is it
> possible to summarize the problem as: "DP and HERE must be in separate
> memory regions." ? If so there are many ways to satisfy this constraint. We
> could assign separate SRAM regions for these purposes. It's also not clear
> to me why we can't put DP back into the flash memory. I don't know about
> the RISC-V side but RA4M1 supports "self-programming" (chapter 44.13), so
> it seems it would be just a "small matter of programming" to get it
> working. Are there any other options you are considering?
>
> Cheers,
>
> Martin
>
> On Mon, Jan 5, 2026 at 5:40 PM <ho...@tj...> 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 <jsa...@gm...>
> > > 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 <ho...@tj...> 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 <
> jsa...@gm...
> > >
> > >>> > 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 <
> > jsa...@gm...>
> > >>> >> 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 <
> mko...@gm...
> > >
> > >>> >>> wrote:
> > >>> >>>
> > >>> >>>> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha
> > >>> >>>> <jsa...@gm...>
> > >>> >>>> 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/
> > >>> >>>> Amf...@li...
> > >>> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > >>> >>>>
> > >>> >>>
> > >>> >
> > >>> > _______________________________________________
> > >>> > Amforth-devel mailing list for http://amforth.sf.net/
> > >>> > Amf...@li...
> > >>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > >>>
> > >>>
> > >>> _______________________________________________
> > >>> Amforth-devel mailing list for http://amforth.sf.net/
> > >>> Amf...@li...
> > >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> > >>>
> > >>
> > >
> > > _______________________________________________
> > > Amforth-devel mailing list for http://amforth.sf.net/
> > > Amf...@li...
> > > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] 32 bit amForth alignment issues

[John S. <jsa...@gm...>]

Hi Tristan,
Some good news,  CH32V033 is now able to run amForth co-existing with C and
other inline routines. A change was made to the the execution loop which
doesn't impact performance and the keeps image size to a minimum. Next step
is to test amForth using C code to pass ascii strings to the interpreter to
see if it works.

Regards,
John S



On Tue, Jan 6, 2026 at 3:14 PM John Sarabacha <jsa...@gm...> wrote:

> Hi Tristan,
> This has and is being looked at. The linker appears to be the problem. I
> have tried a few
> things like changes to the macros with some success. With these successes
> the image sizes grow.
> The run time execution loop is able to function until it hits a halfword
> address then it exceptions out.
> As a temporary workaround I am looking at handling the exception
> gracefully and resuming the execution
> loop,  this way the image size can be kept smaller. The good news is that
> it (amForth) is able to co-exist with
> my existing application which is a mix of C and inline assembler routines.
>
> Regards,
> John S
>
> On Tue, Jan 6, 2026 at 1:53 PM <ho...@tj...> wrote:
>
>> Hi John,
>>
>> Check your compiler/assembler/linker options to see whether they allow
>> free reign to use RISC-V compressed instructions wherever they think
>> appropriate. Then, as a first cut, turn that off globally. There are
>> various ways to be more selective, but it very much depends on how much
>> their use matters to you.
>>
>> Best wishes,
>> Tristan
>>
>> On 2026-01-06 16:33, John Sarabacha wrote:
>> > Hi everyone,
>> > When mixing C *.c and assembler *.s files in your amForth build you can
>> > run
>> > into random 32 bit alignment issues with the dictionary.  The Cortex-M4
>> > and
>> > RISCV on CH32V307 appears to be more forgiving than CH32X033/CH32X035
>> > is.
>> > Using  the -m32 switch for GCC/assembler chain doesn't help. The
>> > strange
>> > part is that the 32 bit mis-alignment doesn't always occur.  It only
>> > happens for certain dictionary elements like
>> > 000015be <XT_DOLITERAL>:
>> >     15be: 15c2
>> > 000015c2 <PFA_DOLITERAL>:
>> >
>> > Regards,
>> > John S
>> >
>> > _______________________________________________
>> > Amforth-devel mailing list for http://amforth.sf.net/
>> > Amf...@li...
>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>>
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>

Re: [Amforth] 32 bit amForth alignment issues

[John S. <jsa...@gm...>]

Hi Tristan,
This has and is being looked at. The linker appears to be the problem. I
have tried a few
things like changes to the macros with some success. With these successes
the image sizes grow.
The run time execution loop is able to function until it hits a halfword
address then it exceptions out.
As a temporary workaround I am looking at handling the exception gracefully
and resuming the execution
loop,  this way the image size can be kept smaller. The good news is that
it (amForth) is able to co-exist with
my existing application which is a mix of C and inline assembler routines.

Regards,
John S

On Tue, Jan 6, 2026 at 1:53 PM <ho...@tj...> wrote:

> Hi John,
>
> Check your compiler/assembler/linker options to see whether they allow
> free reign to use RISC-V compressed instructions wherever they think
> appropriate. Then, as a first cut, turn that off globally. There are
> various ways to be more selective, but it very much depends on how much
> their use matters to you.
>
> Best wishes,
> Tristan
>
> On 2026-01-06 16:33, John Sarabacha wrote:
> > Hi everyone,
> > When mixing C *.c and assembler *.s files in your amForth build you can
> > run
> > into random 32 bit alignment issues with the dictionary.  The Cortex-M4
> > and
> > RISCV on CH32V307 appears to be more forgiving than CH32X033/CH32X035
> > is.
> > Using  the -m32 switch for GCC/assembler chain doesn't help. The
> > strange
> > part is that the 32 bit mis-alignment doesn't always occur.  It only
> > happens for certain dictionary elements like
> > 000015be <XT_DOLITERAL>:
> >     15be: 15c2
> > 000015c2 <PFA_DOLITERAL>:
> >
> > Regards,
> > John S
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[Martin K. <mko...@gm...>]

Hi Tristan,

So to get back to the variable problem and how to deal with it. Is it
possible to summarize the problem as: "DP and HERE must be in separate
memory regions." ? If so there are many ways to satisfy this constraint. We
could assign separate SRAM regions for these purposes. It's also not clear
to me why we can't put DP back into the flash memory. I don't know about
the RISC-V side but RA4M1 supports "self-programming" (chapter 44.13), so
it seems it would be just a "small matter of programming" to get it
working. Are there any other options you are considering?

Cheers,

Martin

On Mon, Jan 5, 2026 at 5:40 PM <ho...@tj...> 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 <jsa...@gm...>
> > 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 <ho...@tj...> 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 <jsa...@gm...
> >
> >>> > 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 <
> jsa...@gm...>
> >>> >> 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 <mko...@gm...
> >
> >>> >>> wrote:
> >>> >>>
> >>> >>>> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha
> >>> >>>> <jsa...@gm...>
> >>> >>>> 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/
> >>> >>>> Amf...@li...
> >>> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>> >>>>
> >>> >>>
> >>> >
> >>> > _______________________________________________
> >>> > Amforth-devel mailing list for http://amforth.sf.net/
> >>> > Amf...@li...
> >>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>>
> >>>
> >>> _______________________________________________
> >>> Amforth-devel mailing list for http://amforth.sf.net/
> >>> Amf...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>>
> >>
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] 32 bit amForth alignment issues

[<ho...@tj...>]

Hi John,

Check your compiler/assembler/linker options to see whether they allow 
free reign to use RISC-V compressed instructions wherever they think 
appropriate. Then, as a first cut, turn that off globally. There are 
various ways to be more selective, but it very much depends on how much 
their use matters to you.

Best wishes,
Tristan

On 2026-01-06 16:33, John Sarabacha wrote:
> Hi everyone,
> When mixing C *.c and assembler *.s files in your amForth build you can 
> run
> into random 32 bit alignment issues with the dictionary.  The Cortex-M4 
> and
> RISCV on CH32V307 appears to be more forgiving than CH32X033/CH32X035 
> is.
> Using  the -m32 switch for GCC/assembler chain doesn't help. The 
> strange
> part is that the 32 bit mis-alignment doesn't always occur.  It only
> happens for certain dictionary elements like
> 000015be <XT_DOLITERAL>:
>     15be: 15c2
> 000015c2 <PFA_DOLITERAL>:
> 
> Regards,
> John S
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[Martin K. <mko...@gm...>]

Thank you, Tristan! You are absolutely right! I can run a terminal session
and gdb at the same time. I made wrong assumptions when my flash uploads
failed when I had the terminal session up. I concluded that only one thing
can use the USB device at a time. But indeed terminal and debug sessions
seem to be fine sharing the same physical USB connection. I'm using MacOS
and only one serial device shows up for me when I plug the board in. I
don't know enough about USB to check and see the virtual ports, but it
seems to be working just as you described. You've saved me a lot of time
and frustration. Thank you again!

Cheers,
Martin

On Tue, Jan 6, 2026 at 7:04 AM <ho...@tj...> wrote:

> Hello Martin,
>
> UNO R4 openOCD plus simultaneous serial connection?
>
> I don't have the hardware to check but would expect [1] two virtual COM
> ports to be provided over the one physical USB-C connection; a debug
> port you can use with openOCD etc. and a serial port you can use
> simultaneously with minicom etc. or amforth-shell.py
>
> Best wishes,
> Tristan
>
> [1] from previous comments I'm guessing you have the UNO R4 Wifi and not
> the UNO R4 minima
>
>
> On 2026-01-06 02:58, Martin Kobetic wrote:
> > 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.
> >
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

[Amforth] 32 bit amForth alignment issues

[John S. <jsa...@gm...>]

Hi everyone,
When mixing C *.c and assembler *.s files in your amForth build you can run
into random 32 bit alignment issues with the dictionary.  The Cortex-M4 and
RISCV on CH32V307 appears to be more forgiving than CH32X033/CH32X035 is.
Using  the -m32 switch for GCC/assembler chain doesn't help. The strange
part is that the 32 bit mis-alignment doesn't always occur.  It only
happens for certain dictionary elements like
000015be <XT_DOLITERAL>:
    15be: 15c2
000015c2 <PFA_DOLITERAL>:

Regards,
John S

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[John S. <jsa...@gm...>]

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 <jsa...@gm...> wrote:

> Hi Tristan,
> Thank you this is making more sense.
>
> John S
>
> On Mon, Jan 5, 2026 at 5:40 PM <ho...@tj...> 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 <jsa...@gm...>
>> > 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 <ho...@tj...> 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 <
>> jsa...@gm...>
>> >>> > 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 <
>> jsa...@gm...>
>> >>> >> 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 <
>> mko...@gm...>
>> >>> >>> wrote:
>> >>> >>>
>> >>> >>>> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha
>> >>> >>>> <jsa...@gm...>
>> >>> >>>> 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/
>> >>> >>>> Amf...@li...
>> >>> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> >>> >>>>
>> >>> >>>
>> >>> >
>> >>> > _______________________________________________
>> >>> > Amforth-devel mailing list for http://amforth.sf.net/
>> >>> > Amf...@li...
>> >>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Amforth-devel mailing list for http://amforth.sf.net/
>> >>> Amf...@li...
>> >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> >>>
>> >>
>> >
>> > _______________________________________________
>> > Amforth-devel mailing list for http://amforth.sf.net/
>> > Amf...@li...
>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>>
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[<ho...@tj...>]

Hello Martin,

UNO R4 openOCD plus simultaneous serial connection?

I don't have the hardware to check but would expect [1] two virtual COM 
ports to be provided over the one physical USB-C connection; a debug 
port you can use with openOCD etc. and a serial port you can use 
simultaneously with minicom etc. or amforth-shell.py

Best wishes,
Tristan

[1] from previous comments I'm guessing you have the UNO R4 Wifi and not 
the UNO R4 minima


On 2026-01-06 02:58, Martin Kobetic wrote:
> 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.
> 

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[Martin K. <mko...@gm...>]

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 <ho...@tj...> 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 <jsa...@gm...>
> > 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 <ho...@tj...> 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 <jsa...@gm...
> >
> >>> > 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 <
> jsa...@gm...>
> >>> >> 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 <mko...@gm...
> >
> >>> >>> wrote:
> >>> >>>
> >>> >>>> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha
> >>> >>>> <jsa...@gm...>
> >>> >>>> 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/
> >>> >>>> Amf...@li...
> >>> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>> >>>>
> >>> >>>
> >>> >
> >>> > _______________________________________________
> >>> > Amforth-devel mailing list for http://amforth.sf.net/
> >>> > Amf...@li...
> >>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>>
> >>>
> >>> _______________________________________________
> >>> Amforth-devel mailing list for http://amforth.sf.net/
> >>> Amf...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>>
> >>
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[John S. <jsa...@gm...>]

Hi Tristan,
Thank you this is making more sense.

John S

On Mon, Jan 5, 2026 at 5:40 PM <ho...@tj...> 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 <jsa...@gm...>
> > 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 <ho...@tj...> 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 <jsa...@gm...
> >
> >>> > 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 <
> jsa...@gm...>
> >>> >> 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 <mko...@gm...
> >
> >>> >>> wrote:
> >>> >>>
> >>> >>>> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha
> >>> >>>> <jsa...@gm...>
> >>> >>>> 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/
> >>> >>>> Amf...@li...
> >>> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>> >>>>
> >>> >>>
> >>> >
> >>> > _______________________________________________
> >>> > Amforth-devel mailing list for http://amforth.sf.net/
> >>> > Amf...@li...
> >>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>>
> >>>
> >>> _______________________________________________
> >>> Amforth-devel mailing list for http://amforth.sf.net/
> >>> Amf...@li...
> >>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>>
> >>
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[<ho...@tj...>]

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 <jsa...@gm...> 
> 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 <ho...@tj...> 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 <jsa...@gm...>
>>> > 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 <jsa...@gm...>
>>> >> 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 <mko...@gm...>
>>> >>> wrote:
>>> >>>
>>> >>>> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha
>>> >>>> <jsa...@gm...>
>>> >>>> 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/
>>> >>>> Amf...@li...
>>> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>> >>>>
>>> >>>
>>> >
>>> > _______________________________________________
>>> > Amforth-devel mailing list for http://amforth.sf.net/
>>> > Amf...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>> 
>>> 
>>> _______________________________________________
>>> Amforth-devel mailing list for http://amforth.sf.net/
>>> Amf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>> 
>> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[John S. <jsa...@gm...>]

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 <jsa...@gm...> 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 <jsa...@gm...>
> 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 <ho...@tj...> 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 <jsa...@gm...>
>>> > 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 <jsa...@gm...>
>>> >> 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 <mko...@gm...>
>>> >>> wrote:
>>> >>>
>>> >>>> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha
>>> >>>> <jsa...@gm...>
>>> >>>> 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/
>>> >>>> Amf...@li...
>>> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>> >>>>
>>> >>>
>>> >
>>> > _______________________________________________
>>> > Amforth-devel mailing list for http://amforth.sf.net/
>>> > Amf...@li...
>>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>
>>>
>>> _______________________________________________
>>> Amforth-devel mailing list for http://amforth.sf.net/
>>> Amf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>
>>

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[John S. <jsa...@gm...>]

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 <jsa...@gm...> 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 <ho...@tj...> 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 <jsa...@gm...>
>> > 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 <jsa...@gm...>
>> >> 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 <mko...@gm...>
>> >>> wrote:
>> >>>
>> >>>> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha
>> >>>> <jsa...@gm...>
>> >>>> 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/
>> >>>> Amf...@li...
>> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>> >>>>
>> >>>
>> >
>> > _______________________________________________
>> > Amforth-devel mailing list for http://amforth.sf.net/
>> > Amf...@li...
>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>>
>> _______________________________________________
>> Amforth-devel mailing list for http://amforth.sf.net/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[John S. <jsa...@gm...>]

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 <ho...@tj...> 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 <jsa...@gm...>
> > 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 <jsa...@gm...>
> >> 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 <mko...@gm...>
> >>> wrote:
> >>>
> >>>> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha
> >>>> <jsa...@gm...>
> >>>> 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/
> >>>> Amf...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
> >>>>
> >>>
> >
> > _______________________________________________
> > Amforth-devel mailing list for http://amforth.sf.net/
> > Amf...@li...
> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[<ho...@tj...>]

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 <jsa...@gm...> 
> 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 <jsa...@gm...>
>> 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 <mko...@gm...>
>>> wrote:
>>> 
>>>> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha 
>>>> <jsa...@gm...>
>>>> 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/
>>>> Amf...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>> 
>>> 
> 
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[John S. <jsa...@gm...>]

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 <jsa...@gm...> 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 <jsa...@gm...>
> 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 <mko...@gm...>
>> wrote:
>>
>>> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha <jsa...@gm...>
>>> 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/
>>> Amf...@li...
>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>
>>

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[John S. <jsa...@gm...>]

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 <jsa...@gm...> 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 <mko...@gm...> wrote:
>
>> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha <jsa...@gm...>
>> 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/
>> Amf...@li...
>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>
>

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[John S. <jsa...@gm...>]

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 <mko...@gm...> wrote:

> On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha <jsa...@gm...>
> 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/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] Uno R4 (RA4M1 - ARM) working

[Martin K. <mko...@gm...>]

On Mon, Jan 5, 2026 at 11:51 AM John Sarabacha <jsa...@gm...> 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.