,---------------. | Contributions | `---------------´ ,------------------------------------------ | 2021-04-18 09:07:57 TG9541 wrote: | requestClarification - ALLOT in ROMable systems | see: https://forth-standard.org/standard/core/ALLOT#contribution-190 `------------------------------------------ ### 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 "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< -> }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](https://www.flashforth.com/) 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](http://theforth.net/). The solution in [STM8 eForth](https://github.com/TG9541/stm8ef) 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 `ALLOT` assume 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 | `---------´ ,------------------------------------------ | 2021-04-18 08:23:54 AntonErtl replies: | comment - Note incompatability (double v single) with some older Forth's. | see: https://forth-standard.org/standard/core/num#reply-648 `------------------------------------------ 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. ,------------------------------------------ | 2021-04-18 10:10:31 TG9541 replies: | requestClarification - ALLOT in ROMable systems | see: https://forth-standard.org/standard/core/ALLOT#reply-649 `------------------------------------------ ### 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 "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< -> }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](https://www.flashforth.com/) 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](http://theforth.net/). The solution in [STM8 eForth](https://github.com/TG9541/stm8ef) 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 `ALLOT` assume 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. ,------------------------------------------ | 2021-04-18 15:43:13 ruv replies: | proposal - Clarify FIND, more classic approach | see: https://forth-standard.org/proposals/clarify-find-more-classic-approach#reply-650 `------------------------------------------ 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](http://al.howardknight.net/?ID=160655595900). ,------------------------------------------ | 2021-04-18 16:04:18 ruv replies: | proposal - Clarify FIND, more classic approach | see: https://forth-standard.org/proposals/clarify-find-more-classic-approach#reply-651 `------------------------------------------ ## 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](/proposals/clarify-find-more-classic-approach?hideDiff#reply-433) ## 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 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_. 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](https://forth-standard.org/standard/usage#subsubsection.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](https://forth-standard.org/standard/rationale#paragraph.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](https://forth-standard.org/standard/rationale#rat:core:POSTPONE), [A.6.1.1550](https://forth-standard.org/standard/rationale#rat:core:FIND)).