Re: [sv-bc] precedence of :/ vs. //

From: Arturo Salz <Arturo.Salz@synopsys.com>
Date: Thu Aug 26 2004 - 16:26:23 PDT

I disagree with this conclusion.

The "://" should be tokenized the same way by both Verilog-2001
and SystemVerilog scanners. In all cases "://" should be scanned
as the two tokens ":" and "//". The only difference should be that
a ":/" token has a meaning only in SystemVerilog.

The potential ambiguity is easily resolved at the lexical analysis level
by giving higher precedence to the ":". This is similar to the potential
ambiguity between the AMS operator "+=>" and the SystemVerilog
"+=" operator. In this case, the scanner must also select tokens in a
consistent manner.

    Arturo

----- Original Message -----
From: <Hermann.Ilmberger@infineon.com>
To: <pgraham@cadence.com>
Cc: <sv-bc@eda.org>
Sent: Thursday, August 26, 2004 2:39 AM
Subject: RE: [sv-bc] precedence of :/ vs. //

>
> > However, if your tool has a Verilog2001 mode and a
> SystemVerilog mode,
> > the :// in your example would have to be preprocessed as
> > : // (2 tokens) for 2001, and as
> > :// (1 token) for SystemVerilog.
>
> What do you mean that "://" is one token in SystemVerilog? I
> don't see any "://" token in the lrm. (Or has one been added
> since 3.1a draft 6?)

Sorry - I scanned one / to much. This all looks like smilies.
:// has to be scanned as
: // (2 tokens) for 2001, and as
:/ / (2 tokens) for SystemVerilog
when we assume C++ LRM rules.
>
> The problem is that SystemVerilog needs to be backwards
> compatible (as much as possible) with standard Verilog. I
> ran across this "://" problem in an existing verilog test case.

I had the same problem. :// is un-compatible, and if there is still a
possibility
we should find a better name which does not break old Verilog.
-Hermann

>
> The "///" problem wasn't an issue for C/C++ since "///" could
> never occur in a valid C program (except within a /* ... */ comment).
>
> Paul
>
Received on Thu Aug 26 16:26:28 2004

This archive was generated by hypermail 2.1.8 : Thu Aug 26 2004 - 16:26:55 PDT