>> That may offer wide portability via cross compilers, but they adopt code >> that isnt as close to the target cpu as possible.
If you are worried about this then use "volatile asm(...)" On Fri, Jan 30, 2026 at 10:07 AM John Sarabacha <[email protected]> wrote: > 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
