Hi John,
Well done! It's better than a fix, it is an enhancement!
Now, the AmForth RISC-V build is more tolerant of compressed
instructions and linker relaxation, but if you explicitly exclude
them,
you should see no change to your build.
Best wishes,
Tristan
On 2026-01-08 05:53, John Sarabacha wrote:
> Hi Tristan,
> A better fix for the alignment problem which leaves the riscv AmForth
> ITC
> VM untouched (full 32 bit reads on flash or sram dictionary).
> It appears that 2 macros which are used to build the flash dictionary
> were
> missing the alignment directive (yet the other macros had them). The
> missing alignment directives were added and the image was rebuilt and
> tested with no problems (no exceptions triggered).
> The macros are in the macros.s file starting at line 136. It was
> noticed in
> the assembly listing that the dictionary was correctly aligned until
> the
> dictionary had entries for anything created by the HEADLESS macro
> (DOLOOP
> ... DOVALUE ... DOLITERAL ...). The NONAME macro was changed also as a
> precaution.
>
> before the changes:
>
> .macro HEADLESS Label
> VE_\Label:
> XT_\Label: .word PFA_\Label
> PFA_\Label:
> .endm
>
> .macro NONAME Label
> VE_\Label:
> XT_\Label: .word DOCOLON
> PFA_\Label:
> .endm
>
> after the changes:
>
> .macro HEADLESS Label
> .p2align 2,0x55
> VE_\Label:
> XT_\Label: .word PFA_\Label
> PFA_\Label:
> .endm
>
> .macro NONAME Label
> .p2align 2,0x55
> VE_\Label:
> XT_\Label: .word DOCOLON
> PFA_\Label:
> .endm
>
> Regards,
> John S
>
> On Wed, Jan 7, 2026 at 5:05 PM John Sarabacha <[email protected]>
> wrote:
>
>> Hi Tristan,
>>
>> Also my amForth VM implementation will access sram the same way as my
>> current application does even though it sits in low address space
>> (<64K)
>> with the amForth dictionary structure, code and ITC. This amForth VM
>> forth
>> will also be able to access variables defined by the C application
>> code
>> just as the inline assembler does (remember amForth code is written in
>> assembly code), it could also create it's own variables. When the
>> image was
>> built only the default settings were used for the GCC riscv tool
>> chain, my
>> guess is that these default settings are based on vendor's chip. I
>> didn't
>> try to use the compact instructions for the code, the GCC/assembler
>> did
>> this based on the default settings. I did try to force 32 bit
>> alignment by
>> specifying -m32 and -O0 as build options but it didn't work and it
>> increased image size, so I reverted back to the default settings. Each
>> target environment will have it's own tweeks to make it work. My tweek
>> works for my implementation but it might not be suitable for other
>> targets
>> (e.g flash > 64K). But it could be useful information for other
>> amForth
>> implementers.
>>
>> Regards,
>> John S
>>
>> On Wed, Jan 7, 2026 at 2:52 PM John Sarabacha <[email protected]>
>> wrote:
>>
>>> The AmForth ITC VM will use the lw (load word 32 bits) instruction as
>>> needed (dynamically) e.g for sram which is at > 0X20000000 or any
>>> peripheral addressing which is even higher.
>>> the hw (load halfword 16 bits) is only for flash memory which is
>>> 0-64K
>>> addressing.
>>>
>>> Regards,
>>> John S
>>>
>>> On Wed, Jan 7, 2026 at 2:26 PM <[email protected]> wrote:
>>>
>>>> Hi John,
>>>>
>>>> So is my understanding below correct?
>>>>
>>>> You've combined the 32 bit aligned RV32IM AmForth dictionary with
>>>> your
>>>> existing c/assembler code and compiled/assembled/linked that with
>>>> optimisations/options that encourage code compactness, including
>>>> substitution with compressed instructions. This results in a
>>>> dictionary
>>>> that can only be guaranteed to be 16 bit aligned. To avoid a memory
>>>> alignment exception, you adjust the final read of the AmForth ITC VM
>>>> to
>>>> be a half word read. This functions as execution is limited to the
>>>> 16
>>>> bit address space of the available flash memory.
>>>>
>>>> Best wishes,
>>>> Tristan
>>>>
>>>>
>>>> On 2026-01-07 17:06, John Sarabacha wrote:
>>>> > 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 <
[email protected]>
>>>> > 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 <
[email protected]>
>>>> >> 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 <[email protected]> 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 <
>>>> [email protected]>
>>>> >>>> > 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 <
>>>> [email protected]>
>>>> >>>> >> 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 <[email protected]> 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/
>>>> >>>> >>>> > [email protected]
>>>> >>>> >>>> >
https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>> >>>> >>>>
>>>> >>>> >>>>
>>>> >>>> >>>> _______________________________________________
>>>> >>>> >>>> Amforth-devel mailing list for http://amforth.sf.net/
>>>> >>>> >>>> [email protected]
>>>> >>>> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>> >>>> >>>>
>>>> >>>> >>>
>>>> >>>> >
>>>> >>>> > _______________________________________________
>>>> >>>> > Amforth-devel mailing list for http://amforth.sf.net/
>>>> >>>> > [email protected]
>>>> >>>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>> >>>>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> Amforth-devel mailing list for http://amforth.sf.net/
>>>> >>>> [email protected]
>>>> >>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>> >>>>
>>>> >>>
>>>> >
>>>> > _______________________________________________
>>>> > Amforth-devel mailing list for http://amforth.sf.net/
>>>> > [email protected]
>>>> > https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>>
>>>>
>>>> _______________________________________________
>>>> Amforth-devel mailing list for http://amforth.sf.net/
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>>>>
>>>
>
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
_______________________________________________
Amforth-devel mailing list for http://amforth.sf.net/
[email protected]
https://lists.sourceforge.net/lists/listinfo/amforth-devel
