Re: errata/282: signing

From: Alec Stanculescu (alec@fintronic.com)
Date: Mon May 03 2004 - 17:50:45 PDT

  • Next message: Shalom.Bresticker@freescale.com: "Re: BTF enhancement open issues which Kurt thinks belong to datatypes"

    Steve,

    I respect very much your style of writing, especially when it provides
    information relevant to the topic at hand. Simple claims that you
    talked to people and know what they want are not good enough as
    arguments to be taken into account.

    Furthermore, I do not believe that anybody told you that what he/she
    really wants is to write some Verilog, knowing without a doubt that
    any LRM-complying Verilog tool will effectively change their Verilog
    description into some other Verilog code, producing totally different
    results from what they may expect. Such a user would be better off
    being told by the tool that what he/she wrote is not legal according
    to the LRM and that he/she should write it differently to begin with!
    This way at least the user will have documented the exact Verilog that
    will be considered by any Verilog LRM complying tool.

    This is like for any semantic error the tool would produce some
    arbitrary result and continue without complaining. I know that
    there is some precedence for this, such as in assignments to bit
    selects with indexes out of range, but this precedent does not make
    this practice any more acceptable.

    So, what do you say to the proposal to make illegal any complex expression
    that uses both signed and unsigned. This could simplify the LRM
    enormously and users would see only benefits from this, since they
    would not loose any modeling capabilities they currently have, and
    models would be portable across tools.

    > Alec,
    >
    > You cannot tell someone what they meant when they wrote something;
    > you can only ask them.
    >
    > Have you asked the people responsible for the signed arithmetic proposal
    > what they meant? I have. You are trying to tell me that they meant
    > something different from what they say they meant. I have to conclude
    > that you are wrong, and that they meant what they say.
    >
    Until you tell us what they told you we cannot say anything on this
    matter.

    > You are including the datatypes task force in the distribution of this
    > discussion. As a result, I wonder if your real concern is the problems
    > that would occur if the rules for signedness were applied to the new
    > type system. This concern could have arisen because the 2001 LRM uses
    > the term "type" when talking about signedness. It tries to roll reals
    > in as a type also, and claim the same rules apply, but this is wrong
    > since different rules apply to reals, and always have.
    >
    Indeed, this is a concern of mine.

    > I agree with you that these rules probably won't work if applied to
    > datatypes in general. They don't even work for reals. The rules are
    > applied to the signedness of vector expressions, which is why they need
    > to work similarly to the rules for sizes of vectors.
    They do work similarly, with the exception that the type depends only
    on the operands and the size may also depend on the context. The
    context makes it possible for the size of a sub-expression to be
    influenced by the size of another sub-expression within the same
    expression.

    >Just because the
    > LRM text uses the term "type" for signedness does not mean that new types
    > will have to follow the same rules. It just means that if they don't,
    > the signedness rules will have to stop using the term "type".
    >
    Signedness does create a different type and I would like to see the
    terminology consistent. Of course sometimes there can be exceptions,
    but only when exceptions are absolutely necessary.

    > Note that the correct rules for reals do not convert non-real operands
    > to real until they are about to be combined with a real at an operator.
    > Subexpressions that will be implicitly converted to real this way are
    > treated as self-determined until that point. This behavior is similar
    > to most programming languages, and is what apparently seems natural to
    > you. When it is documented correctly, this could form a starting point
    > for rules for other datatypes.
    >
    > Steven Sharp
    > sharp@cadence.com
    >
    Alec Stanculescu

    This archive was generated by hypermail 2.1.4 : Mon May 03 2004 - 17:31:20 PDT and
    sponsored by Boyd Technology, Inc.