Hi Everyone, For those looking at these code changes a few notes: 1) The builds generated are only as good as the underlying code base, I used R2462 distribution as the base. 2) The crossover point of using ITC or DTC equivalent was 3 or 4 assembler instructions. 3) The DTC is using inline assembly instructions. 4) DTS uses subroutine calls to underlying code (not utilized yet). 5) ITB uses relative addressing instead of absolute addressing, this gives you relocatability of forth words from flash to sram (e.g. ISRs, vector tables ...). 6) GPLv3 and DRM restricts my ability to fully utilize AmForth without affecting IP. Fortunately there are other forths (with better licensing) that can fill that gap. 7) The assembly abstraction layer generates the actual assembler instructions, and handles the translation of registers x1 -> x31 to what is appropriate for the build (you don't have to change your entire code base if you need a register change).
Have a good day! Regards, John S On Mon, Feb 2, 2026 at 11:43 PM John Sarabacha <[email protected]> wrote: > Hi Tristan, > The latest changes have been made available. Addition of dict_secs.c with > support for ITC & DTC models and code relocatability. > These C files will be used by the cross-compiler to generate an assembler > based build, essentially a one to one instruction equivalent > of the assembler only source build. > > Regards, > John S > > On Mon, Feb 2, 2026 at 5:42 PM John Sarabacha <[email protected]> > wrote: > >> I forgot to mention it could also affect the relocatability of your code, >> like moving forth code from flash memory to sram memory. >> >> On Mon, Feb 2, 2026 at 5:29 PM John Sarabacha <[email protected]> >> wrote: >> >>> Hi Tristan, >>> This gives me more confidence in the code base and saves me time >>> investigating further. >>> Have you tried this in sram (your own user created word) rather than >>> flash resident code. >>> The flash resident code won't manifest this problem but the user created >>> words could. >>> Anyway I will now be releasing my version of dict_secs words (with >>> relative addressing) and it >>> will be updated further when the AmForth codebase is more stable. >>> >>> Thanks for getting back to me on this, >>> John S >>> >>> >>> >>> On Mon, Feb 2, 2026 at 3:49 PM <[email protected]> wrote: >>> >>>> Hi John, >>>> >>>> There is no issue with nesting or recursion and the design choice to >>>> branch to an address, rather than to an offset. >>>> >>>> |F=./fac.f >>>> |S| 1|: factorial ( n -- n! ) >>>> |S| 2| dup 2 < if \ base case: if n < 2, return 1 >>>> |S| 3| drop 1 >>>> |S| 4| else >>>> |S| 5| dup 1- \ compute n-1 >>>> |S| 6| recurse \ recursive call: factorial(n-1) >>>> |S| 7| * \ multiply n * factorial(n-1) >>>> |S| 8| then ; >>>> >>>> > 10 factorial u. >>>> 3628800 ok >>>> >>>> There are situations nowadays where relative branches would make things >>>> easier, but I'm unconvinced these situations really existed on the >>>> target hardware in 2007. However, it is 2026 not 2007, and so is it >>>> worth looking at again? Certainly, and since AmForth is an open source >>>> project, we all have that opportunity. >>>> >>>> Best wishes, >>>> Tristan >>>> >>>> On 2026-02-02 18:30, John Sarabacha wrote: >>>> > Hi Everyone, >>>> > There is an issue (or a lack of a useful feature) in the Amforth >>>> > distribution (32 bit riscv & arm, since they share the same secondary >>>> > hand >>>> > compiled words), I have made the adjustments to the secondary words >>>> > (which >>>> > I have not released yet, as I am verifying its impact). I suspect >>>> these >>>> > are >>>> > causing some of your tests to fail. This revolves around the use of >>>> > BRANCH >>>> > and CONDBRANCH primary words and the addresses they are using, they >>>> > should >>>> > be relative addresses and not absolute addresses specified in >>>> > .word(...) >>>> > after the BRANCH or CONDBRANCH. If there is no nesting or recursion >>>> > involving these words then no problem, but then you are limiting what >>>> > you >>>> > can do. >>>> > >>>> > Hope this helps, >>>> > John S >>>> > >>>> > _______________________________________________ >>>> > 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
