Hi Erich, Somehow I knew others were reading (like yourself). I was drawn to AmForth because of the amount of effort that was put into it (documentation is quite good) even though it (riscv & 32 bit arm) was considered experimental. From what I have seen in the codebase and documentation is that Matthias pursued his dream and was quite the programmer. His legacy will carry on.
I really appreciated your response, Regards John S On Fri, Jan 30, 2026 at 1:07 PM Erich Wälde <[email protected]> wrote: > > Hello all, hello John, > > of course people on the list are reading. I read with interest, > however, my world is different. I'm unable to follow your > experiments in detail. I try to explain, as good as I can. > > > 1. Matthias wanted a comfortable Forth, not a starved one where > minimalism kills everything else. That's why he dropped support > for AVR controllers with /only/ 8kB of flash. They did work with > earlier incantations of AmForth. > > 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. > > 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. > > 4. Matthias' implementation of recognizers, and the > implementation of the inner interpreter using them, was one of > the first implementations. He produced at least 3 iterations > that were presented to the standards comittee, iirc. > > 5. Matthias then went to add other targets. msp430 first. And we > had discussions on how to overcome the lack of eeprom (or some > very different handling of it?), among other things. > > I feel entitled to write these 5 paragraphs, as I knew Matthias > personally, and we spend many hours in a weekly chat kindly > hosted by Bernd Paysan of gforth fame. > > > As Tristan said somewhere, the design decisions of avr AmForth > ripple through the whole codebase. I can recall that AmForth > initially hat a lot of additional words in fairly readable > assembly code. You just included it into the dictionary before > 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. > > The arm and later riscv targets required to base their code on > gnu asm. That is imho a completely different beast, and a > different way of setting up the system. > > In hindsight I feel, it was somewhat unfortunate, that adding 3 > more targets did not lead to the split into separate projects. I > did think about doing this during my term as a maintainer. But > the whole code base is a bit above what I can handle in the > evenings. > > > I personally went /back/ to AmForth 5.0, because that was the > last version that did assemble with upstream avra. Mark Roth has > since added a few patches, so I could go up to 5.5 now. 5.6 was > the release that added msp430 support. > > 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. > > > Now, I'm not anywhere near to decide, what happens to AmForth, > because Matthias has left this planet. And who does the work is > going to decide. Whether or not building AmForth on C or C > macros, or pure gnu assembly for riscv, or whether to switch to > a direct threaded code model, or a native code model, or whether > squeezing out every clock cycle possible --- these are all > 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. > > > Cheers, > Erich > > > -- > May the Forth be with you ... > > > _______________________________________________ > 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
