Digest #143 2021-04-19
Contributions
Problem statement
ALLOT assumes that the data space for mutable data and for compiled code is one and the same. This is a problem for ROMable systems (i.e. the dictionary is compiled to ROM).
Examples:
The compilation semantic of CREATE doesn't indicate whether "data space" should be mutable or not. The problem could potentially be solved by ALLOT (usage of which implies that data should be mutable).
Data Space is mutable
\ define a standard variable
VARIABLE x
\ create an array
CREATE array 10 ALLOT
:
#### Data Space is immutable:
\ the 10 first prime numbers CREATE primes 2 , 3 , 5 , 7, 11 , 13 , 17 , 19 , 23 , 29 ,
\ defining word for a table based interpolation using @inter : INTER ( u[x y] u "<spaces>name" -- ) CREATE DUP , 0 DO SWAP , , LOOP DOES> @inter ;
### Discussion
The problem of defining the intent of memory allotment could potentially be solved by `ALLOT` (assuming that it indicates that data should be mutable). This is, however, not compliant with the standard definition of that word. In fact the test defined in `ALLOT` (which is normative, I suppose) is based with the assumption that the dictionary is in RAM:
HERE 1 ALLOT HERE CONSTANT 2NDA CONSTANT 1STA T{ 1STA 2NDA U< -> <TRUE> }T \ HERE MUST GROW WITH ALLOT T{ 1STA 1+ -> 2NDA }T \ ... BY ONE ADDRESS UNIT ( MISSING TEST: NEGATIVE ALLOT )
It's also possible to use `VARIABLE` to indicate the intent of a data space allotment:
\ define a mutable array with 10 chars VARIABLE carray 4 CELLS ALLOT
This idiomatic definition of mutable arrays appears not to be precluded by the tests in the standard:
T{ VARIABLE V1 -> }T T{ 123 V1 ! -> }T T{ V1 @ -> 123 }T
```
FlashForth uses data space prefixes (i.e. ram, eeprom) to solve the problem. This requires, however, to first amend any source code, including code from a packet repository.
The solution in STM8 eForth is to use the (known) compilation target semantics of the Forth system (i.e. RAM or NVM for "Non Volatile Memory") to compile to ROM or to RAM (executable data space), ALLOT memory beneath the code or in a RAM block reserved for mutable data , and to compile a matching run-time word (either dovar or dovarptr).
To sum it up:
- the tests given in
ALLOTassume an implementation that's not ROMable - in ROMable systems "data space" is ambiguous with respect to use cases of
CREATE - there is a potential to infer the intended properties of the data space from the idiomatic use which might be used to write portable code
It's of course also possible to define ROMable systems as out-of-scope for a Forth Standard (and maybe in the scope of a different standard?).
Clarification or guidance is highly appreciated.
Replies
comment - Note incompatability (double v single) with some older Forth's.
Doubles always use two cells. E.g., on a system with 64-bit cells, a double is 128 bits wide; an ud is in the range 0..2^128-1, a 2s-complement d in the range -2^127..2^127-1.
Problem statement
ALLOT assumes that the data space for mutable data and for compiled code is one and the same. This is a problem for ROMable systems (i.e. the dictionary is compiled to ROM).
Examples:
The compilation semantic of CREATE doesn't indicate whether "data space" should be mutable or not. The problem could potentially be solved by ALLOT (usage of which implies that data should be mutable).
Data Space is mutable
\ define a standard variable
VARIABLE x
\ create an array
CREATE array 10 ALLOT
:
Data Space is immutable:
\ the 10 first prime numbers
CREATE primes 2 , 3 , 5 , 7, 11 , 13 , 17 , 19 , 23 , 29 ,
\ defining word for a table based interpolation using @inter
: INTER ( u[x y] u "\<spaces\>name" -- ) CREATE DUP , 0 DO SWAP , , LOOP DOES> @inter ;
Discussion
The problem of defining the intent of memory allotment could potentially be solved by ALLOT (assuming that it indicates that data should be mutable). This is, however, not compliant with the standard definition of that word. In fact the test defined in ALLOT (which is normative, I suppose) is based with the assumption that the dictionary is in RAM:
HERE 1 ALLOT
HERE
CONSTANT 2NDA
CONSTANT 1STA
T{ 1STA 2NDA U< -> \<TRUE\> }T \ HERE MUST GROW WITH ALLOT
T{ 1STA 1+ -> 2NDA }T \ ... BY ONE ADDRESS UNIT
( MISSING TEST: NEGATIVE ALLOT )
It's also possible to use VARIABLE to indicate the intent of a data space allotment:
\ define a mutable array with 10 chars
VARIABLE carray 4 CELLS ALLOT
This idiomatic definition of mutable arrays appears not to be precluded by the tests in the standard:
T{ VARIABLE V1 -> }T
T{ 123 V1 ! -> }T
T{ V1 @ -> 123 }T
FlashForth uses data space prefixes (i.e. ram, eeprom) to solve the problem. This requires, however, to first amend any source code, including code from a packet repository.
The solution in STM8 eForth is to use the (known) compilation target semantics of the Forth system (i.e. RAM or NVM for "Non Volatile Memory") to compile to ROM or to RAM (executable data space), ALLOT memory beneath the code or in a RAM block reserved for mutable data , and to compile a matching run-time word (either dovar or dovarptr).
To sum it up:
- the tests given in
ALLOTassume an implementation that's not ROMable - in ROMable systems "data space" is ambiguous with respect to use cases of
CREATE - there is a potential to infer the intended properties of the data space from the idiomatic use which might be used to write portable code
It's of course also possible to define ROMable systems as out-of-scope for a Forth Standard (and maybe in the scope of a different standard?).
Clarification or guidance is highly appreciated.
A problem with this version is that it doesn't allow to return the different xt between interpretation and compilation state for words with default interpretation semantics, while the original intention was that it's allowed. See also: news:2020Oct24.191314@mips.complang.tuwien.ac.at.
Author
Ruv
Change Log
2019-10-08: Initial version
2020-08-28: Avoid ambiguous clause "xt is the execution token for name" in the case of a word with non default interpretation semantics.
2021-04-18: Allow to return the different xt for any definition. More tight meaning of n in interpretation state. Avoid "implementation-dependent definition" and make the wording simpler.
Problem
The descriptions of the problem and solution are the same as in the previous version
Proposal
Replace the text in the specification of FIND with the following.
FIND
( c-addr -- c-addr 0 | xt n )
Find the definition name whose name matches the counted string at c-addr. If the definition is not found, return c-addr and zero.
Otherwise, return xt and n, where xt is an execution token and n is -1 or 1. The returned values may differ between interpretation and compilation state, and the following conditions shell be met:
- if the definition is found in interpretation state, then
- if and only if name is immediate, n is
1, otherwise n is-1; - if name has default interpretation semantics, xt indetifies the execution semantics for name;
- performing xt in interpretation state performs the interpretation semantics for name;
- if and only if name is immediate, n is
- if the definition is found in compilation state, then
- if n is
1, performing xt in compilation state performs the compilation semantics for name; - if n is
-1, appending the execution semantics identified by xt to the current definition performs the compilation semantics for name.
- if n is
A definition may be found in compilation state but not found in interpretation state (or vise versa).
"Performing xt" means performing the execution semantics identified by the execution token xt.
A definition has default interpretation semantics if and only if the "Interpretation:" section is absent in the corresponding glossary entry (see 3.4.3.2).
If interpretation semantics are undefined for a definition, a Forth system is allowed to provide implementation-defined interpretation semantics for this definition (see A.3.4.3.2). In such case, when the definition is found in interpretation state, performing the returned xt in interpretation state performs the implementation-defined interpretation semantics for name.
If immediacy is not specified for a definition with non default interpretation semantics, a Forth system is still allowed to implement this definition as an immediate word by providing implementation-dependent execution semantics for this definition (see A.6.1.2033, A.6.1.1550).