From: no.email@nospam.invalid
dxf writes:
> Going back to the EMITS example:
>
> - despite lack of comments you quickly deduced what it did
> - stack operations were few and simple and still you didn't like it
> - your ideal is that every stack operation should go, which is what
> you did
It was the first word in the program that used any stack operations at
all. I saw that it was more concise and imho more readable without
them. Other words there were much harder to read.
> If one takes from forth that which makes it efficient, then one takes away
> its reason for existence. Unfortunately for forth, this is what locals
> users are doing, whether they're aware of it or not.
I'm not persuaded that the stack ops make Forth efficient. Certainly
not as much as advanced compilers do, and yet one of the big attractions
of Forth has been very simple interpreters.
On my x86-64 laptop, gcc -c -S -Os on
void emit(char);
void emits(char c, int n) {
while (n-- > 0) emit(c);
}
gives me 27 bytes, 15 instructions, beating all of the Forth examples.
Several of the 14 instructions seem related to passing parameters in
registers. Passing on the stack like in old fashioned systems would
save a few more, at the expense of some speed. So if I want efficiency,
I should use C.
>> Anyway, if efficiency was important for that example, I'd use CODE.
> In other words forth is not important to you.
I would say efficiency is usually not very important to me, whether in
forth or any other language. It's the usual story of programs having
hot spots. Aim for efficiency in the hot spots and readability and ease
of implementation everywhere else.
Also, you define "forth" as using stack ops instead of locals. I don't
define it that way. Forth with locals is still Forth. They are in the
standard after all.
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
