Hello, Brad Nelson (ueForth & esp32Forth) was kind enough to provide his work on a forth assembler for RISCV and Xtensa and also porting information and current limitations and learnings of his implementation. This feature is missing from AmForth (that I can see), although AmForth can compile dictionary words to sram it is missing an assembler that can compile words interactively that embed RISCV assembly instructions which run in sram. This feature can speed up code execution (running in sram) of forth because flash memory execution of code can involve wait states. This port of RISCV assembler for AmForth is experimental at this point and any successful and useful findings can be listed in the opinion section. This feature may also work for ARM32 AmForth (using the ARM primitives). However Brad Nelson ran into roadblocks in his arduino implementation of assembler for ESP32. The Xtensa support could assemble and disassemble but the RISCV support could only disassemble.
Regards, John S On Wed, Dec 31, 2025 at 7:26 AM Erich Wälde <[email protected]> wrote: > Hello, > > > On 2025-12-31 02:32, Nigel Rowe wrote: > > >> having got amforth running on an arduino nano, I wanted to > >> use *marker* ... > > >> OK, so the problem is in does>, ... > > I have used marker and definitions with does> extensively, and > they do work as advertised, at least up to version 6.9, on avr > controllers (mostly atmega644p). > > From what you describe, I would rather suspect, that there is > something else wrong. Maybe your build has a subtle shortcoming, > or flashing/uploading is missing something, or eeprom content is > not correct, i.e. not correctly coresponding to ram. Or your > controller is configured strangely (fuse bits?). Or your > controller could be subtly broken. Also consider using another > board, like an uno, if possible. > > I have wasted countless hours chasing ghosts like these. > > Good luck! > Erich > > [email protected] writes: > > > Hello Nigel, > > > > I can't reproduce the error from the pastebin with my build of AmForth. > > > > |S| 1|anew empty.tests > > |W| 2| > > |S| 3|: const create , does> @i ; > > |S| 4|42 const ltuae > > |S| 5|ltuae > > |S| 6|. > > |O| 6|42 > > |W| 7| > > > > Above works as expected > > > > |S| 8|anew empty.tests > > |W| 9| > > |S| 10|ltuae > > |E= ?? -13 5 > > |S| 11|. > > > > Above works as expected (can't find ltuae) > > > > |E=0 ?? -4 1 > > |W| 12| > > |S| 13|words > > |O| 13|empty.tests empty White Cyan Brown Blue Yellow Green Red Black > > text_reverse text_blink text_underline text_bold text_normal background > > foreground page at-xy ESC[ .;n .n ESC[ mandelbrot dorow docell doescape > > init_vars count_and_test? escapes? .char zi_sq zr_sq count zimag zreal > cimag > > creal s_escape rescale maxval minval maxiter empty.fun show show.short > > show.long (show) > > > > Above works as expected - words works (output truncated) > > > > So that leaves differences between our hardware/builds. > > > > For hardware a set of known working hex files could be > > flashed to your hardware. For the build, it is more complicated, > > as AmForth will build on multiple operating systems/assemblers. > > > > How are you building AmForth? > > > > One option would be to try building from below in your current way. > > > > https://sourceforge.net/p/amforth/code/2457/tree/releases/6.9/ > > > > This removes the few changes I have made (see link) since > > > > https://sourceforge.net/p/amforth/mailman/message/59254494/ > > > > Best wishes, > > Tristan > > > > > > On 2025-12-31 02:32, Nigel Rowe wrote: > >> Greetings, > >> having got amforth running on an arduino nano, I wanted to use *marker* > >> (I'm using italics for amforth words). Actually I want to use *anew*, > but > >> that requires *marker*. > >> So I #included marker.frt, then did *marker* -*empty*-. got the prompt > >> back, but when I then typed *words*, I got " ?? -13 5". > >> I tried a few other words, same result, numbers however, were accepted > >> without complaint. > >> I then did the "make install", #include mymarker.frt (a sucessivly > >> truncated version of marker), got the same result, rinse and repeat, > until > >> removing *does>* stopped crashing amforth. > >> OK, so the problem is in does>, so rather than playing with marker, I > >> created the most basic word that uses *does>*. > >> *: const create , does> @i ;* (straight out of the cookbook). Same > >> problem, it compiles ok, but when I do > >> *42 const ltuae *now I'm back to the same " ?? -13 x" problem (x > obviously > >> varies depending on the word I type). > >> The symptoms make me think executing does> fouls up *dp*, or *newest*, > or > >> maybe something used by *get-current*. But what do I know? > >> So I look at the source (does.asm), paper traced through XT_DODOES, > makes > >> sense, looks like it does what the comments indicate it should. So I > >> looked at DO_DODOES, and I have no idea, last time I did any assembler > was > >> in the 1980s on a Z80. So I'm lost. > >> Copy of last amshell session is here https://pastebin.com/L60vNSrY > >> Thanks for reading, hopefully someone can help. > >> Nigel > > > > > > _______________________________________________ > > Amforth-devel mailing list for http://amforth.sf.net/ > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/amforth-devel > > -- > 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
