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
