Well, use of an abstraction layer in the C compiler tends to have some sort of unstated simplification involved.
That may offer wide portability via cross compilers, but they adopt code that isnt as close to the target cpu as possible. C compolers are in a merry chase to keep up with ever changing new hardware. That has always been the dilemma of assembler code Forth versus Code Forth. For some, Forth is ideally best in hardware specific assembler. It is an endless debate. On Fri, Jan 30, 2026, 12:24 John Sarabacha <[email protected]> wrote: > Some clarification, even though C is being used in the builds, it generates > an assembler based AmForth target. It doesn't need C on the target (but > could use it if you want). The C macros are used by the cross-compiler to > generate the assembler based target build. The portability comes from the > abstraction layer for the mcu which generates mcu assembler code by the > cross-compiler. There can be an abstraction layer for the mcu of interest > (riscv, arm, xtensa, i386, ...). > The AmForth code base can become more maintainable, extensible and used > more easily for other targets (portability). > > Regards, > John S > > On Thu, Jan 29, 2026 at 10:59 AM John Sarabacha <[email protected]> > wrote: > > > Hi Everyone, > > Those interested in these new developments, please let me know if you > have > > trouble downloading from > > dedicatedcomputer.ca/test > > there should be at least 2 files zipped, macros.h and dict_prims.c > > > > Regards, > > John S > > > > On Wed, Jan 28, 2026 at 4:49 PM John Sarabacha <[email protected]> > > wrote: > > > >> Hi Tristan, > >> The main problem with the portable C approach for forth is that the > >> interpreter (ITC) consumes a lot of mcu cycles so you need assembler > >> code at > >> some point to compensate. With just C this problem is amplified even > when > >> optimized. > >> > >> Regards, > >> John S > >> > >> > >> On Wed, Jan 28, 2026 at 4:25 PM John Sarabacha <[email protected]> > >> wrote: > >> > >>> Hi Tristan, > >>> This is interesting, they use portable C for forth, whereas my approach > >>> is to use portable C to deliver assembler code for forth, by creating > an > >>> abstraction layer for the mcu. This allows you to interface C routines > and > >>> keep the performance of assembly code. > >>> > >>> Regards, > >>> John S > >>> > >>> > >>> On Wed, Jan 28, 2026 at 2:15 PM <[email protected]> wrote: > >>> > >>>> Hi John, > >>>> > >>>> Interesting. > >>>> > >>>> A different target in that of an embedded mcu, but perhaps some > >>>> parallels with ATLAST [1]. The links in the Documentation section (of > >>>> [1]) give an interesting history and rationale. > >>>> > >>>> Best wishes, > >>>> Tristan > >>>> > >>>> [1] https://github.com/Fourmilab/atlast?tab=readme-ov-file > >>>> > >>>> > >>>> On 2026-01-23 18:40, John Sarabacha wrote: > >>>> > Hi Everyone, > >>>> > For using ITC and DTC based forth code the next step is making > >>>> AmForth > >>>> > more > >>>> > portable. > >>>> > Any platform that supports C will be able to use amForth (as a > >>>> > subsystem). > >>>> > The terminology that I am using is that AmForth is the full > >>>> > independent > >>>> > system and amForth is a subsystem based on AmForth. > >>>> > The 1st step is moving the primary words to a form which is more > >>>> > portable > >>>> > across > >>>> > platforms using asm(...) calls with a C infrastructure. Then using > >>>> this > >>>> > as > >>>> > a foundation for all the words. > >>>> > > >>>> > 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
