[Nasm-devel] RFC: operator precedence question, for <=> operator in NASM

[anonymous c. <nas...@us...>]

While looking into implementing the <=> operator [1] [2], I ended
up re-visiting the long-standing operator precedence differences
between NASM and C.

In particular, NASM lumps relational and equality operators while
C keeps them separate [3], and NASM implements bitwise AND/
OR/XOR above relational and equality operators while C handles
them below those [4].

These differences go back all the way to NASM 0.96, when eval.c
was separated from parser.c, and the bitwise AND/OR/XOR were
actually introduced.

For [3] I have been using a NASM patch for many years -- it splits
relational and equality operators by default (a la C) but provides a
command line option for lumping them back together (for the sake
of NASM compatibility).

For [4] I did not end up with a NASM patch (to move bitwise AND/
OR/XOR below relational and equality, a la C) -- my decision back
then was driven by [5].

Alright, enough history -- back to <=> i.e. the issue at hand.  :)

For C the <=> operator's precedence seems to be heading toward
below bitwise shifts but above relational. Which is where NASM is
currently having bitwise AND/OR/XOR. Which in turn does require
a decision on whether <=> should go above or below bitwise AND/
OR/XOR for NASM.

And while the precedence of bitwise AND/OR/XOR in NASM could
be changed (to match the one in C), doing so without an option for
reverting to traditional NASM behavior (similar to what I did for the
splitting/lumping of relational and equality) seems risky. With such
an option, the precedence question -- of <=> versus bitwise AND/
OR/XOR -- remains.

Given where C seems to be heading, placing <=> *above* bitwise
AND/OR/XOR striks me as the right choice. It not only follows C's
precedence (pun intended :), but it also allows for NASM's bitwise
AND/OR/XOR to be moved in the future (to match C).

Comments?

[1] https://en.wikipedia.org/wiki/Three-way_comparison
[2] http://open-std.org/JTC1/SC22/WG21/docs/papers/2017/p0515r0.pdf
[3] https://sourceforge.net/p/nasm/bugs/103/
[4] https://sourceforge.net/p/nasm/bugs/107/
[5] http://www.lysator.liu.se/c/dmr-on-or.html