Further clarification is that the exception occurs when accessing a forth token structure (xt … ) in flash if isn’t 32bit aligned, the address to code within it doesn’t trigger an exception, the jalr instruction still works as expected.
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
