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
