Hi Tristan, Thank you, no problem. Trying to share my software experience (in my so-called retirement years). My working experience was with the other languages (not forth), still getting used to thinking in forth. God has given me the gift of being able to read and understand assembly code sometimes better than higher level languages and english documentation.
Some food for thought, when Charles Moore (the creator of forth) looked up into the sky and wrote his forth language to control those telescopes, was he thinking in the beginning the Word was ... (from the Bible ?) also CREATE ... Thanks again John S On Thu, Jan 8, 2026 at 4:27 AM <[email protected]> wrote: > 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 > _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ [email protected] https://lists.sourceforge.net/lists/listinfo/amforth-devel
