On 12 May 2025 at 09:40:32 CEST, "Anton Ertl" <Anton Ertl> wrote:

Programmers use value-flavoured words for various reasons. In some
cases they want to have the address of the data otherwise accessed by
calling the value-flavoured word V or by using TO V. Popular systems
have ADDR V or &OF V for taking the address.

However, taking the address of the data means that (in the absence of complicated, expensive, and unreliable alias analysis) any memory
access can access the data, so we are very limited in
register-allocating the data and/or in reordering the accesses to the
data.

VFX Forth and other MPE/W&P Forths have had ADDR for decades.

I think that there two flaws in the argument above
1) The use of ADDR or &OF is quite rare and often specialised,
2) All uses that require ADDR can be satisfied using a buffer.
My use of ADDR has significantly reduced over the last ten years.

I would propose that a more satidfying solution is to add local
buffers, which are decades old in MPE/W&P Forths. MPE uses
a notation that others object to for local buffers, but AFAIR someone
had a good notation and implementation that was published. Here
are two examples of local buffer use. Both are taken from the VFX Forth
kernel and demonstrate convenience for operating system
Interfacing.

Local buffers are defined using a trailing '[' character at the end of
local variable name, e.g.
IOBUFF[ cell ]
followed by the buffer size and a trailing '] '

NXCALLx is a call to a shared library function:
px ... p1 address NXCALLx \ x=#parameters, address = function entry
NXCALL is a low level integer function used before the EXTERN:
interface has been compiled.

\ int chmod(const char *path, mode_t mode);
: (OS_Chmod) { c-addr u mode | zaddr[ #1024 ] -- ior }
c-addr u zaddr[ zplace
zaddr[ mode dll_chmod @ nxcall2
0=
;

: (OS_Key) \ -- key
{ | iobuff[ cell ] -- char }
?PrepTerm
stdin @ iobuff[ 1 dll_ReadFile @ nxcall3 drop
iobuff[ c@
;

All VFX Forth downloads include the source code.

Stephen

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Programmers use value-flavoured words for various reasons. In some
cases they want to have the address of the data otherwise accessed by
calling the value-flavoured word V or by using TO V. Popular systems
have ADDR V or &OF V for taking the address.

However, taking the address of the data means that (in the absence of complicated, expensive, and unreliable alias analysis) any memory
access can access the data, so we are very limited in
register-allocating the data and/or in reordering the accesses to the
data.

We want to avoid imposing such optimization obstacles when not
necessary. Taking the address of data accessed through
value-flavoured words is rare: E.g., in the source of Gforth, there
are 130 uses of TO, but the only use of ADDR is for defining a synonym
(the SwiftForth name &OF), i.e., not to take the address of data.
Therefore we do not want to impose the optimization obstacles on all value-flavoured words by supporting ADDR on all of them.

In the past, we introduced alternative defining words (VARUE etc.) for
defining value-flavoured words that support ADDR. But we now have
around 20 words for defining VALUE-flavoured words that do not support
ADDR, and duplicating them for supporting ADDR seems excessive. So
during the last days we implemented an alternative: If you want to
define a value-flavoured word which you can use with ADDR, you precede
the defining word with ADDRESSABLE:. E.g.,

5 addressable: value foo
7 addr foo +!
foo . \ prints 12

or

: bar {: addressable: x -- y :}
5 addr x +! x ;

As you can see, it's hard to give simple examples for the use of ADDR
that are not contrived.

In the case of the locals definition, the defining word W: for a
cell-sized value-flavoured local is usually implied, and can still be
preceded by ADDRESSABLE:.

Currently Gforth does not perform any optimizations for which ADDR
would be an obstacle, so using ADDR on a non-ADDRESSABLE: word only
produces a warning, but once we implement such optimizations, these
warnings will turn into errors.

- 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 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Stephen Pelc <stephen@vfxforth.com> writes:

On 12 May 2025 at 09:40:32 CEST, "Anton Ertl" <Anton Ertl> wrote:

Programmers use value-flavoured words for various reasons. In some
cases they want to have the address of the data otherwise accessed by
calling the value-flavoured word V or by using TO V. Popular systems
have ADDR V or &OF V for taking the address.

However, taking the address of the data means that (in the absence of
complicated, expensive, and unreliable alias analysis) any memory
access can access the data, so we are very limited in
register-allocating the data and/or in reordering the accesses to the
data.

VFX Forth and other MPE/W&P Forths have had ADDR for decades.

I think that there two flaws in the argument above
1) The use of ADDR or &OF is quite rare and often specialised,
2) All uses that require ADDR can be satisfied using a buffer.
My use of ADDR has significantly reduced over the last ten years.

Sure you can use a variable-flavoured word instead of a
value-flavoured word, and you could do that already before VALUE was
invented (and long before ADDR/&OF was invented). Yet you have
introduced ADDR, SwiftForth has introduced &OF, and despite my
arguments against, Gforth 1.0 will introduce ADDR and &OF. You may be
right that ADDR is not needed, but do you take the consequence and
remove ADDR from VFX?

Looking at SwiftForth, I see that all occurences of &OF have to do
with defining &OF, i.e., there is not a single use of &OF for getting
the address of a piece of data.

In any case, the point of my posting is not to promote ADDR, but to
point out how we can avoid the negative repercussions of the existence
of ADDR for value-flavoured words on which ADDR is actually not used.

I would propose that a more satidfying solution is to add local
buffers, which are decades old in MPE/W&P Forths. MPE uses
a notation that others object to for local buffers, but AFAIR someone
had a good notation and implementation that was published.

Gforth (development) has implemented the MPE syntax for local buffers
for several years:

: foo ( n -- n1 )
{: | n[ cell ] :}
n[ ! 1 n[ +! n[ @ ;
3 foo . \ prints 4

Gforth has also had variable-flavoured locals since 1994. You can
write FOO with a variable-flavoured local as follows:

: foo {: w^ n -- n1 :}
1 n +! n @ ;

Why did you mention local buffers? My guess is that the reason is
that for all value-flavoured words other than locals, every Forth has
a variable-flavoured counterpart, so you pointed out your way of
defining variable-flavoured locals, which completes the set for your
systems. But ADDR/&OF was not just introduced for locals, so on each
system that implements ADDR/&OF somebody thought that telling the
customer to use a variable-flavoured word instead is not good enough.

- 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 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

It's much easier with a recognizer. Locals preceded by a tick
result in their parameter field address on the stack:

FOO {: bar -- bar bar+1 :}
bar 1 ‘bar +! bar ;

--

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Ruvim <ruvim.pinka@gmail.com> writes:

Why does this name end with a colon?
Just `addressable` (without a colon) looks better.

Inside a locals definition {: ... :}, names ending in ":" are
reserved. So, to avoid potential conflicts with existing names in
existing standard code, the word used inside {: ... :} ends in a
colon. And consequently, the word using outside {: ... :} ends in a
colon, too.

: bar {: addressable: x -- y :}
5 addr x +! x ;

This declaration of `x` does not look good regardless of the colon.

I hope this makes you think twice about whether you really need an
addressable value-flavoured local.

- 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 2023 proceedings: http://www.euroforth.org/ef23/papers/
EuroForth 2024 proceedings: http://www.euroforth.org/ef24/papers/

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)