Hi Martin, Some information on my Cortex-M7 based target platform, Arduino development environment is being is used https://www.pjrc.com/store/teensy41.html
Regards, John S On Mon, Jan 12, 2026 at 12:04 PM John Sarabacha <[email protected]> wrote: > 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
