errata/282: Re: errata/282: signing

From: Michael McNamara (mac@verisity.com)
Date: Sun May 02 2004 - 23:00:00 PDT

  • Next message: Karen Pieper: "Meeting Monday May 3"

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

    From: Michael McNamara <mac@verisity.com>
    To: Alec Stanculescu <alec@fintronic.com>
    Cc: Shalom.Bresticker@motorola.com, etf-bugs@boyd.com, btf-dtype@boyd.com
    Subject: Re: errata/282: signing
    Date: Sun, 2 May 2004 23:15:22 -0700

     What about 4.5.2?
     
     What about the BNF, where the top level production is called
     "expression" (see page 58) not "complex expression"?
     
     It is true that special things happen given certain binary expressions
     with special operators (>>, **, et cetera).
     
     However the only definition of expression is that in the BNF, and in
     the case of an assignment, "expression" consists of everything on the
     right hand side of an assigment (everything after the '=").
     
     This would support the position that the generic signing and sizing
     rules, when they talk about applying to an expression, in the absense
     of some of these special operators, apply to everything tha Alex is
     calling complex expression. Indeed the term "complex expression"
     doesn't appear in the main text of the manual at all. It does appear
     in the vpi section of the manual; but it is hard to take this as a
     term of the language becuae of this.
     
     
     -- On May 2 2004 at 22:01, Alec Stanculescu sent a message:
    > To: Shalom.Bresticker@motorola.com, etf-bugs@boyd.com, btf-dtype@boyd.com
    > Subject: "Re: errata/282: signing"
    >
    > > > The precedent providing the answer to this question is present in
    > > > 4.1.5 Arithmetic operators (just a few paragraphs before the debated
    > > > use of the word "expression").
    > >
    > > Alec,
    > >
    > > Are you confusing between 4.1.5 and 4.5.1 ?
    > >
    > The answer is NO. However, I do understand why you may be confused
    > by 4.1.5 and 4.5.1. It is because in breaking with an important
    > rule of how to write the LRM, writing the fix of errata 140 has
    > introduced a forward reference in 4.1.5 to 4.5.1.
    >
    > Most forward references should be considered errata and
    > eliminated. That would make for a much better LRM.
    >
    > > > 4.1.5 deals with the specific details of how the type of the
    > > > expression is determined, and which states among other things
    > > > that:
    > > >
    > > > "....
    > > > The result of the power operator shall be real if either operand is a
    > > > real, integer, or signed. If both operands are unsigned then the
    > > > result shall be unsigned.
    > > > ..."
    > > >
    > > > It is clear (because of the use of the word "both") that the type of
    > > > the power-operator-expression depends only on the type of the operands
    > > > of this particular operator and not on the operands present in a
    > > > complex expression which may include the power operator as a
    > > > subexpression. Also, I cannot imagine how it would be if the type of
    > > > the power operator expression would depend on the operand on some
    > > > other expression included in the same overall complex expression.
    > >
    > > You picked a bad example for several reasons.
    > >
    > The wordings of 4.1.5 in "version B" clearly showed the intention of
    > the LRM to determine the type of the expression that uses the power
    > operator as depending only on it's two operands.
    >
    > Given that this is one of the few places where the LRM showed it's intention
    > one way or the other regarding whether "expression" in 4.5.1 means
    > the entire ensemble of subexpressions, or just an expression having
    > one operator, makes the "original wording of the LRM" extremely
    > relevant. Basically, in fixing issue 140 the writer
    > of the LRM has erased one instance of the clear intent of the LRM with
    > respect to what "expression" means in 4.5.1. Also, the fix of errata 140,
    > is flowed in that it introduced a forward reference in 4.1.5 to 4.5.1.
    > Each forward reference in the LRM is basically an errata in itself!
    >
    > > One is that the text you quoted is from 1364-2001 Version B and is simply
    > > incorrect. That was errata issue #140. The text was completely rewritten
    > > and substantially changed.
    > >
    > > The second reason is that, yes, the type of the first operand of the power
    > > operator (i.e., the base) is affected by the other operands in the
    > > expression
    > > in which it appears, i.e., it's bit-size and signedness.
    > > (The second operand, the power, is self-determined, and not affected by other
    > > operands.)
    > >
    > > Thirdly, the text refers only to the two operands of this operator in order to
    > > not complicate the text further by talking about additional
    > > operands.
    > This is pure speculation and cannot be considered as argument.
    >
    > > Similarly, 4.1.7, for example, says that "When two operands of unequal bit
    > > lengths are used ..., the smaller operand shall be zero filled ... to extend
    > > to the size of the larger operand," and does not relate to other operands in
    > > the larger expression. And the same is true of the other
    > > subsections of 4.1.
    > Thank you presenting the argument for me. Indeed several subsections
    > in 4.1. describe the type of the expression in terms of the operands
    > associated to the particular operator. This is so precisely because
    > the type of an expression does not depend on the types of operands of
    > other expressions that happen to be combined into the same complex
    > expression with the one whose type we try to determine.
    >
    > As I stated earlier the size of the expression may also depend on
    > context whereas the type of an expression depends only on the types of
    > it's operands and not on it's context (i.e. on other sub-expressions
    > combined in the same expression via the rules of precedence and via
    > open and closed parenthesis).
    >
    > >
    > > Shalom
    > >
    > Alec
     

    This archive was generated by hypermail 2.1.4 : Sun May 02 2004 - 23:00:24 PDT and
    sponsored by Boyd Technology, Inc.