Re: errata/608: mintypmax_expression usage

From: Shalom.Bresticker@freescale.com
Date: Fri Jul 30 2004 - 02:40:00 PDT

  • Next message: Eric Mahurin: "Re: errata/607: function returning signed integer/real/time/realtime"

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

    From: Shalom.Bresticker@freescale.com
    To: eric_mahurin@yahoo.com
    Cc: etf-bugs@boyd.com
    Subject: Re: errata/608: mintypmax_expression usage
    Date: Fri, 30 Jul 2004 12:34:17 +0300 (IDT)

     Eric,
     
    > Section 4.3 says this: "Values expressed in min:typ:max format can be used in expressions. The min:typ:max format can be used
    > wherever expressions can appear."
    >
    > I think the intent is that these ONLY be used with expressions that are used for generating delays or times. I don't see where it says that.
     
     No, mintypmax expressions really can be used anywhere.
     
      
    > Secondly, the BNF is inconsistent in its use of mintypmax_expression and expression. As it is now, even an epression can have a mintypmax_expression in it with parenthesis.
    >
    > Personally, I think mintypmax_expression should unified expression and then in the text just describe when an expression or portion of it should allow the mintypmax ":" operators.
     
     mintypmax expressions are discussed somewhat in issues 174 and 226.
     
     We know that the BNF is not completely consistent with where implementations
     actually require the parentheses and where they don't. We found it to be
     difficult to research the subject thoroughly and to make the BNF conform to
     that. If we take the approach that the BNF in the next revision can be more
     lenient as long as it does not forbid anything which currently works, then it
     might be easier.
     
     
    > But, if you don't do this, at least make all of the places that can have delay/time values use mintypmax_expression instead. Here are the ones I found:
    >
    > A.2.2.1: variable_type
    >
    > A.4.1: ordered_parameter_assignment (named parameters allow mintypmax, but ordered doesn't)
    >
    > A.6.5: wait statement
    >
    > A.7.5.2: timing_check_limit (found the issue here originally while parsing some example code with a $period statement and colons used direction in these timing_check_limit arguments)
     
     I haven't looked at these.
     
     
    > Again, I think expression and mintypmax_expression should be merged (along with constant_expression and module_path_expression) instead.
     
     I looked at merging constant_expression and module_path_expression with
     expression, as you suggested. I found then different enough at the basic
     element, the primary, that I was reluctant to do that merger.
     
     The idea of mintypmax_expression as I remember was to require parentheses
     everywhere except where specifically allowed without parentheses.
     
     Bring on the additional issues.
     
     Shalom
     
     --
     Shalom Bresticker Shalom.Bresticker @freescale.com
     Design & Reuse Methodology 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 : Fri Jul 30 2004 - 02:40:20 PDT and
    sponsored by Boyd Technology, Inc.