ISSUE 607

Number 607
Notify-List
Category errata
Synopsis function returning signed integer/real/time/realtime
State closed
Class duplicate
Arrival-DateJul 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