Hi Erich, >> assembling. That was changed, because /other targets/ needed the >> same words, so he went /back/ to Forth source code. I'm not >> saying this is bad, it is just a detail that came with adding >> other targets.
In my case this turned out to be a good thing, as it allowed me to use ITC and DTC more easily. It got to the point where I could mix the two models without problems. If one wanted to, you could tweek the prim_secs words for speed or compactness by specifying which macro (ITC or DTC) you wanted. The other benefit was it was another step towards platform (hardware) independence. In line with other comments that I have seen, this work is fun (joy) for me. Where it goes I honestly don't know, that is part of the fun (joy). Thanks again for your information (including background and design decisions), John S On Fri, Jan 30, 2026 at 9:15 PM John Sarabacha <[email protected]> wrote: > Hi Erich, > Taking your suggestion very seriously > >> questions, that I cannot answer. *I would encourage a split/fork* > > and instead of > >> I will be leaning on AmForth-ML (a version that supports Machine > Learning) > > I will be using the name AmForth-GLANN since GLANN is already a registered > trademark > (there should be no name conflicts) and Machine Learning is also implied > in this name. > Changes to the original source relating to AmForth and used, will be made > available at > dedicatedcomputer.ca/test > Bug fixes that are made to the original source (currently using > amforth-code-r2462) will be passed > back to the maintainer (Tristan W). > > Thanks again for your input, > John S > > > > > On Fri, Jan 30, 2026 at 5:35 PM John Sarabacha <[email protected]> > wrote: > >> Hi Erich, >> >> I have spent a lot of time to find a small bug in AmForth >> >> regarding interrupt handling (my systems lost time ticks for no >> >> apparent reason). That was fixed in 6.5 or so. And in another >> >> project I spent an unbelievable amount of time, but the project >> >> never became stable. So that's when I decided to go back to >> >> version 5.0, just to have a smaller and less complex codebase to >> >> work with. And it paid for me. >> >> I can relate to this many times over, not to AmForth (it has been kinder >> to me) >> but my own applications, many a time it is related to imperfect software >> tools >> and not to any coding errors. That is why I had better results forcing >> the compiler >> to generate my code, not its code (eg using volatile asm(...)). >> >> Regards, >> John S >> >> >> On Fri, Jan 30, 2026 at 4:39 PM John Sarabacha <[email protected]> >> wrote: >> >>> >> questions, that I cannot answer. I would encourage a split/fork >>> >> and call the thing AmForth-riscv and NOT look left or right to >>> >> other targets. But that is just my humble opinion. >>> >>> I will be leaning on AmForth-ML (a version that supports Machine >>> Learning) >>> minimizing hardware dependencies. >>> >>> On Fri, Jan 30, 2026 at 3:58 PM John Sarabacha <[email protected]> >>> wrote: >>> >>>> Hi Erich, >>>> >> 3. Matthias wanted AmForth to be as close to the standard as >>>> >> plausible. Of course there are differences, like the @e !e @i !i >>>> >> Variants of @ and !. That is attributed to being close to the >>>> >> hardware. Otherwise Matthias spent a lot of time to get AmForth >>>> >> close to the standard. >>>> >>>> This was the most important aspect of AmForth, the actual hardware >>>> target is not as important as this. >>>> I am always amazed at how forth (with its many variants) has survived >>>> the test of time. Many hardware >>>> platforms have come and gone but forth is still here. The abstraction >>>> layer that I talked about isolates the >>>> hardware dependencies to keep changes to a minimum. What you want is >>>> being close to an acceptable standard. >>>> My application needs to run on a large number of nodes which could >>>> involve many different platforms on a network. >>>> It is interesting that the AmForth site (Commented Projects) has a link >>>> (put there by Matthias?) that parallels what >>>> is being done (but not with Wifi, RF or ethernet), experimentally of >>>> course. >>>> >>>> >>>> http://www.complang.tuwien.ac.at/anton/euroforth/ef15/genproceedings/papers/peri.pdf >>>> >>>> Again I appreciate your input, >>>> Regards, >>>> John S >>>> >>>> >>>> On Fri, Jan 30, 2026 at 2:35 PM Carsten Strotmann via Amforth-devel < >>>> [email protected]> wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> On Friday 30 January 2026 06:51:32 PM (+01:00), Erich Wälde wrote: >>>>> >>>>> > 2. Matthias started out with an indirect threaded code model, >>>>> > because he understood, how it worked. Making this thing fast was >>>>> > not high on the list. At the time he started there was a series >>>>> > of articles in the "Vierte Dimension" magazine, on how to >>>>> > construct a Forth from scratch. It was written by Ron Minke >>>>> > around 2005/2006. >>>>> > > https://forth-ev.de/wiki/vd-archiv >>>>> > Unfortunately the links seem broken ... I have to tell -mk. >>>>> > >>>>> >>>>> I can bring light into this issue: because Forth-Gesellschaft has been >>>>> sued over the use of one picture in the VD magazine, for legal reasons the >>>>> PDF download versions are not freely available anymore. The case has not >>>>> been settled, but as a precaution the PDFs have been de-published. >>>>> >>>>> They will be available for members of Forth Gesellschaft in the >>>>> future, we're working on a new system with authentication. >>>>> >>>>> I'm not sure if Forth Gesellschaft will risk allowing non-members in, >>>>> as this incident almost killed Forth Gesellschaft financially. >>>>> >>>>> If someone here wishes to support work on Forth publications, maybe >>>>> consider becoming a member. There is (was?) an English translated version >>>>> of the magazine in addition to the German edition. >>>>> >>>>> Greetings >>>>> >>>>> >>>>> Carsten >>>>> (who will be @ FOSDEM, in the Retro-Computer Devroom on Sunday, in >>>>> case someone want's to meet and talk some Forth) >>>>> >>>>> -- >>>>> strotmann.de >>>>> >>>>> >>>>> _______________________________________________ >>>>> 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
