Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.forth > #135053
| From | anton@mips.complang.tuwien.ac.at (Anton Ertl) |
|---|---|
| Newsgroups | comp.lang.forth |
| Subject | Re: locals |
| Date | 2026-05-02 10:34 +0000 |
| Organization | Institut fuer Computersprachen, Technische Universitaet Wien |
| Message-ID | <2026May2.123429@mips.complang.tuwien.ac.at> (permalink) |
| References | (8 earlier) <87o6j74l1z.fsf@nightsong.com> <2026Apr25.084323@mips.complang.tuwien.ac.at> <87340i46vi.fsf@nightsong.com> <2026Apr26.115059@mips.complang.tuwien.ac.at> <87pl3e2tlv.fsf@nightsong.com> |
Paul Rubin <no.email@nospam.invalid> writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
[...]
>I wonder if gforth would get less code bloat if you added some
>primitives for pushing more than one local. E.g. 2>L, 3>L, etc. would
>push that many stack elements to LOCAL0, LOCAL1, LOCAL2. Then there
>wouldn't be that big chunk of replicated code.
Gforth has superinstructions for the sequences
sequence count AMD64 code gforth-fast
>l >l 62 len= 4+ 26+ 3
>l >l >l 9 len= 4+ 34+ 3
>l >l >l >l 5 len= 4+ 42+ 3
f>l f>l 2 len= 4+ 42+ 3
>l @local0 20 len= 4+ 11+ 3
f>l lit f@localn 1 len= 4+ 24+ 3
compared to
primitive count AMD64 code gforth-fast
>l 67 len= 4+ 18+ 3
f>l 10 len= 4+ 23+ 3
The counts are static occurences of the code for this primitive, i.e.,
if for a sequence >l >l the superinstruction is selected, the
superinstruction's count is increase, while the count of >l stays the
same. The whole data is for gforth-fast with disabled static stack
caching. With static stack caching enabled, there are more variants
of >l that the counts distribute over.
As far as native code is concerned, these superinstructions already
give the benefit of the additional primitives you suggest. On the
threaded-code side there is a threaded-code slot for each >L. That
simplifies the implementation of superinstructions: no need to
rearrange the threaded code when the decision about the use of
superinstructions is taken.
We could add some special mechanism to the locals implementation that
produces 2>L etc. instead of just producing a sequence of >Ls, and
letting the ordinary superinstruction mechanism in Gforth combine
them. But would such a mechanism cost less in code size than the
62+9*2+5*3=95 cells that it saves? Not to mention the development and
maintenance effort.
While we are at it, here are the other locals-related primitives:
primitive count AMD64 code gforth-fast
@localn 1 len= 4+ 5+ 3
@local0 115 len= 4+ 11+ 3
@local1 87 len= 4+ 11+ 3
@local2 62 len= 4+ 11+ 3
@local3 31 len= 4+ 11+ 3
@local4 18 len= 4+ 11+ 3
@local5 16 len= 4+ 11+ 3
@local6 10 len= 4+ 11+ 3
@local7 4 len= 4+ 11+ 3
!localn 0 len= 4+ 16+ 3
!local0 4 len= 4+ 11+ 3
!local1 1 len= 4+ 11+ 3
!local2 4 len= 4+ 11+ 3
!local3 2 len= 4+ 11+ 3
!local4 0 len= 4+ 11+ 3
!local5 0 len= 4+ 11+ 3
!local6 0 len= 4+ 11+ 3
!local7 0 len= 4+ 11+ 3
+!localn 3 len= 4+ 16+ 3
lp+n 82 len= 4+ 3+ 3
f@localn 11 len= 4+ 24+ 3
lp@ 14 len= 4+ 10+ 3
lp+! 67 len= 4+ 10+ 3
lp- 3 len= 4+ 4+ 3
lp+ 36 len= 4+ 4+ 3
lp+2 33 len= 4+ 4+ 3
lp! 12 len= 4+ 10+ 3
>> Even with multi-representation stack-caching as used since Gforth 0.7
>> (which does require more compiler smarts), no statically determined
>> stack effect is necessary, because the code generator returns to the
>> canonical state on control-flow.
>
>I see, yeah, but that means stack juggling to get to the canonical
>state.
In clf, "Stack juggling" usually means using words like ROT (see the
cartoon about ROT in starting Forth). That's not what happens here.
What happens is that there is code that performs a transition between
stack representations. Between any two primitives, as well as at the
start and end of a sequence, the code generator can insert such code.
It uses a shortest-path algorithm to find the shortest native-code
sequence for the threaded-code sequence. The result is never longer
than the native-code sequence that you get when you always use the
implementation of the primitive that starts in the canonical
representation and ends in the canonical representation, and it often
is shorter.
Here is the usage of the transitions between the stack representations
on AMD64 for the gforth.fi image:
trans count AMD64 code gforth-fast
1-0 2932 len= 0+ 7+ 3
2-0 944 len= 0+ 12+ 3
3-0 135 len= 0+ 16+ 3
0-1 152 len= 0+ 8+ 3
2-1 87 len= 0+ 10+ 3
3-1 35 len= 0+ 14+ 3
0-2 39 len= 0+ 12+ 3
1-2 151 len= 0+ 10+ 3
3-2 0 len= 0+ 13+ 3
0-3 15 len= 0+ 15+ 3
1-3 48 len= 0+ 15+ 3
2-3 5 len= 0+ 13+ 3
The transition is shown as M-N, where M is the number of stack items
in registers before the transition and N is the number of stack items
in registers after the transition. The high number of transitions
with N=0 is interesting, given that the canonical representation is 1.
My impression is, that for a primitive that pushes a value, such as
lit, r@ or @local0, the code generator selects the transition to 0
followed by the 0-1 variant of the primitive over the 1-1 variant of
the primitive when the code size is the same.
>> ... we have user variables like BASE and HLD (in F83, HOLDPTR in
>> gforth). They are used across multiple words, and the fact that you
>> don't have to pass them and put them into a local has been touted as
>> an advantage over locals: Definitions that use global variables are
>> easier to factor.
>
>Urgggh...
When that is combined with proper wrapping, it can be a useful
mechanism. E.g., environment variables in shell scripts work that
way, or the graphics state in Postscript. But it's something that
needs a lot of restraint to avoid creating a mess. Hanson and
Proebsting presented a case (and efficient implementation) for this
kind of mechanism:
@InProceedings{hanson&proebsting01,
author = {David. R. Hanson and Todd A. Proebsting},
title = {Dynamic Variables},
crossref = {sigplan01},
pages = {264--273},
annote = {}
}
@Proceedings{sigplan01,
booktitle = "SIGPLAN '01 Conference on Programming Language
Design and Implementation",
title = "SIGPLAN '01 Conference on Programming Language
Design and Implementation",
year = "2001",
key = "PLDI '01"
}
- 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