Hi George, I am encouraged that at least one person is reading these emails. I prefer assembler coding over other languages (many of them), I have done it for many years. My only problem was that I would go back to programs that I originally wrote and be scratching my head and saying to myself "what the heck was I doing here?". One humorous point, one time I was trying to fix someone else's assembly code (many years ago now) and as I was shifting through his code the original author commented "if you are reading this comment you are in deep trouble" in terms of a fix. For me forth is the next step above assembler.
Regards, John S On Fri, Jan 30, 2026 at 2:33 AM John Sarabacha <[email protected]> wrote: > 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
