Here is a copy of the email from Brad Nelson below. Note: in riscv-assembler.fs assembler.fs code.fs the necessary the implementation is an option and the information is stored as strings in flash memory which gets evaluated at run time which could be at an interactive session (this is demonstrated by Brad Nelson a youtube video - 2020 forth interest group).
Hi John, At some point I moved the assembler/disassembler into an optional module here: https://github.com/flagxor/ueforth/blob/main/esp32/optional/assemblers/riscv-assembler.fs With the shared (with Xtensa) core here: https://github.com/flagxor/ueforth/blob/main/common/assembler.fs https://github.com/flagxor/ueforth/blob/main/common/code.fs Since that presentation, I've not done a lot with it, as I hit an issue that made it less useful than I'd hoped. ESP32-C3 through Arduino has the RISC-V configured in a mode where writing code after boot is disallowed. So unlike for Xtensa it can only really function as a disassembler (it can assemble but not to executable memory). In terms of the approach (using words to populate mask tables), it worked reasonably well. For porting it things to consider: * There's uEforth specific wrapping involving r| .. | to allow for lazy loading of the assembler/disassembler, this would need to be dropped / changed. * uEforth uses a weird mish-mash of Forth79 and Forth83 vocabularies, it might need to be adapted to whatever AmForth has (sorry am unfamiliar) * The assembler redefines the word i to be a bit indicator for immediates in the RISCV instruction set. If not wrapped in a vocabulary, this could clash with the standard name. * code.fs is filled with uEforth specific assumptions about how words are laid out and how to do unaligned writes. It would need to be replaced with something equivalent. * The assembler uses FOR..NEXT and FOR..AFT..THEN..NEXT <https://github.com/TG9541/stm8ef/wiki/eForth-FOR-..-NEXT> instead of DO..LOOP / ?DO..LOOP. - These would need to be replace accordingly - FOR..NEXT --> 1+ 0 DO...LOOP - FOR..AFT..THEN..NEXT --> 1+ 0 ?DO...LOOP - At a glance it looks like the loop variable I / R@ is not relied on (and DO is used where it is), so simple substitution will probably work. Regards -BradN On Thu, Jan 1, 2026 at 12:30 PM <[email protected]> wrote: > Hello John, > > Sounds very interesting. You are correct, there is no > Forth assembler for RISC-V in the current RISC-V repo. > > > 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. > > Do you have a link for this? The ability to define CODEWORDS > interactively and store in RAM or flash would be a major > step forward for AmForth RISC-V. > > Best wishes, > Tristan > > > On 2025-12-31 17:42, John Sarabacha wrote: > > 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 > > > _______________________________________________ > 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
