Re: errata/474: First class part selection operator

From: Steven Sharp (sharp@cadence.com)
Date: Thu Sep 18 2003 - 08:30:00 PDT

  • Next message: Adam Krolnik: "Re: enhancement/477: Provide an assertion statement with thecapabilityto use industry standard property specification."

    Precedence: bulk

    The following reply was made to PR enhancement/474; it has been noted by GNATS.

    From: Steven Sharp <sharp@cadence.com>
    To: etf-bugs@boyd.com
    Cc:
    Subject: Re: errata/474: First class part selection operator
    Date: Thu, 18 Sep 2003 12:15:21 -0400 (EDT)

     I am forwarding a copy of part of the local discussion that Jay refers to.
     It might be relevant to this enhancement request.
     
     
    >On page 42 of the 2001 LRM the operator precedence table does not
    >include:
    >
    > ".", "()", "[]"
    >
    >Should we file an errata on this? In the stuff on dereference I'm doing
    >for handles we are going to need to introduce unary * and -> and the
    >precendence relative to the above will be important.
     
     In the existing LRM, these are not considered to be operators. The "."
     is not described as an operator; instead, it is considered part of a
     hierarchical name, a special identifier. The LRM even disallows spaces
     around the "." in the name. I have suggested that this restriction be
     removed and the "." be treated more like an operator.
     
     The "[]" is not described as an operator; instead, bit and part selects
     are operands of expressions involving real operators.
     
     I assume you are referring to "()" meaning a function call. Again, this
     is not regarded as an operator.
     
     They can get away with this because there are so many restrictions on
     how these operators can be applied. For example, a function name can
     only be used with "()", and "()" can only be used with a function name.
     So the name and the argument list can be regarded as part of the same
     operand, not as an operator applied to an operand. Note that in Verilog,
     the "()" can be left off of a system function call that has no arguments
     (Verilog HDL functions are required to have arguments), so it really
     isn't an operator meaning function call anyway.
     
     Similarly, an array can only be referenced with "[]", and (except for
     bit and part selects) "[]" can only be used with an array. The same
     thing applies to "." and a scope.
     
     Also, you can't parenthesize all of the "operands" of these "operators",
     so they aren't really separable operands being acted on by operators in
     expressions. For example, you can't say (array)[i], or (name1).(name2)
     or (func)(i).
     
     I know that there was a proposal to add some entries to the operator
     precedence table. For example, the "{}" and "{{}}" (concatenation and
     multi- concatenation) operators were added. It wasn't clear what precedence
     to use for them, since they are self-parenthesizing and don't rely on
     precedence. This made it meaningless to add them to the table. I think
     the event-or got left out after some discussion, because it wasn't being
     referred to as an operator in other sections, and putting the "," version of
     it into the table would have been confused with other uses of commas. I
     think they may have added something else too. Overall I think it would
     have been better left alone.
     
     Steven Sharp
     sharp@cadence.com
     
     ------------- End Forwarded Message -------------
     
     
     Steven Sharp
     sharp@cadence.com
     

    This archive was generated by hypermail 2.1.4 : Thu Sep 18 2003 - 08:32:37 PDT and
    sponsored by Boyd Technology, Inc.