3 ms·
What I mean by a penalty of threaded code isn't related to whether words are implemented in native code or not. For example: : square dup * ; is going to gene
by vdupras 11mo ago
What I mean by a penalty of threaded code isn't related to whether words are implemented in native code or not. For example:
: square dup * ;
is going to generate a square word that does 2 calls, regardless of whether "dup" and "*" are native words or not.
The equivalent in C:
int square(int x) { return x*x; }
will generate code that contains no call, even if your C compiler is not a very optimized one.
With STC, it becomes possible for an elaborate Forth to inline "dup" and "*", but STC is less popular on the 8-bit architectures you mentioned because it's much less compact.
It's in that context that I mention that threaded code entails a speed tax. It's those 2 calls.
Of course, in your Forth system, you could rewrite "square" in native code to get rid of the penalty, but then it's not threaded code anymore, it's native code.
- cestith 11mo agoOh, yeah. The call overhead specifically isn’t all that onerous though is it? For your example you’re also talking about making a memory copy, and unless you have hardware multiply you’re doing looping addition. Most Forths I’ve dealt with also offer inline assembly as part of a word definition, so I suppose you could do it that way if really desired. I can see what you mean though about the penalty being completely acceptable, because it shouldn’t be super large.
- vdupras 11mo agoIt depends on the weight of the target word. For trivial words like "dup" or "1+", the cost of the call is proportionally pretty big compared to inlining the native code. But all it all, I agree that this tax is far from being a deal breaker. That's why I don't say that in my article :)