Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #134959
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: locals |
| Date | 2026-04-25 06:43 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2026Apr25.084323@mips.complang.tuwien.ac.at> (permalink) |
| References | (4 earlier) <nnd$4d4782db$73d0020c@69cc4648be712fe3> <69db0856$1@news.ausics.net> <871pg66epy.fsf@nightsong.com> <2026Apr25.064712@mips.complang.tuwien.ac.at> <87o6j74l1z.fsf@nightsong.com> |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> With competent Forth compilers, the machine code is 1) the same when
>> using stack operations, when using the return stack, or when using
>> locals
>
>"Competent Forth compilers" there describes what by Forth standards
>would be called quite fancy optimizing compilers ("analytic compilers").
>They are a significant technical feat and there aren't that many of
>them. Traditionally Forth has been implemented as simple interpreters.
And traditionally Forth has been implemented without locals, for the
same reason: It takes less memory and, for the system implementor,
less work; on current non-tiny machines, the latter aspect still
exists, and IMO is a big motivation for anti-locals advocacy (i.e., a
sour-grapes argument).
It's a bit perverse: You argue for locals with simple implementations,
while anti-locals advocates argue against locals with simple
implementations.
And because it's more work, there are fewer sophisticated than simple
systems. But who cares how many there are? The question is what
programmers and users use and what their goals are.
In any case, when it comes to performance measurements on "simple
interpreters" like the Gforth of 1994, Forth code with locals usually
turns out to be slower and consume more memory than Forth code using
(and trying to avoid) stack juggling. E.g., my paper [ertl94l]
contains the following comparison:
locals
with without ratio
max 3.56us 2.69us 1.32
strcmp 83.20us 70.50us 1.18
Numbers from a 486DX2/66, strcmp compares a string with 17 characters
with itself.
The explanation given is:
|The slowdown factor of using locals is due to the execution of more
|primitives (e.g., 14 instead of 12 per character in
|"strcmp"). Originally there was also a large overhead due to fetching
|inline arguments, resulting in slowdowns of 1.58 for "max" and 1.41
|for "strcmp". This overhead has been eliminated mostly by using
|versions of the primitives specialized for frequent inline arguments
|(e.g., "8lp+!" as specialization of "lp+!#" with the inline
|argument 8).
@InProceedings{ertl94l,
author = "M. Anton Ertl",
title = "Automatic Scoping of Local Variables",
booktitle = "EuroForth~'94 Conference Proceedings",
year = "1994",
address = "Winchester, UK",
pages = "31--37",
url = "https://www.complang.tuwien.ac.at/papers/ertl94l.ps.gz",
abstract = "In the process of lifting the restrictions on using
locals in Forth, an interesting problem poses
itself: What does it mean if a local is defined in a
control structure? Where is the local visible? Since
the user can create every possible control structure
in ANS Forth, the answer is not as simple as it may
seem. Ideally, the local is visible at a place if
the control flow {\em must} pass through the
definition of the local to reach this place. This
paper discusses locals in general, the visibility
problem, its solution, the consequences and the
implementation as well as related programming style
questions."
}
It might be interesting to measure this again on current hardware with
the current, somewhat more sophisticated, but not yet "competent"
Gforth, and maybe I will, at some other time. However, looking at the
code for Gforth for 3DUP.3 compared to the ohers, Gforth still uses
more primitives (even with superinstructions) and more machine
instructions; From <2025Oct2.224440@mips.complang.tuwien.ac.at>:
: 3dup.1 ( a b c -- a b c a b c ) >r 2dup r@ -rot r> ;
: 3dup.2 ( a b c -- a b c a b c ) 2 pick 2 pick 2 pick ;
: 3dup.3 {: a b c :} a b c a b c ;
: 3dup.4 ( a b c -- a b c a b c ) dup 2over rot ;
And here's the gforth-fast code on AMD64:
3dup.1 3dup.2 3dup.3 3dup.4
>r 1->0 third 1->2 >l >l 1->1 dup 1->1
mov -$08[r14],r13 mov r15,$10[r10] >l 1->1 mov [r10],r13
sub r14,$08 third 2->3 mov -$08[rbp],r13 sub r10,$08
2dup 0->2 mov r9,$08[r10] mov rdx,$08[r10] 2over 1->3
mov r13,$10[r10] third 3->1 mov rax,rbp mov r15,$18[r10
mov r15,$08[r10] mov [r10],r13 add r10,$10 mov r9,$10[r10]
i 2->3 sub r10,$18 lea rbp,-$10[rbp] rot 3->1
mov r9,[r14] mov $10[r10],r15 mov -$10[rax],rdx mov [r10],r15
-rot 3->2 mov $08[r10],r9 mov r13,[r10] sub r10,$10
mov [r10],r9 ;s 1->1 >l @local0 1->1 mov $08[r10],r9
sub r10,$08 mov rbx,[r14] @local0 1->1 ;s 1->1
r> 2->1 add r14,$08 mov rax,rbp mov rbx,[r14]
mov -$08[r10],r15 mov rax,[rbx] lea rbp,-$08[rbp] add r14,$08
sub r10,$10 jmp eax mov -$08[rax],r13 mov rax,[rbx]
mov $10[r10],r13 @local1 1->2 jmp eax
mov r13,[r14] mov r15,$08[rbp]
add r14,$08 @local2 2->1
;s 1->1 mov -$08[r10],r15
mov rbx,[r14] sub r10,$10
add r14,$08 mov $10[r10],r13
mov rax,[rbx] mov r13,$10[rbp]
jmp eax @local0 1->2
mov r15,$00[rbp]
@local1 2->3
mov r9,$08[rbp]
@local2 3->1
mov -$10[r10],r9
sub r10,$18
mov $10[r10],r15
mov $18[r10],r13
mov r13,$10[rbp]
lit 1->2
#24
mov r15,$50[rbx]
lp+! 2->1
add rbp,r15
;s 1->1
mov rbx,[r14]
add r14,$08
mov rax,[rbx]
jmp eax
[Note that for a superinstruction like ">l >l" or ">l @local0", all
threaded code cells are shown, the first as superinstruction, and the
remaining ones as the simple primitive in that threaded-code slot; but
the other threaded-code slots have no separate code generated.]
You seem to argue that the random-access aspect of locals provides a
performance advantage on simple systems, but in most cases, code using
locals is at a performance disadvantage on such systems (and
traditionalists have often used that to argue against locals).
>In that case, a pure stack VM seems to ignore capabilities of the
>underlying hardware. Particularly, the the stack's memory actually
>being RAM.
Keeping at least one stack item in a register leads to a smaller and
faster implementation, and is not more complex than keeping all the
stack memory in RAM. It does require enough registers, however (i.e.,
you do not use this technique on the 6502).
>Doesn't PICK go back to the earliest days of Forth, as a way
>to bypass the limitation?
A way to use RAM that is less frowned upon by Forth traditionalists is
(global) variables. The fact that the use of global variables is
frowned upon in the wider programming community for various reasons
seems to pour oil into the fire of their elitism.
- anton
--
M. Anton Ertl http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
New standard: https://forth-standard.org/
EuroForth 2025 proceedings: http://www.euroforth.org/ef25/papers/
Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar
Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-05 23:25 +0100
Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-05 23:30 +0100
Re: Coroutines in Forth Paul Rubin <no.email@nospam.invalid> - 2026-04-05 17:16 -0700
Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-06 19:58 +0100
Re: Coroutines in Forth Paul Rubin <no.email@nospam.invalid> - 2026-04-22 11:13 -0700
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-22 22:05 +0200
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-07 13:23 +0200
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-06 13:51 +0200
Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-06 22:20 +0100
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-07 13:35 +0200
Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-07 20:55 +0100
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-08 12:34 +0200
Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-08 12:32 +0100
Re: Coroutines in Forth Stephen Pelc <stephen@vfxforth.com> - 2026-04-09 10:12 +0000
Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-10 19:01 +0200
Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-11 11:54 +1000
Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-05-01 13:07 +0200
Re: Coroutines in Forth peter <peter.noreply@tin.it> - 2026-04-11 09:49 +0200
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-11 22:03 +0200
Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-12 12:49 +1000
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-12 12:13 +0200
Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-12 17:39 +0200
Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-13 10:54 +1000
Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-13 19:24 +0200
Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-12 13:48 +0200
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-13 12:13 +0200
Re: Coroutines in Forth Paul Rubin <no.email@nospam.invalid> - 2026-04-22 11:18 -0700
Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-23 11:13 +1000
Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-23 12:37 +0200
Re: Coroutines in Forth Paul Rubin <no.email@nospam.invalid> - 2026-04-24 10:36 -0700
Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-25 12:12 +1000
Re: Coroutines in Forth Paul Rubin <no.email@nospam.invalid> - 2026-04-24 23:31 -0700
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-25 10:45 +0200
Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-25 22:06 +1000
Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-25 15:11 +0200
Re: Coroutines in Forth dxf <dxforth@gmail.com> - 2026-04-26 13:33 +1000
Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-26 16:28 +0200
Re: Coroutines in Forth Paul Rubin <no.email@nospam.invalid> - 2026-04-25 21:46 -0700
FP stack depth limitations (was: Coroutines in Forth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-26 05:55 +0000
Re: FP stack depth limitations Paul Rubin <no.email@nospam.invalid> - 2026-04-26 00:28 -0700
Re: FP stack depth limitations dxf <dxforth@gmail.com> - 2026-04-26 19:55 +1000
Re: FP stack depth limitations (was: Coroutines in Forth) peter <peter.noreply@tin.it> - 2026-04-26 09:57 +0200
Re: FP stack depth limitations (was: Coroutines in Forth) albert@spenarnc.xs4all.nl - 2026-04-26 14:34 +0200
Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-25 15:01 +0200
Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-05-01 13:13 +0200
Forth, C, hardware, and programming virtues (was: Coroutines in Forth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-25 05:26 +0000
Re: Forth, C, hardware, and programming virtues Paul Rubin <no.email@nospam.invalid> - 2026-04-24 23:55 -0700
Re: Forth, C, hardware, and programming virtues anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-25 08:21 +0000
Re: Forth, C, hardware, and programming virtues albert@spenarnc.xs4all.nl - 2026-04-25 11:27 +0200
Re: Forth, C, hardware, and programming virtues Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-25 15:43 +0200
Re: Forth, C, hardware, and programming virtues anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-25 17:21 +0000
Re: Forth, C, hardware, and programming virtues dxf <dxforth@gmail.com> - 2026-04-26 15:21 +1000
Re: Forth, C, hardware, and programming virtues Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-26 15:08 +0200
Re: Forth, C, hardware, and programming virtues albert@spenarnc.xs4all.nl - 2026-04-26 00:34 +0200
Re: Forth, C, hardware, and programming virtues Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-26 15:10 +0200
locals (was: Coroutines in Forth) anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-25 04:47 +0000
Re: locals Paul Rubin <no.email@nospam.invalid> - 2026-04-24 23:21 -0700
Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-25 06:43 +0000
Re: locals albert@spenarnc.xs4all.nl - 2026-04-25 11:43 +0200
Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-25 10:22 +0000
Re: locals peter <peter.noreply@tin.it> - 2026-04-25 16:07 +0200
Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-25 17:38 +0200
Re: locals albert@spenarnc.xs4all.nl - 2026-04-26 01:13 +0200
Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-26 14:03 +0000
Re: locals peter <peter.noreply@tin.it> - 2026-04-27 09:31 +0200
Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-27 07:53 +0000
Re: locals peter <peter.noreply@tin.it> - 2026-04-27 11:52 +0200
Re: locals albert@spenarnc.xs4all.nl - 2026-04-26 00:51 +0200
Re: locals Paul Rubin <no.email@nospam.invalid> - 2026-04-25 22:40 -0700
Re: locals albert@spenarnc.xs4all.nl - 2026-04-26 14:55 +0200
Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-26 09:50 +0000
Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-26 16:22 +0200
Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-26 17:04 +0000
Re: locals dxf <dxforth@gmail.com> - 2026-04-27 11:51 +1000
Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-28 08:21 +0200
Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-28 08:22 +0200
Re: locals dxf <dxforth@gmail.com> - 2026-04-27 11:12 +1000
Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-28 14:34 +0200
Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-28 14:34 +0200
Re: locals Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-29 12:44 +0100
Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-29 14:37 +0200
Re: locals Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-29 14:44 +0200
Re: locals Paul Rubin <no.email@nospam.invalid> - 2026-05-01 23:50 -0700
Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-02 10:34 +0000
Re: locals Paul Rubin <no.email@nospam.invalid> - 2026-05-01 23:54 -0700
Re: locals dxf <dxforth@gmail.com> - 2026-05-02 17:36 +1000
Re: locals Paul Rubin <no.email@nospam.invalid> - 2026-05-02 01:11 -0700
Re: locals anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-05-02 15:58 +0000
Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-07 09:28 -0500
Re: Coroutines in Forth anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2026-04-07 16:12 +0000
Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-07 18:06 -0500
Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-08 11:43 +0100
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-08 13:16 +0200
Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-08 11:47 -0500
Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-08 21:48 +0100
Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-09 07:06 -0500
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-09 16:41 +0200
Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-09 13:34 -0500
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-10 01:23 +0200
Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-09 21:34 -0500
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-09 13:01 +0200
Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-09 07:01 -0500
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-09 16:10 +0200
Re: Coroutines in Forth Krishna Myneni <krishna.myneni@ccreweb.org> - 2026-04-09 13:29 -0500
Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-08 21:26 +0100
Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-08 14:22 +0200
Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-28 15:31 +0200
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-29 10:49 +0200
Re: Coroutines in Forth Hans Bezemer <the.beez.speaks@gmail.com> - 2026-04-29 15:22 +0200
Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-08 11:33 +0100
Re: Coroutines in Forth albert@spenarnc.xs4all.nl - 2026-04-08 13:07 +0200
Re: Coroutines in Forth Gerry Jackson <do-not-use@swldwa.uk> - 2026-04-08 22:05 +0100
csiph-web