Digest #316 2025-09-03
Contributions
: +! ( n|u a-addr -- )
TUCK @ + SWAP ! ;
Replies
I do not know of any Forth implementation on a ones-complement or sign-magnitude machine, much less of a Forth-94/2012 implementation. It's an interesting, but practically irrelevant, question if Forth-94/-2012 can be implemented on such hardware with + etc. performing ones-complement or sign-magnitude addition, and then run commonly available code.
My thinking when reading the specification is that 0= should return true for negative 0. Same for 0 =. If the authors of Forth-94 had bitwise equality in mind, they should have specified it (like they did for 0e F~; I don't know what point that specification has, however). The consequence of that would be that code that uses 0= on flags does not work as intended on ones-complement machines, as you point out. There might also be some fallout on sign-magnitude machines.
There might indeed be less fallout if 0= and 0 = produced false when there is a negative 0 on the top of stack. If there ever is someone who implements Forth on such a system, it will be interesting to get a report from them what they did about this problem and what the result was.
0 = is already required to only return TRUE for bit-for-bit equality; so it is only 0= that didn't distinguish which type of equality is meant, where there is an ambiguity on whether it is implemented as : 0= 0 = ; or as signed hardware equality. But I've seen plenty of code that assumes action DUP 0= IF or similar does the right thing when action returns a flag; declaring that such code has an environmental dependency unless it inserts the space between 0 and = seems like it would be chasing windmills.
A double IMMEDIATE is already tested in the test suite file coreplustest.fth
Overall, this is an interesting observation.
so it is only
0=that didn't distinguish which type of equality is meant
I think that from 3.2.1.1 and A.3.2.1 it should be concluded that:
- any formal reference to
zerowithout qualification means a single-cell value with all bits clear, which can be universally interpreted as arithmetic zero (positive zero or unsigned zero); - there is no standard way to obtain a negative zero value;
Then, 0= shall be equivalent to 0 =.
But there are non-numeric words, such as
ANDandOR, which operate on the bits of x rather than on an arithmetic value of n or u; and those words can indeed be used to generate the bit pattern of negative zero.
Yes, using these words a Forth-2012 compliant program can generate a value that can be interpreted as the negative zero on some plausible Forth-2012 systems, but the program cannot universally interpret this value as a specific integer number in arithmetic operations — i.e., this is ambiguous. The program can probably test the environment and use such an interpretation when it matches the system.
Anton wrote:
My thinking when reading the specification is that
0=should returntruefor negative 0. Same for0 =.
After the first glance, I thought so too. But a consequence of this interpretation is that TRUE 0= is ambiguous.
But the argument of 0= (and =) has type x (hence, flag is allowed as an argument), and no ambiguous conditions are specified. Then, TRUE 0= must be unambiguous and return the same result on any standard system.
since the execution of
mchanges dictionary pointers.
Yes, formally, "change the compilation word list" can cover both cases:
- make another word list the compilation word list;
- change the state of the compilation word list (i.e., add or remove words in the word list).
But adding a word does not lead to an ambiguous condition, because the added word becomes "the most recently compiled definition". Hence, the entire case (2) does not apply.
It seems intuitively obvious which word is "the most recently compiled definition" in the dictionary after execution of a marker — it is the word that had this status just before the marker was defined (but only if execution of a marker restores the search order and the compilation word list in use). I don't see a technical problem in implementing this.
Thus, the same as for does> (see my reply-1501), we should either formally declare an ambiguous condition concerning execution of markers, or treat the intuitive understanding which word is "the most recently compiled definition" as implied by the standard (and clarify this).