Re: errata/474: First class part selection operator

From: Shalom.Bresticker@motorola.com
Date: Thu Sep 18 2003 - 00:10:00 PDT

  • Next message: Shalom.Bresticker@motorola.com: "Re: errata/82: Section 9.7.5: Description of @*, @(*) incomplete"

    Precedence: bulk

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

    From: Shalom.Bresticker@motorola.com
    To: etf-bugs@boyd.com
    Cc:
    Subject: Re: errata/474: First class part selection operator
    Date: Thu, 18 Sep 2003 10:57:34 +0300 (IDT)

     This is to attach the discussion from 409.
     
     Date: Fri, 1 Aug 2003 08:15:38 -0400
     From: Jay Lawrence <lawrence@cadence.com>
     To: Shalom Bresticker <Shalom.Bresticker@motorola.com>, etf-bugs@boyd.com
     Subject: RE: enhancement/409: lists in part-selects
     
     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'd love to hear your opinion on whether this change from operand to
     operator would significantly simplify the LRM.
     
     
     Date: Sun, 03 Aug 2003 12:19:52 +0300
     From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
     
     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.
     
     
     Date: Mon, 4 Aug 2003 10:11:57 -0700
     From: Michael McNamara <mac@verisity.com>
     
     In Appendix A, section 7.3 of tha ANSI C standard, C defines [] as one
     of its postfix operators (along with exp ++, exp --, exp -> id, exp
     . id, and exp () ).
     
     Hence in C you can do things like:
     
           char a = "hello world"[6];
     
           or
     
           a = m(6)[4]; // assuming m returns an array (or pointer);
     
     C++ goes further and allows you to overload the subscript operator []
     by saying:
     
     class X {
           X operator []() {
             //
           }
     }
     
     Java pulled back from that degree by removing the overload facility.
     
     Perl went further than C, but no overload; allowing appling this
     operator to anonymous arrays and hashes:
     
     $a = (1,2,3)[2];
     
     
     Date: Sun, 17 Aug 2003 17:28:57 +0300 (IDT)
     From: Shalom.Bresticker@motorola.com
     
     Coincidentally, I just saw the following on comp.lang.verilog:
     
     =========================================================================
     Subject: syntax question
            Date: Fri, 15 Aug 2003 14:37:20 -0700
            From: Ron Smith <rdsmith@sedona.intel.com>
      Newsgroups: comp.lang.verilog
     
     Why does this work:
     
     wire [1:0] foo,bar;
     
     assign {foo,bar}=4'b1000;
     
     at setting foo to 2'b10 and bar to 2'b00, but this gives a syntax error:
     
     wire [1:0] foo,bar;
     
     assign {foo,bar}=4'b0000;
     assign {foo,bar}[3]=1'b1;
     
     but this also works:
     
     wire [3:0] foobar;
     
     assign foobar=4'b0000;
     assign foobar[3]=1'b1;
     
     Please note that I'm not trying to argue over the finer points of style,
     the above is simply a trivial and overly simplistic example of something
     I tried that I thought "should" work, but of course it didn't.
     
     
     Date: Wed, 20 Aug 2003 11:38:55 -0700
     From: Michael McNamara <mac@verisity.com>
     
      In a language like perl assign {foo.bar}[3] = 1'b1; would work; and I
      believe it is a useful RFE for 1364 verilog. Again, one would
      discourage folks from typing the above directly; but it may be very
      useful to do:
     
      `define CPU_REG {mode,exception_mask,interrupt_mask,cpu_id}
     
     
      ...
     
      if ( `CPU_REG[5:0] == 6'b0 ) begin
        // we are the boot cpu; load the OS
        ...
      end
     
      which would expand to the same thing.
     

    This archive was generated by hypermail 2.1.4 : Thu Sep 18 2003 - 00:12:46 PDT and
    sponsored by Boyd Technology, Inc.