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
