Sujet : Re: Avoid treating the stack as an array [Re: "Back & Forth" is back!]
De : no.email (at) *nospam* nospam.invalid (Paul Rubin)
Groupes : comp.lang.forthDate : 18. Sep 2024, 21:10:31
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <87zfo4zps8.fsf@nightsong.com>
References : 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
dxf <
dxforth@gmail.com> writes:
I think we're retreading old ground. Orders of 30% reduction in code
size were in respect of optimizing compilers (VFX).
That 30% difference was because VFX doesn't attempt to optimize locals.
If two pieces of code are obviously equivalent (the locals and no-locals
version of EMITS) then a fancier optimizing compiler is likely to
generate the same code for both.
What I was getting at though is that VFX even using locals will still
beat the pants off any interpreter, even without locals. So if you have
interpreted Forth code using locals and want it to be faster, you get
far more gain compiling it with VFX than you would get by undoing the
locals. If you're already using VFX then yes, you can squeeze out a bit
more performance by not using locals, but that just tells me that the
VFX optimizer is still a work in progress (which is fine).
I can assure you I don't find using stack operators a burden. Indeed
I find them reassuring as it puts me in control.
It's hard for me to understand that. If you're using VFX, the stack
operations are transformed by compiler gyrations to register ops so
SWAP, ROT, etc. generate no code at all, but this is completely out of
sight and you have no control over it. Locals on the other hand (in an
interpreter) are equivalent to RPICK at specific offsets in obvious
ways, so there is no loss of control. That also happens with locals in
VFX but it's only because VFX (for now) hasn't pursued optimizing them.
That example using FVALUE just seems to be a loss: the storage cells are
constantly tied up even when not active. If that function can be used
in a multitasking environment, you might even need a separate copy for
each task. Significant efficiency loss.
Forth is a niche language. If there's success to be had, it will be
on its own merits and not ideas imported from other languages.
That seems to support looking at any particular feature on its merits.
Adding to that a dislike of standardization, it would seem to be up to
the programmer, with most choices being legitmate for any particular
programmer.