Precedence of Unary Logical Operators

Proposal Information

  • Who Updates: JimLewis, YourName>, ...
  • Date Proposed: 2013-11-14
  • Date Last Updated: 2013-11-14
  • Priority:
  • Complexity:
  • Focus: Testbench

Requirement Summary

In VHDL-2008 LRM p118, the precedence of the unary logical operators is not listed and needs to be.

Related and/or Competing Issues: NONE

Issue Summary: Bugzilla 278 and 280

Bugzilla 278 ... Skipping over the part that is ok ...

the list on 9.2.1, Operators-General, is misleading and technically incorrect, since it lists logic_operators as second in the list and states the the "operators are listed in order of increasing precedence." This statement implies that my original claim about precedence is true. One possible solution is to add "logical reduction operators" or "unary logical operators" to the miscellaneous_operator list, to give them the correct precedence.

A further issue is that NOTE 2 on page 118 is wrong. It appears to be a relic of the way the grammar was originally written, not as it was finally approved.

Bugzilla 280 ... Closes saying it is ok and to see 278 for discussion

Actions

Change the grammar production for miscellaneous operator to

miscellaneous_operator ::= ** | abs | not | unary _logical_operator

Delete note 2 at the top of 118 that reads:

"NOTE 2—The syntax for an expression involving a unary condition operator or unary logical operator in combination with any other operator requires that the unary operator and its operand be a parenthesized expression. For example, the expressions “(and A) and B” and “A and (and B)” are legal, whereas the expression “and A and B” and “A and and B” are not. Similarly, “and (and A)” is legal, whereas “and and A” is not. An expression consisting only of a unary condition oprator or unary logical operator and its operand need not be parenthesized."

General Comments

-- DavidKoontz - 2014-10-07

If 9.1 Note 2 (top of P.118) where it would represent a lexical ambiguity between the EBNF and

9.2 Operators, 9.2.1 General, para 10:

Operators of higher precedence are associated with their operands before operators of lower precedence. Where the language allows a sequence of operators, operators with the same precedence level are associated with their operands in textual order, from left to right. The precedence of an operator is fixed and cannot be changed by the user, but parentheses can be used to control the association of operators and operands.

This would require parentheses to avoid an elaboration time error.

Supporters

Add your signature here to indicate your support for the proposal
-- DavidKoontz - 2014-10-07
-- Brent Hayhoe - 2014-10-13

Topic revision: r4 - 2020-02-17 - 15:34:57 - JimLewis
 
Copyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback