ADDRESSABLE: value-flavoured words

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/