Hi again George, I agree that you're better off with an assembler version of forth. The C code with the abstraction layer is for the benefit of the cross-compiler which generates the assembler code for your forth. You don't need C on your target machine, you can still have pure assembly.
Regards, John S On Fri, Jan 30, 2026 at 2:05 AM John Sarabacha <[email protected]> wrote: > Hi George, > I welcome your comment on this. I have used this method already it can > generate the same machine instructions > as an assembler would, it uses asm(...) within C code, the cross-compiler > passes it along to the assembler part of the tool chain. It is quite common > to do this to improve performance within C code. > > Regards, > John S > > On Thu, Jan 29, 2026 at 11:37 PM George H <[email protected]> > wrote: > >> 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 >> > _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ [email protected] https://lists.sourceforge.net/lists/listinfo/amforth-devel
