Menu

#38 lift restrictions on relational/equality/boolean logic ops

open
nobody
None
1
2004-02-13
2003-08-10
No

As of writing this, the relational, equality, and
boolean logic operators are restricted to %(EL)IF.
That is, only if an expression is used with those
particular preprocessor directives, may it contain
said operators.

When I reviewed Nickolay's proposed changes to the
evaluator (for a conditional ternary operator -- SF
request 758548 has details), I noticed that he was
going through some pain to maintain the restriction
of these operators.

At that point I started to take a closer look, to
see whether why that restriction was introduced,
whether it could be removed, and whether it should
be removed in the future.

My conclusion is that the restriction is merely an
artefact of NASM history, that it can be removed,
and that it should be removed.

Up to NASM v0.96 the evaluator wasn't a standalone
module, and the preprocessor didn't know %(EL)IF.
Only when those two changes were made in 0.96, was
the restriction on the new operators imposed. No-
where does it say why.

As Nickolay's changes have shown, these operators
can be evaluated in _all_ situations, not just the
case of %(EL)IF directives.

Therefore I think that the restriction should be
removed. Doing so would make NASM expressions more
similar to those of e.g. C. And more powerful, of
course.

Also, doing so would simplify the changes required
for the conditional ternary operator. :)

Does anyone see a problem with this?

Discussion

  • Nickolay Yurchenko

    Logged In: YES
    user_id=806493

    In my sources I'd just added a warning when programmer
    uses conditionals outside of %(el)if, expressions are evaluated
    correctly (I had think these restrictions are needed for
    someone). So, removing these parts of code is trivial.

    But the thing disturbing me much more is docummented
    example of using '?' as first identifier sign for
    masm-emulating syntax. What do you think? To remove this
    example from documentation (less compatibility - someone
    uses this syntax, of course) or to add partial support to this
    syntax (this is bad decision, I know) or to add a comand line
    key (this is bad too)?

     
  • nasm64developer

    nasm64developer - 2004-02-13
    • priority: 5 --> 1
     

Log in to post a comment.