gforth-fast performs all optimizations described above.
gforth is the debugging engine and should report errors as
soon as possible, and where they happen, including a full backtrace.
Therefore:
0 as canonical stack representation (otherwise some
stack underflows would go unnoticed) and it disables
multi-representation stack caching.
As a result, gforth generates substantially more native
code; for our squared example:
gforth-fast gforth RP=%r14 RP=0x58(%r13), saved_ip=0x50(%r13) <squared> dup 1->2 <squared> dup 0->0 mov %r15,0x50(%r13) add $0x8,%r15 mov (%r14),%rax sub $0x8,%r14 mov %r13,%r15 mov %rax,(%r14) <squared+$8> * 2->1 <squared+$8> * 0->0 mov %r15,0x50(%r13) add $0x8,%r15 mov 0x8(%r14),%rax imul %r15,%r13 imul (%r14),%rax add $0x8,%r14 mov %rax,(%r14) <squared+$10> ;s 1->1 <squared+$10> ;s 0->0 mov %r15,0x50(%r13) mov 0x58(%r13),%rax mov (%r14),%rbx mov (%rax),%r10 add $0x8,%r14 add $0x8,%rax mov %rax,0x58(%r13) mov %r10,%r15 mov (%rbx),%rax mov (%r15),%rcx jmp *%rax jmp *%rcx
gforth-itc provides pure indirect-threaded code, for running
code that relies on its properties. For good measure, it provides all
the debugging benefits of the gforth engine, and inherits
all of gforth’s debugging advantages as well as performance
disadvantages. Moreover, it disables all other optimizations. It
disables dynamic native-code generation, because each primitive is
invoked through its code field, so there is no way to have several
instances of the primitive with different code addresses. And it uses
the classic indirect-threaded code compiler , instead of the
intelligent compile,, so literal-based optimizations do not
work, either. Note that the code coming from gforth.fi has not
been compiled with ,, but code that you compile after loading
the image uses ,.