Hello everyone, Intermixing ITC & DTC appears to be working well, the real challenge so far is keeping the dictionary 32bit aligned. The RISCV toolchain is generating misaligned addresses almost randomly (should still be viewed as experimental tools). I have noticed (in the code base) that the previous developer was dealing with the same issues. Wanted to keep the code base in the release with minimal changes. For reliability, I am looking to move the dictionary into C data structures and leave the code intact.
The glass is half full, not half empty, Regards, John S On Wed, Jan 21, 2026 at 10:27 AM John Sarabacha <[email protected]> wrote: > This information (on DTC) should probably be in the opinions section. > This DTC work also has the advantage that it is tested incrementally along > with my current application which is known to work quite reliably across a > network. Only known to work code changes are being made to amForth macros, > risc-v words, shared words and platform words. These changes will be > released when complete and fully stress tested. > > Regards, > John S > > On Wed, Jan 21, 2026 at 2:41 AM John Sarabacha <[email protected]> > wrote: > >> Hello, those following riscv DTC development, >> Here are some very preliminary results: >> >> A snippet from the assembly listing of latest build: >> 00003458 <XT_CHAR>: >> 3458: 014e slli sp,sp,0x13 >> ... >> 0000345c <PFA_CHAR>: >> 345c: e04fd0ef jal ra,a60 <PFA_DTC_PUSH_RETURN> >> 3460: cbffe0ef jal ra,211e <PFA_PARSENAME> >> 3464: e18fd0ef jal ra,a7c <PFA_ZEROEQUAL> >> 3468: 00018293 mv t0,gp >> 346c: 00022183 lw gp,0(tp) >> 3470: 0211 addi tp,tp,4 >> 3472: 00500763 beq zero,t0,3480 <CHAR_1> >> 3476: 94cfe0ef jal ra,15c2 <PFA_DOLITERAL> >> 347a: 51c1 li gp,-16 >> 347c: adbfe0ef jal ra,1f56 <PFA_THROW> >> >> 00003480 <CHAR_1>: >> 3480: db8fd0ef jal ra,a38 <PFA_CFETCH> >> 3484: de2fd0ef jal ra,a66 <PFA_DTC_PULL_RETURN_EXIT> >> ... >> Those reading riscv assembly (ra is X1, gp is X3(tos), tp is X4), the ITC >> linkage is still there >> and can be used to execute the DTC code (PFA_CHAR). The DTC code will >> outperform the ITC equivalent. >> Some instruction compression here balances the extra code needed for >> nesting, performance can increase further at the cost of increasing size by >> inlining (using the DTC macro below instead of DTS). >> The shared\char.s file used in this build: >> COLON "char", CHAR >> DTS DTC_PUSH_RETURN # Allows nesting >> DTS PARSENAME # Subroutine call >> DTS ZEROEQUAL # " >> DTB DOCONDBRANCH, CHAR_1 # Conditional Branch >> DTS DOLITERAL # Subroutine call >> DTD -16 # Data >> DTS THROW # Exception >> CHAR_1: >> DTS CFETCH # Subroutine call >> DTS DTC_PULL_RETURN_EXIT # DTC Return >> >> Best Regards, >> John S >> >> >> >> On Mon, Jan 19, 2026 at 11:48 AM John Sarabacha <[email protected]> >> wrote: >> >>> Hello to all those following this chain of development (ITC and DTC), >>> As changes are being made to the risc-v and shared code base the light >>> is getter brighter (things are getting clearer), >>> Using a combination of ITC and DTC for user interaction and user created >>> words and DTC for the default dictionary (primary, shared and platform >>> words in flash). Using this approach incrementally, I am getting >>> smaller and faster incremental builds by examining the assembly listings of >>> the builds. The real proof of concept will be when all the changes are made >>> and the final build tested. >>> >>> Regards to all, >>> John S >>> >>> >>> >>> >>> >>> >>> >>> >>> On Sun, Jan 18, 2026 at 10:18 AM John Sarabacha <[email protected]> >>> wrote: >>> >>>> Hello everyone, >>>> My implementation of amForth will address the performance issues >>>> relating to ITC and DTC, >>>> the results will be posted here as well as where to get the changes >>>> that were made to amForth (and which release was used). Currently amForth >>>> (risc-v & arm) appears to use more (for most primitives) instruction cycles >>>> in the ITC than the actual primitive code itself. >>>> A balance is needed when to use DTC or ITC which can be made more >>>> dynamic depending on changing needs. >>>> >>>> Regards, >>>> John S >>>> >>>> On Sat, Jan 17, 2026 at 11:07 PM John Sarabacha <[email protected]> >>>> wrote: >>>> >>>>> For those interested in this topic and some history (ITC and DTC), >>>>> These concepts are not new, they were used way back in the '80s in >>>>> scada software, used to monitor and control natural gas pipeline >>>>> compressor >>>>> stations across Canada (100s of them). Macros (as in macros.s) were used >>>>> to >>>>> create dictionary type (IO) structures on hard disks and magnetic tape >>>>> cartridges (which loaded into memory). Usarts were used in series to >>>>> communicate using a direct phone line across Canada to DEC LSI-11 >>>>> computers >>>>> (Charles Moore is probably familiar with them). Instead of forth, >>>>> rsx11-m/s >>>>> operating systems (with 16 bit cpus) were used. The scada software was >>>>> using a combination of ITC and DTC written in macro assembler. As in forth >>>>> this software used keywords (interactively) to drive the color video >>>>> displays (monitors) at the main control center and keywords (turnkey) that >>>>> provided the packing and unpacking of communication data packets >>>>> travelling >>>>> on the direct phone line. >>>>> All in real-time. My role back then was independent software >>>>> analyst/programmer (consultant). >>>>> Although this implementation (for RISCV) is still experimental, the >>>>> concepts have already been proven. >>>>> To-day we have 32bit mcus, more sram than was used back then and >>>>> faster flash instead of hard disks and magnetic tapes. >>>>> >>>>> Yes this is still experimental. >>>>> Regards, >>>>> John S >>>>> >>>>> >>>>> On Sat, Jan 17, 2026 at 12:34 PM John Sarabacha <[email protected]> >>>>> wrote: >>>>> >>>>>> Also finding that ITC and DTC can be intermixed within >>>>>> shared\words\*.s >>>>>> by just leaving NEXT macro as the default for ITC and adding NEXT_DTC >>>>>> for DTC. >>>>>> The NEXT_DTC and DTC_MODEL macros being added to macros.s. In the >>>>>> shared/words/*.s files >>>>>> the default .word XT_(primative name) still being the default and >>>>>> using the macro DTC_MODEL to provide DTC support within the same *.s file >>>>>> intermixed with ITC .word XT_(primative name). >>>>>> Again this is still experimental. >>>>>> >>>>>> Regards, >>>>>> John S >>>>>> >>>>>> On Sat, Jan 17, 2026 at 11:57 AM John Sarabacha <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi All, >>>>>>> The code execution model of amForth can be easily changed to >>>>>>> support ITC (Indirect Threading Code) and DTC (Direct Threading >>>>>>> Code). >>>>>>> On RISCV the DTC model takes advantage of a call and return using a >>>>>>> register to provide the return address which uses fewer instruction >>>>>>> cycles >>>>>>> than the ITC. >>>>>>> This has the advantage of faster execution and more compact compiled >>>>>>> words (shared\words) the dictionary and sram. The changes are almost >>>>>>> trivial, the NEXT macro in macros.s can have a conditional assembly of j >>>>>>> (jump for ITC) or ret (return for DTC). >>>>>>> Also an additional macro in macro.s which conditionally assembles to >>>>>>> .word XT_(primative name) (for ITC) or a call PFA_(primative name) (for >>>>>>> DTC). This new macro used within the shared\words\*.s files and it would >>>>>>> prefix the primitive word name with XT_ (for ITC) or PFA_ (for DTC). >>>>>>> Again this is still experimental. >>>>>>> >>>>>>> Regards, >>>>>>> John S >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ [email protected] https://lists.sourceforge.net/lists/listinfo/amforth-devel
