ISSUE 3

Number 3
Category errata
Synopsis 10.3.5: Inconsistent restrictions on system tasks in constant functions
State lrmdraft
Class errata-discuss
Arrival-DateJul 21 2001
Originator Shalom Bresticker, Motorola
Release 2001b: 10.3.5
Environment
Description
In Section 10.3.5 ("Use of constant functions"),
the following constraints appear:

- All system tasks within a constant function shall be ignored.

- The only system task that may be invoked is $display,
and it shall be ignored when invoked at elaboration time.

The two appear inconsistent. Only one should appear.
Fix

Delete 5th bullet:

- The only system task that may be invoked is $display,
and it shall be ignored when invoked at elaboration time.

If there is a another issue regarding constant functions,
a new erratum entry should be filed.

Audit-Trail

From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: btf-bugs@boyd.com
Cc:
Subject: Re: errata/3: Inconsistent restrictions on system tasks in constant
functions
Date: Thu, 11 Oct 2001 17:06:42 +0200

--------------2451956E7969EEA5157A258B
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

The first is correct.
The second should be deleted.
I found this in a mail from Yatin that accompanied Draft 6.
The change was not done properly.

Shalom


Shalom.Bresticker@motorola.com wrote:

> In Section 10.3.5 ("Use of constant functions"),
> the following constraints appear:
>
> - All system tasks within a constant function shall be ignored.
>
> - The only system task that may be invoked is $display,
> and it shall be ignored when invoked at elaboration time.
>
> The two appear inconsistent. Only one should appear.

--
**************************************************************************
Shalom Bresticker Shalom.Bresticker@motorola.com
Motorola Semiconductor Israel, Ltd. Tel #: +972 9 9522268
P.O.B. 2208, Herzlia 46120, ISRAEL Fax #: +972 9 9522890
**************************************************************************



--------------2451956E7969EEA5157A258B
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!doctype html public "-//w3c//dtd html 4.0 transitional//en">

The first is correct.

The second should be deleted.

I found this in a mail from Yatin that accompanied Draft 6.

The change was not done properly.

Shalom

 

Shalom.Bresticker@motorola.com wrote:
<blockquote TYPE=CITE>In Section 10.3.5 ("Use of constant functions"),

the following constraints appear:

- All system tasks within a constant function shall be ignored.

- The only system task that may be invoked is $display,

and it shall be ignored when invoked at elaboration time.

The two appear inconsistent. Only one should appear. 

-- 
 **************************************************************************
 Shalom Bresticker                           Shalom.Bresticker@motorola.com
 Motorola Semiconductor Israel, Ltd.                  Tel #: +972 9 9522268
 P.O.B. 2208, Herzlia 46120, ISRAEL                   Fax #: +972 9 9522890
 **************************************************************************

 

--------------2451956E7969EEA5157A258B--


From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/3: Inconsistent restrictions on system tasks in constant
functions
Date: Tue, 27 Aug 2002 11:51:16 +0300

Update from ETF meeting 2002-08-12:

1. The original erratum entry refers to section 10.3.5. It says,

"Constant functions ... shall meet the following constraints:"

Bullet 3 then says, "All system tasks .. shall be ignored."

Bullet 5 says, "The only system task that may be invoked is $display,
and it shall be ignored when invoked at elaboration time."

These two bullets are contradictory.


2. The source of the problem was traced to an improper correction
from Draft 5 to Draft 6.

Draft 5 was the original ballot version.
In that version, bullets 3 and 4 did not exist.
Draft 6's bullet 5 was bullet 3 in Draft 5.

Cadence objected to that bullet in ballot comment CDS09,
"What is special about $display?".

The WG resolution to that comment was supposed to be replacing that
bullet
with two new bullets, which appear as bullets 3 and 4 in Draft 6,
allowing, but ignoring, all system tasks.

This was documented in a mail from Yatin Trivedi to 1364 WG on
2000-12-04,
containing all ballot comments and their resolutions in an .xls file.
It was not to the BTF, so it is not in BTF archives.
I have a copy of the mail and the .xls file.

The correction was incorrectly made.
The two new bullets were added, but the original bullet referencing
$display
was not deleted.


3. If we had left the WG ballot resolution as is, it would be a simple
erratum.
However, in the ETF meeting on 2002-08-12, the entire subject came up
for reconsideration.
I understood the issues as follows:
Should system tasks be allowed at all in constant functions?
How can the compiler distinguish between constant functions
and regular functions, and thereby apply different rules to them?

Shalom



From: Shalom.Bresticker@motorola.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/3: Inconsistent restrictions on system tasks in constant
functions (fwd)
Date: Sun, 27 Apr 2003 18:40:03 +0300 (IDT)

Considering that we are not currently working on this issue, and there is an
open contradiction in the LRM, and it is known that the VSG once decided on a
particular resolution and that the contradiction is a result of a mistake in
editing the LRM, and that we are about to start publishing drafts, and we have a
chance to quickly issue a revision of 1364-2001 with errata corrections,

THEREFORE I propose that we accept for now the past decision of the VSG (to
delete bullet 5), and simultaneously open a new issue for re-examination of the
constant function issue.

Shalom


---------- Forwarded message ----------
Date: Tue, 27 Aug 2002 11:51:16 +0300

Update from ETF meeting 2002-08-12:

1. The original erratum entry refers to section 10.3.5. It says,

"Constant functions ... shall meet the following constraints:"

Bullet 3 then says, "All system tasks .. shall be ignored."

Bullet 5 says, "The only system task that may be invoked is $display,
and it shall be ignored when invoked at elaboration time."

These two bullets are contradictory.


2. The source of the problem was traced to an improper correction
from Draft 5 to Draft 6.

Draft 5 was the original ballot version.
In that version, bullets 3 and 4 did not exist.
Draft 6's bullet 5 was bullet 3 in Draft 5.

Cadence objected to that bullet in ballot comment CDS09,
"What is special about $display?".

The WG resolution to that comment was supposed to be replacing that
bullet
with two new bullets, which appear as bullets 3 and 4 in Draft 6,
allowing, but ignoring, all system tasks.

This was documented in a mail from Yatin Trivedi to 1364 WG on
2000-12-04,
containing all ballot comments and their resolutions in an .xls file.
It was not to the BTF, so it is not in BTF archives.
I have a copy of the mail and the .xls file.

The correction was incorrectly made.
The two new bullets were added, but the original bullet referencing
$display
was not deleted.


3. If we had left the WG ballot resolution as is, it would be a simple
erratum.
However, in the ETF meeting on 2002-08-12, the entire subject came up
for reconsideration.
I understood the issues as follows:
Should system tasks be allowed at all in constant functions?
How can the compiler distinguish between constant functions
and regular functions, and thereby apply different rules to them?

Shalom


From: Steven Sharp <sharp@cadence.com>
To: etf-bugs@boyd.com, Shalom.Bresticker@motorola.com
Cc:
Subject: Re: errata/3: Inconsistent restrictions on system tasks in constant functions (fwd)
Date: Mon, 28 Apr 2003 21:38:59 -0400 (EDT)

> I understood the issues as follows:
> Should system tasks be allowed at all in constant functions?
> How can the compiler distinguish between constant functions
> and regular functions, and thereby apply different rules to them?

This second question isn't a problem, though the text may be confusing.

It is a use of the function in an expression that is required to be a
constant expression that creates the requirement that the function follow
those different rules. The text isn't very clear about whether the term
"constant function" refers to a function used in such a context, or a
function eligible to be used in such a context. However, it is clear what
the behavior needs to be. Any function used in such a context must meet
the restrictions. Any other function doesn't have to.

The compiler can check the restrictions and mark each function as eligible
or not when it parses them, and then produce an error later when it processes
constant expressions and finds an ineligible function. Or it can wait until
it sees the function used in a constant expression and then go do the checks
and produce an error if it doesn't satisfy the restrictions. Different
approaches may give better compile speed versus better errors, but it can be
implemented.

Constant functions have some problems, but this isn't one of the serious ones.

Steven Sharp
sharp@cadence.com


From: Shalom Bresticker <Shalom.Bresticker@motorola.com>
To: Steven Sharp <sharp@cadence.com>
Cc: etf-bugs@boyd.com
Subject: Re: errata/3: Inconsistent restrictions on system tasks in constant
functions (fwd)
Date: Wed, 30 Apr 2003 12:40:45 +0300

I agree with you, but that was how I understood the discussion.
My understanding of compilers is limited, so maybe I did not understand
correctly.
My proposal still stands, to correct the existing contradiction according to what
was SUPPOSED to be in Draft 6,
and open a new issue on constant functions, if needed.

Shalom


Steven Sharp wrote:

> > I understood the issues as follows:
> > Should system tasks be allowed at all in constant functions?
> > How can the compiler distinguish between constant functions
> > and regular functions, and thereby apply different rules to them?
>
> This second question isn't a problem, though the text may be confusing.
>
> It is a use of the function in an expression that is required to be a
> constant expression that creates the requirement that the function follow
> those different rules. The text isn't very clear about whether the term
> "constant function" refers to a function used in such a context, or a
> function eligible to be used in such a context. However, it is clear what
> the behavior needs to be. Any function used in such a context must meet
> the restrictions. Any other function doesn't have to.
>
> The compiler can check the restrictions and mark each function as eligible
> or not when it parses them, and then produce an error later when it processes
> constant expressions and finds an ineligible function. Or it can wait until
> it sees the function used in a constant expression and then go do the checks
> and produce an error if it doesn't satisfy the restrictions. Different
> approaches may give better compile speed versus better errors, but it can be
> implemented.
>
> Constant functions have some problems, but this isn't one of the serious ones.
>
> Steven Sharp
> sharp@cadence.com

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



Unformatted



Hosted by Boyd Technology