Brad, you are right about '##1' not being in tables 16-24 or 16-25. '##' is however. '##' is not an operator in its own right. I think it is there to represent the whole family of operators ##0, ##1, .. ##[0:1], ... I don't think we need to specify the syntax furher. Right now in parsers like Verific's a ##1 b throughout c will parse as a ##1 (b throughout c) and a throughout b ##1 c will parse as a throughout (b ##1 c) It is thus only in the second parse that the higher precedence of ##1 over throughout takes effect. I don't see this as a problem. It is probably what the user might expect. However there was the opinion voiced in the committee that the first parse should result in a syntax error given the fact that ##1 has higher precedence than throughout and that '(a ##1 b) throughout c' is a syntax error. I just wanted to hear your opinion on that view. Best Regards, Johan M On Wed, Jan 16, 2008 at 10:15:40AM -0800, Brad Pierce wrote: > Johan, > > It might be that this unclearness about precedence (Table 16-25) is pointing to a need for a level of factoring in sequence_expr, analogous to expression and primary in A.8.3 and A.8.4. > > That BNF is roughly > > expression ::= > > primary > > | unary_operator primary > > | expression binary_operator expression > > ... > > > > primary ::= > > literal > > | ( expression ) > > | concatenation > > ... > > > > For example, sequence_expr might be factored as > > sequence_expr ::= > > [ cycle_delay_range_list ] sequence_term > > { cycle_delay_range_list sequence_term } > > | sequence_expr and sequence_expr > > | sequence_expr intersect sequence_expr > > | sequence_expr or sequence_expr > > | expression throughout sequence_expr > > | sequence_expr within sequence_expr > > | clocking_event sequence_expr { ##1 clocking_event sequence_expr } > > > > cycle_delay_range_list ::= > > cycle_delay_range { cycle_delay_range } > > > > sequence_term ::= > > expression_or_dist [ boolean_abbrev ] > > | sequence_instance [ sequence_abbrev ] > > | ( sequence_expr { , sequence_match_item } ) [ sequence_abbrev ] > > | first_match ( sequence_expr ) > > > > The appropriate factoring depends on the intent, which is hard for me to puzzle out. For example, 16.13.1 says that ##1 is an operator, yet ##1 is not in Table 16-24 or Table 16-25. > > Before considering Table 16-25, does something like the above factoring make sense, or is my thinking about this on the wrong track? > > Thanks, > > -- Brad > > [ In reply to http://www.eda-stds.org/sv-ac/hm/6556.html . ] > > > > -----Original Message----- > From: Johan Mårtensson [mailto:johan.martensson@jasper-da.com <mailto:johan.martensson@jasper-da.com> ] > Sent: Wednesday, January 16, 2008 1:30 AM > To: brad.pierce@synopsys.COM > Cc: sv-ac@eda.org > Subject: Question about the semantics of operator precedences > > Hi Brad, > > I was told by John Havlicek that you would be the right person to ask the kind of question I am going to ask. > > In SV-AC we are working on the addition of some property operators and we have got stuck a little in a discussion on the meaning of operator precedences as they are stated in the SV LRM. > > Consider the following example > > 1) a ##1 b throughout s > > The productions for ##1 and throughout are (somewhat simplified) > > sequence_expr ::= > | expression > ... > | sequence_expr ##1 sequence_expr > ... > | expression throughout sequence_expr > .... > > Let a and b be expressions and s a sequence_expr. 'a ##1 b' is not an expression so the only grouping which is not a syntax error is > > 2) a ##1 (b throughout s) > > Now in the precedence table (Table 16-25 in D4) ##1 is given higher precedence than 'throughout'. > > a) According to my understanding because of the way an LR1 parser works (1) will be grouped as (2) regardless of the relative precedences of '##1' > and 'throughout'. I.e. the precedence rules will only be used when there is a conflict between two syntactically legal groupings, for example in a shift-reduce conflict. > > b) On the other hand one could (as some people on the committee do) interpret the precedence rules to imply that (1) is a syntax error, because the rules would favor the grouping '(a ##1 b) throughout s'. > > The question is, should the precedence rules as stated in the LRM be interpreted on the lines of (a) or of (b)? > > Best Regards, > > Johan Mårtensson > > > -- > ------------------------------------------------------------ > Johan Mårtensson Office: +46 31 7451913 > Jasper Design Automation Mobile: +46 703749681 > Kvarnbergsgatan 2 Fax: +46 31 7451914 > 411 05 Gothenburg, Sweden Skype ID: johanmartensson > ------------------------------------------------------------ > > Content-Description: RE Question about the semantics of operator precedences.htm -- ------------------------------------------------------------ Johan Mårtensson Office: +46 31 7451913 Jasper Design Automation Mobile: +46 703749681 Kvarnbergsgatan 2 Fax: +46 31 7451914 411 05 Gothenburg, Sweden Skype ID: johanmartensson ------------------------------------------------------------ -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Jan 17 04:57:30 2008
This archive was generated by hypermail 2.1.8 : Thu Jan 17 2008 - 04:58:14 PST