Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.



Oh, 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.


It 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 :)




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: