[sv-ac] RE: Question about the semantics of operator precedences

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
------------------------------------------------------------



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.