Re: enhancement/409: lists in part-selects

From: Shalom Bresticker (Shalom.Bresticker@motorola.com)
Date: Sun Aug 03 2003 - 02:30:02 PDT

  • Next message: Shalom.Bresticker@motorola.com: "errata/356: PROPOSAL - 16: "1497-1999" should be "1497-2001""

    Precedence: bulk

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

    From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
    To: Jay Lawrence <lawrence@cadence.com>
    Cc: etf-bugs@boyd.com
    Subject: Re: enhancement/409: lists in part-selects
    Date: Sun, 03 Aug 2003 12:19:52 +0300

     Hi, Jay.
     
     That's a very interesting and elegant idea.
     
     I actually had to think about how indexing is defined in the Verilog language
     when I was looking at 3.9.1, bullet 2, which seems to relate to indexing as an
     operator, since the title of 3.9.1 is "Operators and real numbers".
     
     I don't think it was deliberate there, just not very precise wording and
     organization, but it got me to thinking about it.
     
     I understand what you wrote and I think it is worth further work.
     I am not sure it would simplify the LRM, though.
     
     You wrote that "Most other languages treat subscripting as a general
     operator. " Could you give a couple of references?
     My first mental association when I read that was the APL language,
     but I am not familiar with how languages like C and PERL relate to it.
     
     I like the idea of being able to write (r1 & r2)[3].
     One other feature which would be occasionally useful is subscripting of
     constants.
     
     Thanks and regards,
     Shalom
     
     
     Jay Lawrence wrote:
     
    > Shalom,
    >
    > I think this is an interesting enhancement that makes currently
    > expressible things more succinct and clear. As long as the user
    > community does not confuse succinctness with performance this is OK.
    >
    > This enhancement is closely related to another concept we've been
    > discussing internally here at Cadence related to bit-selects,
    > part-selects, and data types.
    >
    > Bit-selects and part-selects are currently defined as operands, not as
    > an operator. Most other languages treat subscripting as a general
    > operator. This allows things like subscripting to participated in
    > precendence relationships and arbitrary expressions. Once the language
    > has things like structs you get (for some struct s) expressions like:
    >
    > s.x[2]
    >
    > Now you need to define structure references as an operand as well or
    > define precedence of '.' and '[]'.
    >
    > One advantage of treating subscripting as an operator would be
    > simplifying the LRM signficantly. Currently anywhere operands are
    > discussed there is are special rules about bit-selects and part-selects.
    > If we just made them operators and defined what objects they were
    > allowed to operate on all this special purpose text goes away.
    >
    > It appears your enhancments request here would fit into this concept
    > nicely. The [] operator would be defined to be able to contain a list of
    > either integers or ranges.
    >
    > There are some difficult cases like:
    >
    > reg [10:0] r1;
    > reg [20:10] r2;
    > reg r;
    >
    > r = (r1 & r2)[3];
    >
    > What is the range of the expression (r1 & r2)? Is [3] a legal subscript
    > in this range?
    >
    > Either by defining such a range, or by disallowing subscripting on
    > expressions with a self-determined width, but no defined range these
    > could be handled.
    >
    > As someone who has invested a huge amount of time in clarifying the LRM,
    > I'ld love to hear your opinion on whether this change from operand to
    > operator would significantly simplify the LRM.
    >
    > Jay
    >
    > ===================================
    > Jay Lawrence
    > Senior Architect
    > Functional Verification
    > Cadence Design Systems, Inc.
    > (978) 262-6294
    > lawrence@cadence.com
    > ===================================
    >
    > > -----Original Message-----
    > > From: Shalom.Bresticker@motorola.com
    > > [mailto:Shalom.Bresticker@motorola.com]
    > > Sent: Friday, August 01, 2003 3:40 AM
    > > To: etf-bugs@boyd.com
    > > Subject: Re: enhancement/409: lists in part-selects
    > >
    > >
    > > Precedence: bulk
    > >
    > > The following reply was made to PR enhancement/409; it has
    > > been noted by GNATS.
    > >
    > > From: Shalom.Bresticker@motorola.com
    > > To: Steven Sharp <sharp@cadence.com>
    > > Cc: etf-bugs@boyd.com
    > > Subject: Re: enhancement/409: lists in part-selects
    > > Date: Fri, 1 Aug 2003 10:30:48 +0300 (IDT)
    > >
    > > > I would also like to point out that this is not a
    > > customer-vendor situation;
    > > > this is a standardization effort. As an individual
    > > representative, I feel
    > > > a responsibility to the long-term quality of the language
    > > and the interests
    > > > of the entire industry, not just the short-term goal of
    > > making a sale.
    > >
    > > I am also trying to consider "the interests of the entire
    > > industry" by looking
    > > at what designers actually need on a day-to-day basis.
    > >
    > > Sometimes people get so caught up in big revolutionary
    > > changes that they
    > > forget the little things which make a big difference in how good a
    > > tool really is.
    > >
    > > --
    > > Shalom Bresticker
    > > Shalom.Bresticker@motorola.com
    > > Design & Reuse Methodology Tel:
    > > +972 9 9522268
    > > Motorola Semiconductor Israel, Ltd. Fax:
    > > +972 9 9522890
    > > POB 2208, Herzlia 46120, ISRAEL Cell:
    > > +972 50 441478
    > >
    > >
     
     --
     Shalom Bresticker Shalom.Bresticker@motorola.com
     Design & Reuse Methodology Tel: +972 9 9522268
     Motorola Semiconductor Israel, Ltd. Fax: +972 9 9522890
     POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 441478
     
     
     

    This archive was generated by hypermail 2.1.4 : Sun Aug 03 2003 - 02:31:47 PDT and
    sponsored by Boyd Technology, Inc.