| Number | 607
|
| Notify-List |
|
| Category | errata
|
| Synopsis | function returning signed integer/real/time/realtime
|
| State | closed
|
| Class | duplicate
|
| Arrival-Date | Jul 29 2004
|
| Originator | Eric Mahurin
|
| Release |
|
| Environment |
I'm about to bombard you with some more errata items. It's almost as though nobody has built a parser based directly on the BNF in the spec. Or maybe they didn't report the errors. In A.2.6, a function starts like this: function [ automatic ] [ signed ] [ range_or_type ] where range_or_type include integer|real|realtime|time Nowhere else can the "signed" keyword be used with these types. I assume this is not what was intended, but if it is, what would "signed" mean with these? |
| Description |
|
| Fix |
CLOSE as duplicate of issue #554. The P1800 has voted to close this issue 10/26/04 |
| Audit-Trail |
From: "Brad Pierce" <Brad.Pierce@synopsys.com> To: <etf-bugs@boyd.com> Cc: Subject: RE: errata/607: function returning signed integer/real/time/realtime Date: Thu, 29 Jul 2004 17:45:38 -0700 This is a duplicate of issue 554. In the SystemVerilog BNF, this bug was already fixed by LRM-292. See the following http://www.eda.org/sv-bc/hm/att-1638/subroutine_prototype_bnf.htm -- Brad From: Eric Mahurin <eric_mahurin@yahoo.com> To: Brad Pierce <Brad.Pierce@synopsys.com>, etf-bugs@boyd.com Cc: Subject: RE: errata/607: function returning signed integer/real/time/realtime Date: Thu, 29 Jul 2004 18:52:57 -0700 (PDT) Sorry - I missed that. --- Brad Pierce <Brad.Pierce@synopsys.com> wrote: > The following reply was made to PR errata/607; it > has been noted by GNATS. > > From: "Brad Pierce" <Brad.Pierce@synopsys.com> > To: <etf-bugs@boyd.com> > Cc: > Subject: RE: errata/607: function returning signed > integer/real/time/realtime > Date: Thu, 29 Jul 2004 17:45:38 -0700 > > This is a duplicate of issue 554. In the > SystemVerilog BNF, > this bug was already fixed by LRM-292. See the > following > > > http://www.eda.org/sv-bc/hm/att-1638/subroutine_prototype_bnf.htm > > -- Brad > > > > _______________________________ Do you Yahoo!? Express yourself with Y! Messenger! Free. Download now. http://messenger.yahoo.com From: Shalom.Bresticker@freescale.com To: eric_mahurin@yahoo.com Cc: etf-bugs@boyd.com Subject: Re: errata/607: function returning signed integer/real/time/realtime Date: Fri, 30 Jul 2004 12:09:17 +0300 (IDT) Eric, The BNF most definitely is not sufficient by itself for a parser. Not every syntax allowed by the BNF is actually legal. That was a deliberate decision of the Working Group. I think that in most of those cases, the text of the LRM contains additional restrictions. Shalom > I'm about to bombard you with some more errata items. It's almost as though nobody has built a parser based directly on the BNF in the spec. Or maybe they didn't report the errors. -- 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 From: Eric Mahurin <eric_mahurin@yahoo.com> To: etf-bugs@boyd.com Cc: Subject: Re: errata/607: function returning signed integer/real/time/realtime Date: Fri, 30 Jul 2004 09:18:44 -0700 (PDT) To write a lenient parser that accepts all legal syntax, the BNF is quite close. That is what I've been doing and reporting the issues. I think the issues I'm finding can be broken down into these categories: 1. doesn't allow some valid syntax. Examples: extra semicolons in PATHPULSE constructs; inconsistent mintypmax usage. 2. doesn't group items meaningful to the language. Examples: expression/event_expression (no regards to operator precedence) 3. redundancies/ambiguities. Examples: #2 issues typically also are ambiguous; in A.6.2 "force" can take a net_assignment or a variable_assignment, but syntactically net_assignment is a subset of variable_assignment; if_else_if alternative for a conditional statement. I'll document these next. 4. inconsistencies in the leniency. This really doesn't hinder making the parser. Example: this errata (function allowing the return signed integers/etc when nothing else allows it) 5. lower-level token/whitespace/preprocessor issues (lexical analysis). I know this isn't part of the BNF, but having something solid here is necessary for the parser. Examples: all of the compiler directive questions I've had. I think you can break down the LRM in terms of a parsing and understanding meaning into these categories: - tokens/whitespace/preprocessor stuff: lexical analysis - BNF: syntactic analysis - all other qualifications in the LRM: semantic qualifications. Some of these can be handled during the parsing phase, but most will need to be done later (or checking after parsing an entire construct - i.e. module) --- Shalom.Bresticker@freescale.com wrote: > The BNF most definitely is not sufficient by itself > for a parser. > Not every syntax allowed by the BNF is actually > legal. > That was a deliberate decision of the Working > Group. > I think that in most of those cases, the text of > the LRM contains additional > restrictions. > > Shalom > > > > I'm about to bombard you with some more errata > items. It's almost as though nobody has built a > parser based directly on the BNF in the spec. Or > maybe they didn't report the errors. > __________________________________ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail Fix replaced by Shalom.Bresticker@freescale.com on Sun Aug 1 08:05:02 2004 CLOSE as duplicate of issue #554. |
| Unformatted |
|
Hosted by Boyd Technology