errata/282: Re: errata/282: signing

From: Alec Stanculescu (alec@fintronic.com)
Date: Mon May 03 2004 - 08:20:00 PDT

  • Next message: pieper@synopsys.com: "errata/16: PROPOSAL - 19.7: `line - meaning of level parameter is unclear"

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

    From: Alec Stanculescu <alec@fintronic.com>
    To: mac@verisity.com
    Cc: Shalom.Bresticker@motorola.com, etf-bugs@boyd.com, btf-dtype@boyd.com
    Subject: Re: errata/282: signing
    Date: Mon, 3 May 2004 08:38:13 -0700

     Mac,
     
         4.5.2 is poorly written as well. It mixes the notions of size,
         property of signed/unsigned and type in some steps that are not
         enumerated, it makes references to 4.5.1 when it talks about
         determining the sign ( note that 4.5.1 is the section which talks
         about the type of expressions) and does not reference the section
         that describes how the size is determined.
     
         The correct answer to the issue you raise is that the BNF must be
         understood in terms of it's corresponding schema, under which both
         one operand expressions and "complex expressions" are expressions.
     
         Given that the code the user is writing is modified automatically
         by the LRM-obiding tool (by transforming signed into unsigned) in
         a way that produces results that are
         different from the expected ones, I propose that such mixed
         descriptions where signed and unsigned operands are encountered
         shall be flagged as errors. It will force users to realize that
         what they wrote is useless (according to the LRM anyways) and that
         by re-writing their code at least they will have some code which
         will produce expected results.
     
     Regards,
     
     Alec
     
    >
    > 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 : Mon May 03 2004 - 08:20:20 PDT and
    sponsored by Boyd Technology, Inc.