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
