,---------------.
| Contributions |
`---------------´


,------------------------------------------
| 2025-08-25 13:24:21  EricBlake  wrote:
| requestClarification - Hardware zero vs all bits zero
| see: https://forth-standard.org/standard/core/ZeroEqual#contribution-409
`------------------------------------------
"is equal to zero" is unambiguous for an implementation with twos-complement arithmetic (the only bit value equal to zero is all bits zero); but for ones complement or sign-magnitude, the sentence is ambiguous thanks to hardware negative zero. A better wording would be "if all bits in the cell are equal to zero", to ensure that no implementation returns a true flag because the contents of x happen to be equal to hardware negative zero.

The standard is already clear at 3.2.1.1 that "Arithmetic zero is represented as the value of a single cell with all bits clear."?  The non-normative text in A.3.2.1 adds "Per 3.2.1.1 Internal number representation and 6.1.0270 0=, the implementor must ensure that no standard or supported word return negative zero for any numeric (non-Boolean or flag) result. Many existing programmer assumptions will be violated otherwise."  So in practice, that means no combination of `a b +` or `a b *` should result in a negative zero hardware output (at least absent any other trigger of ambiguous behavior, such as arithmetic overflow), and any word with a stack effect producing n or u can be assumed to have produced that value via arithmetic means, and so will not have left a negative zero on the stack.  But there are non-numeric words, such as AND and OR, 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.  Less obvious is whether LSHIFT (which operates on and produces x) falls into this category of being able to produce a hardware negative zero without triggering ambiguous behavior.

The problem is probably less pronounced on ones complement machines (since the very value of TRUE with all bits set is the hardware encoding of negative zero; any ones complement implementation that blindly uses a hardware signed equality assembly opcode that treats 0 and -0 as equivalent would be setting up for `TRUE 0=` to return the surprising TRUE that the rationale warns against), it would be surprising if such hardware did not also provide an opcode for unsigned zero equality (which should only admit the all bits zero case).  But even sign-magnitude systems should be careful on how 0= is implemented.

This may be a moot point going forward, since future versions of the standard will require twos complement behavior.



,---------.
| Replies |
`---------´


,------------------------------------------
| 2025-08-25 06:12:45  AntonErtl  replies:
| proposal - A easy visual separator
| see: https://forth-standard.org/proposals/a-easy-visual-separator#reply-1519
`------------------------------------------
The existing practice is to use newline or multiple spaces for visual separation.  The latter for your example:

````
: CATCH   SP@ >R   HANDLER @ >R   RP@ HANDLER !   EXECUTE   R> HANDLER !   R> DROP   0 ;
````


,------------------------------------------
| 2025-08-25 12:33:25  EricBlake  replies:
| proposal - A easy visual separator
| see: https://forth-standard.org/proposals/a-easy-visual-separator#reply-1520
`------------------------------------------
https://forth-standard.org/standard/locals/bColon already uses `|` as part of `{:` during locals; using it for more than one purpose may be confusing.


,------------------------------------------
| 2025-08-25 18:25:08  EricBlake  replies:
| comment - Ambiguous conditions
| see: https://forth-standard.org/standard/core/IMMEDIATE#reply-1521
`------------------------------------------
Is it ambiguous if immediate is performed more than once on the same definition, or is this an appropriate testsuite addition:

```forth
T{ 0 VALUE x -> }T
T{ : a 1 TO x ; IMMEDIATE IMMEDIATE -> }T
T{ x : b a ; x 2 TO x b x -> 0 1 2 }T
```

There is an observable difference if an implementation implements immediate by toggling a bit, where toggling it twice reverts to non-immediate; compared to an implementation that only ever sets the bit (even if it is already set).  From my testing, at least gforth and SwiftForth treat the second immediate as a nop; but since at least Jonesforth (yes, I know that's not a standard implementation) treats it as a toggle, I'm wondering if there any standard implementations that toggle.