RE: Mantis #658 for V-1364: Notes

From: Shalom.Bresticker@freescale.com
Date: Wed May 04 2005 - 07:26:00 PDT

  • Next message: Clifford E. Cummings: "RE: [sv-cc] P1364 meeting minutes and email ballot"

    > > 3.5.1: See ETF #428 proposal for better places to locate
    > > Notes 2 and 3.
    > > Note 1 disappeared from that proposal, but I don't remember
    > > whether that was deliberate. You can find suggestions for
    > > places to locate Note 1 in earlier versions of the proposals
    > > to 428 by looking through the email history of that issue.
    >
    > The example 4 in D6 does not match the final example in ETF 428, so I'm
    > not sure what to do with this. Other than the examples, the consensus of
    > 428 seems to be to delete the three NOTES paragraphs. Is this what
    > you're proposing?

    The example is not relevant here.
    The proposal is:

    Note 1) Sized negative constant numbers and sized signed constant numbers are sign-extended when assigned to a reg data type, regardless of whether the reg itself is signed or not.

    Delete this note. Turn it into normative text.
    Move it to be a new normative paragraph preceding the paragraph,
    "The use of x and z in defining the value of a number is case insensitive."

    Note 2) Each of the three tokens for specifying a number may be macro substituted.

    Delete this note. Add the sentence,
    "It shall be legal to macro substitute these three tokens."
    at the end of the second paragraph, which begins "There are two forms to express integer constants."

    Note 3) The number of bits that make up an unsized number (which is a simple decimal number or a number without the size specification) shall be at least 32.

    Delete this note. Add the sentence,
    "The number of bits that make up an unsized integer constant (which is
    a simple decimal number or a based constant without a size specification) shall be at least 32."
    at the BEGINNING of the paragraph which now begins,
    "Unsized unsigned constants where the high order bit is unknown (X or x) or three-state (Z or z) shall be extended to the size of the expression containing the constant."

    > > 9.2: I don't think we should reference 3.5.1 here, since 5.4
    > > and 5.5 are
    > > supposed to describe the rules completely. Please verify whether 5.4
    > > should be referenced or 5.5. Delete the word "subclause".
    >
    > 3.5.1 describes rules for extending constants, and covers the
    > x/z/0/sign-extension rules (11th paragraph). The same information is
    > specified as a footnote for table 5-21 in 5.4.1. I've amended the
    > proposal to read:
    >
    > As described in 5.4, when the right-hand side evaluates to fewer bits
    > than the left-hand side, the right-hand side value is padded to the size
    > of the left-hand side. If the right-hand side is unsigned, it is padded
    > according to the rules specified in 5.4.1. If the right-hand side is
    > signed, it is sign-extended.

    OK (I think)

    > > 14.2.4.3: The problem is that the paths are not unique. See ETF #652.
    >
    > I take it this is an issue that should have made it into D6, but didn't?
    > If so, are there others, and how can we track these? Will it be
    > sufficient just to remove the note?

    ETF 652 is an issue that we never resolved.
    Apparently two different examples were combined into a single example,
    and then the 4 together are not mutually exclusive.
    With or without the note, the example is not legal.
    It would be better to split it up into 2 separate examples.

    > > 27.25: I wrote previously that I don't like writing, "The
    > > $fopen system
    > > function may also return fd file descriptors" because it
    > > sounds like it is
    > > optional.
    >
    > How about: "If the most significant bit of the return value from $fopen
    > is set, then the value is an fd file descriptor, which is not compatible
    > with the mcd descriptor returned by vpi_mcd_open()"

    OK.

    I did not yet have time to review Cliff's comments.

    Shalom 

    -- 
Shalom.Bresticker @freescale.com                     Tel: +972 9  9522268
Freescale Semiconductor Israel, Ltd.                 Fax: +972 9  9522890
POB 2208, Herzlia 46120, ISRAEL                     Cell: +972 50 5441478

    This archive was generated by hypermail 2.1.4 : Wed May 04 2005 - 07:02:01 PDT and
    sponsored by Boyd Technology, Inc.