[Fwd: Parsing @* (was Re: "always" block)]

From: Shalom Bresticker (Shalom.Bresticker@freescale.com)
Date: Sat Jul 10 2004 - 22:57:32 PDT

  • Next message: Shalom.Bresticker@freescale.com: "Re: Minutes of the 6/28/04 meeting" 

    --
Shalom Bresticker                        Shalom.Bresticker @freescale.com
Design & Reuse Methodology                           Tel: +972 9  9522268
Freescale Semiconductor Israel, Ltd.                 Fax: +972 9  9522890
POB 2208, Herzlia 46120, ISRAEL                     Cell: +972 50 5441478

    [ ]Freescale Internal Use Only      [ ]Freescale Confidential Proprietary

    attached mail follows:

    I think the rant was more that other tools don't always get the @(*)
    parsing right, particularly in more subtle cases, and in getting it
    wrong make the feature more problematic.

    While I agree that with a competent lexer and parser generator it
    isn't too difficult to get the parsing mostly correct, I'm not so
    certain about entirely correct. As a result, I'm not surprised that
    some vendors get it subtly wrong, given that there are several almost
    hacks that come close. For example, the case of code like:
        `define empty
        always @(*`empty)
    is tricky if one does maximal munch and one wants to treat (* as a
    single token when appropriate. Are you really certain, you have all
    the cases where something can become syntacticly invisible between
    the (* and the ). I, myself, haven't implemented that 2001 extension,
    but I won't be surprised if there isn't some subtle case that I miss.

    Moeover, I think the point about differing behaviors with respect to
    tokenizing (* as one token or as two are correct. There are simply a
    different set of tricky issues is you lex (* as two tokens and put
    them together in the parser and if you remove whitespace and/or
    comments in your lexer.

    The sad part of this is that distinguishing the various obscure cases
    of (* of how it should be parsed are probably not the best uses of
    ones time in general. Most of us have more important tasks.
    Unfortunately, it will be some poor user who has a piece of Verilog
    that falls on different sides of the crack with two different tools
    who suffers in the end.

    Hope this helps,
    -Chris

    *****************************************************************************
    Chris Clark Internet : compres@world.std.com
    Compiler Resources, Inc. Web Site : http://world.std.com/~compres
    23 Bailey Rd voice : (508) 435-5016
    Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
    ------------------------------------------------------------------------------

    This archive was generated by hypermail 2.1.4 : Sat Jul 10 2004 - 22:54:57 PDT and
    sponsored by Boyd Technology, Inc.