Hi Martin, I will be trying to host amForth on an arm-m7 (600Mhz) platform which was being evaluated a few years ago. I will be using the same process as I used for CH32X033. Any learning I will pass on, M7 is significantly different than M4 so by sticking to thumb type instructions there should be some common issues.
Regards, John S On Sun, Jan 11, 2026 at 1:36 PM John Sarabacha <[email protected]> wrote: > Hi Martin, > What our builds have in common is shared/words, the foundation words being > in assembler risc-v/words or arm/words depending on target mcu. Then the > platform words in appl. > I have avoided the platform words (hfive1) even though they were built > into my initial image. Before I could run (pun here) I had to walk and > sometimes even crawl through the foundation words code execution. This > helped me to understand what was really going on under the hood with the > engine (ITC) and foundation word codes (maybe too many puns). Long story > made short, painful as it might seem understanding trumps (hate using this > word now) trial and error. My journey here is not yet complete but so far > there is more hope for a successful deployment. > Before looking at amForth I had looked at a lot of forth > implementations and documentation (even at the code level) on GitHub or > Sourceforge since 2016 and in my opinion amForth is one of the best even > though the 32 bit versions are not stable (still experimental). > > Glass is half full not half empty, > John S. > > On Sun, Jan 11, 2026 at 10:12 AM John Sarabacha <[email protected]> > wrote: > >> Hi Martin, >> I understand your approach which is a good approach, I have used (free) >> platforms and still do but they do have costs your time to make them work >> according to your needs. >> >> Best regards, >> John S >> >> On Sun, Jan 11, 2026 at 9:53 AM Martin Kobetic <[email protected]> >> wrote: >> >>> Hi John, I fully agree, testing a subset of AmForth in some sort of >>> emulation is absolutely not a substitute for tests on actual hardware. >>> What >>> got me excited is the possibility of running the emulated test subset on >>> some of the (free) CI platforms out there. I'm confident I could get >>> github >>> run the suite fully automatically on every commit I push. It could serve >>> as >>> an early warning system that my changes are breaking something I didn't >>> expect. Manual tests will of course always be part of the development >>> process. >>> >>> Best regards, >>> Martin >>> >>> On Sat, Jan 10, 2026 at 8:39 PM John Sarabacha <[email protected]> >>> wrote: >>> >>> > Hi, >>> > My approach to testing amForth is somewhat different. The MounStudio >>> makes >>> > it easier to deploy/debug the software on the chip level from Windows >>> 11 >>> > instead of using QEMU. >>> > Testing the core software for amForth whether ARM32 or RISCV is going >>> to be >>> > similar, the way I am handling this is the riscv/words (arm/words) >>> > directory contains the assembler code for the words 73 files 1 file for >>> > each base word (same for arm). I am checking each one, some are >>> visually >>> > easily verifiable (e.g contain 1 or 2 assembler instructions). Then I >>> will >>> > check the runtime results of each of these 73 words. If those results >>> are >>> > correct (above) the (DOCOLLEN) words in shared/words directory should >>> also >>> > work since they use those base words. Same would be true for the >>> > appl/.../words. >>> > This is just a start, a runtime combination of words could still fail. >>> That >>> > is why an automated means of testing can help. >>> > At some point I will be using CLIPS (expert system shell) to help this >>> > testing process, CLIPS based rules will generate sequences of XT byte >>> codes >>> > and examine the results of execution to analyse and help diagnose >>> problems. >>> > >>> > Regards, >>> > John S >>> > >>> > >>> > >>> > >>> > >>> > >>> > On Sat, Jan 10, 2026 at 3:18 PM Martin Kobetic <[email protected]> >>> wrote: >>> > >>> > > Hello again, >>> > > >>> > > I keep running into basic things being broken on the ARM >>> architecture; >>> > > yesterday I found out that even division doesn't work correctly. It >>> won't >>> > > be hard to fix, but it made me yearn for the ability to run the >>> standard >>> > > Forth test suite against the ARM build. >>> > > >>> > > I noticed that the test/ directory is attempting something similar >>> and >>> > > arguably more ambitious by running a test suite against actual >>> boards, >>> > > which is certainly very useful, but I'm after something much more >>> basic. >>> > > Any 32-bit arm based target should do to test the core words. >>> > > >>> > > So I made another attempt at getting the linux-arm build running. I >>> still >>> > > haven't figured out how to make it run under bare QEMU (I'm lost in >>> the >>> > > various details that are required to emulate a Raspbery PI, I will >>> get >>> > > there eventually), but I did get it running in an emulated 32-bit ARM >>> > > container. The Makefile on my branch shows the details how >>> > > >>> > > >>> > >>> https://github.com/mkobetic/amforth/blob/unor4/appl/linux-arm/Makefile#L36-L57 >>> > > >>> > > With that I was able to attempt the core test suite run. Running >>> `make >>> > > test` currently ends on this sour note: >>> > > --- >>> > > ... >>> > > > TESTING BOOLEANS: INVERT AND OR XOR >>> > > ok >>> > > > >>> > > ok >>> > > > T{ 0 0 AND -> 0 }T >>> > > ok >>> > > > T{ 0 1 AND -> 0 }T >>> > > ok >>> > > > T{ 1 0 AND -> 0 }T >>> > > ok >>> > > > T{ 1 1 AND -> 1 }T >>> > > qemu: uncaught target signal 11 (Segmentation fault) - core dumped >>> > > Segmentation fault >>> > > --- >>> > > This is to be expected because variables are still broken on ARM and >>> they >>> > > are critical for the test framework to function. Frankly I'm >>> surprised it >>> > > managed to get that far. >>> > > >>> > > But anyway, what gets me excited is how easy it is to run the tests >>> and >>> > > collect results with the linux-arm build. With a bit of programming >>> I can >>> > > process the results and output pass/fail stats and make the job pass >>> or >>> > > fail based on that. From there it shouldn't be hard to get a fully >>> > > automated CI run on any platform that supports 32-bit ARM (or at >>> least >>> > some >>> > > sort of emulation). It looks like Github Actions should accommodate >>> that >>> > > reasonably easily. I'm not sure how hard it would be to get the same >>> for >>> > > RISC-V, but I'd be surprised if there weren't any (free) options for >>> that >>> > > somewhere. A Raspbery PI style linux-riscv build could probably be >>> very >>> > > similar to the linux-arm one. >>> > > >>> > > Anyway, please let me know if I'm rediscovering the wheel here. Any >>> hints >>> > > or pointers to previous efforts in this direction would be very >>> welcome. >>> > > >>> > > Cheers, >>> > > >>> > > Martin >>> > > >>> > > _______________________________________________ >>> > > 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
