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
