Compiling rewritten Tachyon Forth kernel on C vs Spin?
Peter Jakacki
Posts: 10,193
As you know the very kernel of Tachyon Forth is initially compiled through the Spin compiler and I use BST because it generates a listing that I can use to make sure things are where they need to be and compiled as I expect them to be. But Spin is not very friendly towards compiling kernels of this nature and what I really wanted was just a macroassembler.. But I notice these C compilers, perhaps even Catalina (which I'm playing with) and I got to wondering if it might be better to rewrite the kernel so that it could compile in one of these and perhaps also craft some hooks to access library functions etc. I would still have the cog kernel functions written in PASM though as they need to be super-optimized.
Would any of you C gurus be able to comment on the feasibility of this approach?
Would any of you C gurus be able to comment on the feasibility of this approach?
Comments
The Assembler part of GCC is a macro Assembler...,
http://203.64.187.42/99-B/GAS-MACRO/GAS-Macro-Note.htm
and GCC can create small code pieces, as COG native. (ie PASM)
That should also move to P2 with relative ease.
Converting code from Spin to C is usually not too difficult -- the languages are quite similar. In fact there's an automated tool (spin2cpp) that can do much of the work for you.
You should certainly see a performance improvement in the non-PASM portions of your code. The tradeoff is that C code usually takes more space. There's a continuum of performance/size tradeoffs available; Spin is the smallest, slowest code, CMM (compressed memory model) C gives more performance with bigger code, and LMM C gives the fastest performance but with the biggest code. (CMM is implemented with a byte-code interpreter, LMM loads individual PASM instructions into COG memory and executes them one at a time. PropGCC also supports loading small loops and functions into COG memory and executing them as a whole, which the compiler can do automatically.)
I think PropGCC would be a good choice for implementing Tachyon Forth, since they both share an emphasis on high performance. I am biased though :-).
As jmg mentioned, a macro assembler comes with PropGCC. The syntax is slightly different from PASM -- the most recent PropGCC version has a .pasm directive that makes GAS much more PASM compatible, so you may want to get that if you're doing a lot of PASM programming in GAS.
Are suggesting a utility that would compile Forth code into Spin DAT code? It would take something like this and compile it into this.
' : here dp @ ; here_L word @cmove_L+Q byte FLAG_DEF, 4, "here" long here_X word execlistfunc, 0 word @dp_X+Q, @fetch_X+Q, 0 long ' : allot dp @ + dp ! ; allot_L word @here_L+Q byte FLAG_DEF, 5, "allot" long allot_X word execlistfunc, 0 word @dp_X+Q, @fetch_X+Q, @plus_X+Q, @dp_X+Q, @store_X+Q, 0 long ' : , here ! 4 allot ; comma_L word @allot_L+Q byte FLAG_DEF, 1, "," long comma_X word execlistfunc, 0 word @here_X+Q, @store_X+Q, @_lit_X+Q, 4, @allot_X+Q, 0 longThat should be fairly easy to write. I've thought about doing that for pfth. It would need to know the dictionary format and the alignment requirements. pfth uses the convention that the label for the starting address has an "_L" suffix, and the label for the XT uses an "_X" suffix. "Q" is the object offset, which is 16 for the top object. I think Tachyon uses "s" for the offset.There would need to be a way to define an alias for words like "," and "@", where "comma" and "fetch" would be used instead.
Dave
EDIT: that's why I wrote on C vs Spin rather than in C vs Spin
I actually like the way you do it now.
PropTool or BST is there anyhow and no additional tools required.
Reading your Tachyon kernel was very helpful &B fun to me in
a) learning PASM
b) understand how Tachyon really works internally
c) even making slight kernel modifications ;-)
Of course it takes a while to be able ro read the precompiled forth -
but then - those are the actual bytes executed and much more readable than:
and having to install a C compiler toolchain to run Tachyon is not s.th. I would like to do.
And just taking the kernel as a fixed prefabed module that I could only use, but not look inside
would take out a lot of the fun it currently is.
Do you expect so many kernel changes, that this is worth it?
P2 Tachyon maybe??
You have started to move code from the kernel out to EXTEND.
I am sure there is some more, that can be moved, so what's left is not very big any more.
Edit: and being able to include SPIN objects is sure a plus as well
I definitely would not make it harder to write or read, it would never be hex and by using a macroassembler instead of writing:
byte ZEQ,_IF,@lab1-lab2
I could instead write:
0=
_IF lab1
as the macros for _IF allow me to use them as a directive or instruction and the macro can calculate the displacement to lab1.
The PASM part should be much the same though. Anyway, just toying with the idea.