Proposal: PLACE +PLACE

CfV - Call for votes

This page is dedicated to discussing this specific proposal

ContributeContributions

UlrichHoffmannavatar of UlrichHoffmann PLACE +PLACEProposal2021-07-30 11:19:29

PLACE +PLACE request for discussion

Standardizing common use

Change History

  • 2020-07-28 revising historical description, correcting typos
  • 2021-07-26 adding history
  • 2021-07-22 initial version

Problem

Traditional Forth represents strings in memory as so called counted strings, a leading count byte giving the length of the string (0 to 255) followed by the characters of string. No character value plays a special role (in contrast to zero-terminated strings where the character NUL terminates the string). The limitation of a single count byte and thus a maximal string length of 255 characters imposes no restriction on a broad range of applications especially in embedded systems. Of course there are applications that require processing longer strings. The programmer should then best use another string representation (such as c-addr len) without the length restriction of counted strings.

The advantage of counted strings is that they are identified by a single cell (the address of the count byte) on the data stack and so help minimizing stack rearrangements.

The Forth-94 and Forth-2012 standards make use of counted strings and specify even core words which use counted string representation such as WORD FIND COUNT.

The Informational Annex of Forth-94 says in A.3.1.3.4 about counted strings

Counted strings remain useful as a way to store strings in memory. This use is not discouraged, but when references to such strings appear on the stack, it is preferable to use the “_c-addr u_” representation. 

What is missing is an easy way to place a sequence of characters into memory using the counted string representation and also appending a sequence of characters to an already existing counted string in memory.

Solution

The Forth community already has a solution for placing strings as counted strings into memory and appending characters to counted strings by means of the words PLACE and +PLACE. PLACE appeared around 1984 e.g. in F83. +PLACE has been proposed by Wil Baden in his Tool Belt Extensions (latest version at [1], also with the name APPEND)[^1]. Since then many systems have adopted PLACE and +PLACE with exactly the same behaviour.

So, we are proposing PLACE and +PLACE here for standardization.

Proposal

Please add the following specifications to the string extension word set.


PLACE STRING EXT

              ( c-addr1 u c-addr2 -- )

Store u as a length character at c-addr2. When character size is smaller than cell size, only the number of low-order bits corresponding to character size are transferred.

If u is greater than zero, copy u consecutive characters from the data space starting at c-addr1 to that starting at c-addr2+1, proceeding character-by-character from lower addresses to higher addresses.

+PLACE "plus place" STRING EXT

              ( c-addr1 u1 c-addr2 -- )

Read the length character at c-addr2 as u2.

Store u1+u2 as a count character at c-addr2. When character size is smaller than cell size, only the number of low-order bits corresponding to character size are transferred.

If u1 is greater than zero, copy u1 consecutive characters from the data

space starting at c-addr1 to that starting at c-addr2+u2+1, proceeding character-by-character from lower addresses to higher addresses.


end of proposal

Rationale

PLACE places the string identified by c-addr1 u as a counted string at c-addr2 managing the length character. Essentially PLACE converts from c-addr len representation to counted string representation.

PLACE complements COUNT which essentially converts counted strings in memory to their c-addr u representations.

+PLACE appends the string identified by c-addr1 u1 to the counted string at c-addr2 (with length u2) managing the updated string length in the length character at c-addr2.

The application must take care of any string overflow situation where the length of the resulting string would exceed the maximal length that can be stored in a length character. Also it has to assure that the memory is available to store the resulting string.

Note, that the proposal adds PLACE and +PLACE to the up to now empty string extensions word set. A compliant Forth system is free to provide or not to provide these words individually. If it chooses to provide them, they must have the above behaviour. Providing the words could be done by making the reference implementation available in source form or by means of an appropriate alias definition of an already provided word.

Typical Use

S" The quick brown"  PAD PLACE  
S"  fox jumps over" PAD +PLACE
S"  the lazy dog." PAD +PLACE

PAD COUNT TYPE  ( The quick brown fox jumps over the lazy dog.)

Reference Implementation

PLACE and +PLACE can be implemented in Forth-94 as follows:

    : PLACE ( c-addr1 u c-addr2 -- )
         2DUP C!  CHAR+ SWAP MOVE ;

    : +PLACE ( c-addr1 u c-addr2 -- )
         DUP COUNT + >R    2DUP C@ + SWAP C!  R> SWAP MOVE ;

Of course systems are expected to provide optimized implementations.

Testing

The following tests assure basic functionality of PLACE and +PLACE \

<strong><code>CREATE buf 64 ALLOT</code></strong>
    T{ S" ABC" buf PLACE  buf COUNT S" ABC" COMPARE -> 0 }T

    T{ S" ABC" buf PLACE  buf C@ -> 3 }T

    T{ S" ABC" buf PLACE  
       S" DEF" buf +PLACE  buf COUNT S" ABCDEF" COMPARE -> 0 }T

Experience

PLACE and +PLACE have been implemented in numerous systems with the proposed functionality. +PLACE is sometimes called APPEND. A non-exhaustive list is:

System PLACE +PLACE
gforth ?? ??
SwiftForth ?? provided as APPEND
VFX Forth ?? provided as APPEND in ToolBelt.fth
Win32Forth ?? ??
4th ?? ??
PFE ?? ??
F-PC ?? ??
F83 ??
volksForth-83 ??
DXForth ??

Discussion

Why standardize PLACE and +PLACE?

Standard programs that deal with counted strings often also make use of PLACE and +PLACE. As these words are not known to be provided by the underlying system the standard program has to bring its own possibly less efficient implementation with it. This can be done with a prelude that uses the above reference implementation.

Note that the typical phrase

[UNDEFINED] PLACE [IF]

    «reference implementation for PLACE»

[THEN]

[UNDEFINED] +PLACE [IF]

    «reference implementation for +PLACE»

[THEN]

is not sufficient as the underlying system might provide PLACE or +PLACE, but with a different behaviour, rendering the rest of the standard program invalid.

If PLACE and +PLACE are standardized, then a compliant system (if it decides to provide them) has to define them with the exact proposed behaviour. The above phrase would be sufficient and standard programs can leverage efficient system provided implementations.

Restriction on the Length of Counted Strings

Forth-94 and Forth-2021 both do not enforce characters to be of byte size so allow for systems with larger character sizes and by this also counted strings with a maximal length that exceeds 255 characters. For this reason both standards use the term “length character” and not “count byte”.

Since then, in 2016 the Forth-200x committee in favour of eliminating ambiguous conditions has decided to require “1 CHARS = 1” thus making systems that have other character sizes than on not compliant to future Forth-200x standards [2][3]. Requesting standard systems to have byte size characters limit counted strings to the known maximal length of 255 characters.

References

[1] “Toolbelt”, Wil Baden/Neil Bawd, http://www.wilbaden.com/neil_bawd/tool2002.txt

[2] http://www.forth200x.org/rfds.html

[3] http://www.forth200x.org/char-is-1.html

Author

Hans Bezemer <thebeez@xs4all.nl>

Ulrich Hoffmann <uho@xlerb.de>

Notes

[^1]: If the reader is aware of the detailed history of +PLACE aka APPEND, the authors would be happy to learn about that.

UlrichHoffmannavatar of UlrichHoffmannNew Version

Hide differences

PLACE +PLACE request for discussion

Standardizing common use

Change History

  • 2020-07-29 improving Markdown formatting
  • 2020-07-28 revising historical description, correcting typos
  • 2021-07-26 adding history
  • 2021-07-22 initial version

Problem

Traditional Forth represents strings in memory as so called counted strings, a leading count byte giving the length of the string (0 to 255) followed by the characters of string. No character value plays a special role (in contrast to zero-terminated strings where the character NUL terminates the string). The limitation of a single count byte and thus a maximal string length of 255 characters imposes no restriction on a broad range of applications especially in embedded systems. Of course there are applications that require processing longer strings. The programmer should then best use another string representation (such as c-addr len) without the length restriction of counted strings.

The advantage of counted strings is that they are identified by a single cell (the address of the count byte) on the data stack and so help minimizing stack rearrangements.

The Forth-94 and Forth-2012 standards make use of counted strings and specify even core words which use counted string representation such as WORD FIND COUNT.

The Informational Annex of Forth-94 says in A.3.1.3.4 about counted strings

Counted strings remain useful as a way to store strings in memory. This use is not discouraged, but when references to such strings appear on the stack, it is preferable to use the “_c-addr u_” representation. 

What is missing is an easy way to place a sequence of characters into memory using the counted string representation and also appending a sequence of characters to an already existing counted string in memory.

Solution

The Forth community already has a solution for placing strings as counted strings into memory and appending characters to counted strings by means of the words PLACE and +PLACE. PLACE appeared around 1984 e.g. in F83. +PLACE has been proposed by Wil Baden in his Tool Belt Extensions (latest version at [1], also with the name APPEND)[^1]. Since then many systems have adopted PLACE and +PLACE with exactly the same behaviour.

So, we are proposing PLACE and +PLACE here for standardization.

Proposal

Please add the following specifications to the string extension word set.


PLACE STRING EXT

              ( c-addr1 u c-addr2 -- )

Store u as a length character at c-addr2. When character size is smaller than cell size, only the number of low-order bits corresponding to character size are transferred.

If u is greater than zero, copy u consecutive characters from the data space starting at c-addr1 to that starting at c-addr2+1, proceeding character-by-character from lower addresses to higher addresses.

+PLACE "plus place" STRING EXT

              ( c-addr1 u1 c-addr2 -- )

Read the length character at c-addr2 as u2.

Store u1+u2 as a count character at c-addr2. When character size is smaller than cell size, only the number of low-order bits corresponding to character size are transferred.

If u1 is greater than zero, copy u1 consecutive characters from the data

space starting at c-addr1 to that starting at c-addr2+u2+1, proceeding character-by-character from lower addresses to higher addresses.


end of proposal

Rationale

PLACE places the string identified by c-addr1 u as a counted string at c-addr2 managing the length character. Essentially PLACE converts from c-addr len representation to counted string representation.

PLACE complements COUNT which essentially converts counted strings in memory to their c-addr u representations.

+PLACE appends the string identified by c-addr1 u1 to the counted string at c-addr2 (with length u2) managing the updated string length in the length character at c-addr2.

The application must take care of any string overflow situation where the length of the resulting string would exceed the maximal length that can be stored in a length character. Also it has to assure that the memory is available to store the resulting string.

Note, that the proposal adds PLACE and +PLACE to the up to now empty string extensions word set. A compliant Forth system is free to provide or not to provide these words individually. If it chooses to provide them, they must have the above behaviour. Providing the words could be done by making the reference implementation available in source form or by means of an appropriate alias definition of an already provided word.

Typical Use

S" The quick brown"  PAD PLACE  
S"  fox jumps over" PAD +PLACE
S"  the lazy dog." PAD +PLACE

PAD COUNT TYPE  ( The quick brown fox jumps over the lazy dog.)

Reference Implementation

PLACE and +PLACE can be implemented in Forth-94 as follows:

    : PLACE ( c-addr1 u c-addr2 -- )
         2DUP C!  CHAR+ SWAP MOVE ;

    : +PLACE ( c-addr1 u c-addr2 -- )
         DUP COUNT + >R    2DUP C@ + SWAP C!  R> SWAP MOVE ;

Of course systems are expected to provide optimized implementations.

Testing

The following tests assure basic functionality of PLACE and +PLACE \

The following tests assure basic functionality of PLACE and +PLACE

<strong><code>CREATE buf 64 ALLOT</code></strong>
    CREATE buf 64 ALLOT
T{ S" ABC" buf PLACE  buf COUNT S" ABC" COMPARE -> 0 }T

T{ S" ABC" buf PLACE  buf C@ -> 3 }T

T{ S" ABC" buf PLACE  
   S" DEF" buf +PLACE  buf COUNT S" ABCDEF" COMPARE -> 0 }T



## Experience

<strong><code>PLACE</code></strong> and <strong><code>+PLACE</code></strong> have been implemented in numerous systems with the proposed functionality. <strong><code>+PLACE</code></strong> is sometimes called <strong><code>APPEND.</code></strong> A non-exhaustive list is:


<table>
  <tr>
   <td>System
   </td>
   <td>PLACE
   </td>
   <td>+PLACE
   </td>
  </tr>
  <tr>
   <td>gforth
   </td>
   <td>??
   </td>
   <td>??
   </td>
  </tr>
  <tr>
   <td>SwiftForth
   </td>
   <td>??
   </td>
   <td>provided as APPEND
   </td>
  </tr>
  <tr>
   <td>VFX Forth
   </td>
   <td>??
   </td>
   <td>provided as APPEND in ToolBelt.fth
   </td>
  </tr>
  <tr>
   <td>Win32Forth
   </td>
   <td>??
   </td>
   <td>??
   </td>
  </tr>
  <tr>
   <td>4th
   </td>
   <td>??
   </td>
   <td>??
   </td>
  </tr>
  <tr>
   <td>PFE
   </td>
   <td>??
   </td>
   <td>??
   </td>
  </tr>
  <tr>
   <td>F-PC
   </td>
   <td>??
   </td>
   <td>??
   </td>
  </tr>
  <tr>
   <td>F83
   </td>
   <td>??
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>volksForth-83
   </td>
   <td>??
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>DXForth
   </td>
   <td>??
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>
   </td>
   <td>
   </td>
   <td>
   </td>
  </tr>
</table>



## Discussion


### <strong>Why standardize <code>PLACE</code> and <code>+PLACE</code>?</strong>

Standard programs that deal with counted strings often also make use of <strong><code>PLACE</code></strong> and <strong><code>+PLACE</code></strong>. As these words are not known to be provided by the underlying system the standard program has to bring its own possibly less efficient implementation with it. This can be done with a prelude that uses the above reference implementation.

Note that the typical phrase

[UNDEFINED] PLACE [IF]

«reference implementation for PLACE»

[THEN]

[UNDEFINED] +PLACE [IF]

«reference implementation for +PLACE»

[THEN]



is not sufficient as the underlying system might provide <strong><code>PLACE</code></strong> or <strong><code>+PLACE,</code></strong> <strong>but with a different behaviour</strong>, rendering the rest of the standard program invalid.

If <strong><code>PLACE</code></strong> and <strong><code>+PLACE</code></strong> are standardized, then a compliant system (if it decides to provide them) has to define them with the exact proposed behaviour. The above phrase would be sufficient and standard programs can leverage efficient system provided implementations.


### **Restriction on the Length of Counted Strings**

Forth-94 and Forth-2021 both do not enforce characters to be of byte size so allow for systems with larger character sizes and by this also counted strings with a maximal length that exceeds 255 characters. For this reason both standards use the term “length character” and not “count byte”.

Since then, in 2016 the Forth-200x committee in favour of eliminating ambiguous conditions has decided to require “1 CHARS = 1” thus making systems that have other character sizes than on not compliant to _future_ Forth-200x standards [2][3]. Requesting standard systems to have byte size characters limit counted strings to the known maximal length of 255 characters.


## References 

[1] “Toolbelt”, Wil Baden/Neil Bawd, [http://www.wilbaden.com/neil_bawd/tool2002.txt](http://www.wilbaden.com/neil_bawd/tool2002.txt)

[2] http://www.forth200x.org/rfds.html

[3] http://www.forth200x.org/char-is-1.html

Author

Authors

Hans Bezemer <thebeez@xs4all.nl>

Ulrich Hoffmann <uho@xlerb.de>

Notes

[^1]: If the reader is aware of the detailed history of +PLACE aka APPEND, the authors would be happy to learn about that.

Formal

StephenPelcavatar of StephenPelc

I support this proposal, but much prefer APPEND to +PLACE.

UlrichHoffmannavatar of UlrichHoffmannNew Version

Hide differences

PLACE +PLACE request for discussion

Standardizing common use

Change History

  • 2021-09-08 remove conditional phrase from PLACE definition following committees comments
  • 2021-09-08 change reference imlementation for PLACE to avoid no overlapping issue, code by Wil Baden
  • 2020-07-29 improving Markdown formatting
  • 2020-07-28 revising historical description, correcting typos
  • 2021-07-26 adding history
  • 2021-07-22 initial version

Problem

Traditional Forth represents strings in memory as so called counted strings, a leading count byte giving the length of the string (0 to 255) followed by the characters of string. No character value plays a special role (in contrast to zero-terminated strings where the character NUL terminates the string). The limitation of a single count byte and thus a maximal string length of 255 characters imposes no restriction on a broad range of applications especially in embedded systems. Of course there are applications that require processing longer strings. The programmer should then best use another string representation (such as c-addr len) without the length restriction of counted strings.

The advantage of counted strings is that they are identified by a single cell (the address of the count byte) on the data stack and so help minimizing stack rearrangements.

The Forth-94 and Forth-2012 standards make use of counted strings and specify even core words which use counted string representation such as WORD FIND COUNT.

The Informational Annex of Forth-94 says in A.3.1.3.4 about counted strings

Counted strings remain useful as a way to store strings in memory. This use is not discouraged, but when references to such strings appear on the stack, it is preferable to use the “_c-addr u_” representation. 

What is missing is an easy way to place a sequence of characters into memory using the counted string representation and also appending a sequence of characters to an already existing counted string in memory.

Solution

The Forth community already has a solution for placing strings as counted strings into memory and appending characters to counted strings by means of the words PLACE and +PLACE. PLACE appeared around 1984 e.g. in F83. +PLACE has been proposed by Wil Baden in his Tool Belt Extensions (latest version at [1], also with the name APPEND)[^1]. Since then many systems have adopted PLACE and +PLACE with exactly the same behaviour.

So, we are proposing PLACE and +PLACE here for standardization.

Proposal

Please add the following specifications to the string extension word set.


PLACE STRING EXT

              ( c-addr1 u c-addr2 -- )

Store u as a length character at c-addr2. When character size is smaller than cell size, only the number of low-order bits corresponding to character size are transferred.

Store u as a length character at c-addr2. Only the number of low-order bits corresponding to character size are transferred.

If u is greater than zero, copy u consecutive characters from the data space starting at c-addr1 to that starting at c-addr2+1, proceeding character-by-character from lower addresses to higher addresses.

+PLACE "plus place" STRING EXT

              ( c-addr1 u1 c-addr2 -- )

Read the length character at c-addr2 as u2.

Store u1+u2 as a count character at c-addr2. When character size is smaller than cell size, only the number of low-order bits corresponding to character size are transferred.

If u1 is greater than zero, copy u1 consecutive characters from the data

space starting at c-addr1 to that starting at c-addr2+u2+1, proceeding character-by-character from lower addresses to higher addresses.


end of proposal

Rationale

PLACE places the string identified by c-addr1 u as a counted string at c-addr2 managing the length character. Essentially PLACE converts from c-addr len representation to counted string representation.

PLACE complements COUNT which essentially converts counted strings in memory to their c-addr u representations.

+PLACE appends the string identified by c-addr1 u1 to the counted string at c-addr2 (with length u2) managing the updated string length in the length character at c-addr2.

The application must take care of any string overflow situation where the length of the resulting string would exceed the maximal length that can be stored in a length character. Also it has to assure that the memory is available to store the resulting string.

Note, that the proposal adds PLACE and +PLACE to the up to now empty string extensions word set. A compliant Forth system is free to provide or not to provide these words individually. If it chooses to provide them, they must have the above behaviour. Providing the words could be done by making the reference implementation available in source form or by means of an appropriate alias definition of an already provided word.

Typical Use

S" The quick brown"  PAD PLACE  
S"  fox jumps over" PAD +PLACE
S"  the lazy dog." PAD +PLACE

PAD COUNT TYPE  ( The quick brown fox jumps over the lazy dog.)

Reference Implementation

PLACE and +PLACE can be implemented in Forth-94 as follows:

    : PLACE ( c-addr1 u c-addr2 -- )
     2DUP C!  CHAR+ SWAP MOVE ;
     2DUP 2>R  CHAR+  SWAP CHARS MOVE  2R> C! ;
: +PLACE ( c-addr1 u c-addr2 -- )
     DUP COUNT + >R    2DUP C@ + SWAP C!  R> SWAP MOVE ;


Of course systems are expected to provide optimized implementations.


## Testing

The following tests assure basic functionality of <strong><code>PLACE</code></strong> and <strong><code>+PLACE</code></strong>

CREATE buf 64 ALLOT


T{ S" ABC" buf PLACE  buf COUNT S" ABC" COMPARE -> 0 }T

T{ S" ABC" buf PLACE  buf C@ -> 3 }T

T{ S" ABC" buf PLACE  
   S" DEF" buf +PLACE  buf COUNT S" ABCDEF" COMPARE -> 0 }T



## Experience

<strong><code>PLACE</code></strong> and <strong><code>+PLACE</code></strong> have been implemented in numerous systems with the proposed functionality. <strong><code>+PLACE</code></strong> is sometimes called <strong><code>APPEND.</code></strong> A non-exhaustive list is:


<table>
  <tr>
   <td>System
   </td>
   <td>PLACE
   </td>
   <td>+PLACE
   </td>
  </tr>
  <tr>
   <td>gforth
   </td>
   <td>??
   </td>
   <td>??
   </td>
  </tr>
  <tr>
   <td>SwiftForth
   </td>
   <td>??
   </td>
   <td>provided as APPEND
   </td>
  </tr>
  <tr>
   <td>VFX Forth
   </td>
   <td>??
   </td>
   <td>provided as APPEND in ToolBelt.fth
   </td>
  </tr>
  <tr>
   <td>Win32Forth
   </td>
   <td>??
   </td>
   <td>??
   </td>
  </tr>
  <tr>
   <td>4th
   </td>
   <td>??
   </td>
   <td>??
   </td>
  </tr>
  <tr>
   <td>PFE
   </td>
   <td>??
   </td>
   <td>??
   </td>
  </tr>
  <tr>
   <td>F-PC
   </td>
   <td>??
   </td>
   <td>??
   </td>
  </tr>
  <tr>
   <td>F83
   </td>
   <td>??
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>volksForth-83
   </td>
   <td>??
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>DXForth
   </td>
   <td>??
   </td>
   <td>
   </td>
  </tr>
  <tr>
   <td>
   </td>
   <td>
   </td>
   <td>
   </td>
  </tr>
</table>



## Discussion


### <strong>Why standardize <code>PLACE</code> and <code>+PLACE</code>?</strong>

Standard programs that deal with counted strings often also make use of <strong><code>PLACE</code></strong> and <strong><code>+PLACE</code></strong>. As these words are not known to be provided by the underlying system the standard program has to bring its own possibly less efficient implementation with it. This can be done with a prelude that uses the above reference implementation.

Note that the typical phrase

[UNDEFINED] PLACE [IF]

«reference implementation for PLACE»

[THEN]

[UNDEFINED] +PLACE [IF]

«reference implementation for +PLACE»

[THEN]



is not sufficient as the underlying system might provide <strong><code>PLACE</code></strong> or <strong><code>+PLACE,</code></strong> <strong>but with a different behaviour</strong>, rendering the rest of the standard program invalid.

If <strong><code>PLACE</code></strong> and <strong><code>+PLACE</code></strong> are standardized, then a compliant system (if it decides to provide them) has to define them with the exact proposed behaviour. The above phrase would be sufficient and standard programs can leverage efficient system provided implementations.


### **Restriction on the Length of Counted Strings**

Forth-94 and Forth-2021 both do not enforce characters to be of byte size so allow for systems with larger character sizes and by this also counted strings with a maximal length that exceeds 255 characters. For this reason both standards use the term “length character” and not “count byte”.

Since then, in 2016 the Forth-200x committee in favour of eliminating ambiguous conditions has decided to require “1 CHARS = 1” thus making systems that have other character sizes than on not compliant to _future_ Forth-200x standards [2][3]. Requesting standard systems to have byte size characters limit counted strings to the known maximal length of 255 characters.


## References 

[1] “Toolbelt”, Wil Baden/Neil Bawd, [http://www.wilbaden.com/neil_bawd/tool2002.txt](http://www.wilbaden.com/neil_bawd/tool2002.txt)

[2] http://www.forth200x.org/rfds.html

[3] http://www.forth200x.org/char-is-1.html


## Authors

Hans Bezemer &lt;[thebeez@xs4all.nl](mailto:thebeez@xs4all.nl)>

Ulrich Hoffmann &lt;[uho@xlerb.de](mailto:uho@xlerb.de)>


<!-- Footnotes themselves at the bottom. -->
## Notes

[^1]: If the reader is aware of the detailed history of <strong><code>+PLACE</code></strong> aka <strong><code>APPEND</code></strong>, the authors would be happy to learn about that.
CfV - Call for votes

AntonErtlavatar of AntonErtl

The specification requires a specific (and probably not useful) behaviour when the start of the target address is in [c-addr1, caddr1+u). The reference implementation uses MOVE, which guarantees a different (and probably more useful) behaviour in that case. The two should be reconciled, and in this case I think it's better to change the specification to agree with the (more useful) reference implementation. For +PLACE there is the additional complication of whether the original or updated count should be copied if it is in [c-addr1,c-addr1+u), but at least in this case the specification and the implementation agree that the updated count is copied; Gforth also behaves that way, but SwiftForth's APPEND updates the count only afterwards.

AntonErtlavatar of AntonErtl

Also, for PLACE, the specification specifies that the count byte is stored first, while the reference implementation, the Gforth implementation and the SwiftForth implementation store it afterwards. This makes a difference if c-addr2 is in [c-addr1,c-addr1+u).

Reply New Version