> Why not use amforth's assembler.frt for words with a need for speed? Right > now I need to reflash the base image every time I forget some words that > are implemented in assembly.
It's not a matter of speed, but a matter of bootstrapping the system. The whole forth compiler is written in forth, in fact most of amforth, only that many files are written with assembly syntax. Why? Well, to compile a word, a running compiler is needed. Which files were written in assembly and which in forth, has changed over the years. It depends on which words are useful/needed initially and which can be uploaded later. Since the file include works with the amforth-shell, many assembly files were rewritten as forth code. > > Some people (such as myself) may be flashing a large number of nodes before > deployment. For this reason it would be good to bootstrap-metacompile that > base image rather than building a tiny core image on the host and compiling > the rest on the microcontroller. > > Metacompiling the image would have the advantage that the entire & complete > application could be compiled to ihex for deployment and require no uploads > over UART. Which somewhat contradicts what I want to do with amforth: I do not want to create a hex file that is flashed to the controller. That is C-like. The Arduino works that way too. > So, a metacompiling Forth system should be able to run code out of its own > image in order to be built up on the host to become a complete system. Doable? Yes, of course. Changing amforth to work that way? Unlikely. The second goal with amforth is to have a simple system. Something I can understand even after a long working day with crying kids around. Metacompiling and other voodoo is definitly nothing I want to do. Matthias ------------------------------------------------------------------------------ _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
