From: Shalom.Bresticker@motorola.com
Date: Fri Apr 25 2003 - 03:10:07 PDT
Precedence: bulk
The following reply was made to PR errata/16; it has been noted by GNATS.
From: Shalom.Bresticker@motorola.com
To: etf-bugs@boyd.com
Cc:
Subject: Re: errata/16: 19.7 `line - meaning of level parameter is unclear
Date: Fri, 25 Apr 2003 13:01:59 +0300 (IDT)
The following was the original complaint:
> In 19.7 (`line): "The level parameter indicates whether an
> include file has been entered (value is 1), an include file
> is existed (value is 2), or neither has been done(value is 0)."
>
> This sentence is incomprehensible to me.
>
> At the very least, an example or examples must be added.
A long discussion followed.
I have reviewed all the discussion and most of the original correspondence which
led to its addition to 1364-2001 (It was Enhancement B29, see BTF archives from
Jan,Apr,Jul 1999).
I will try to summarize here what I have learned and concluded, and propose
a resolution which only minimally affects the standard.
Read section 19.7 of the LRM before the following.
The form of `line is:
`line number "filename" level
'line was derived from the combination of a similar CPP input directive and CPP
output linemarkers. If that sounds confusing, that's because it is.
The SunOs 5.7 CPP man page says,
"Output consists of a copy of the input file, with modifications, plus lines of
the form:
#lineno "filename" "level"
indicating the original source line number and filename of the following output
line and whether this is the first such line after an include file has been
entered (level=1), the first such line after an include file has been exited
(level=2), or any other such line (level is empty)."
Note that lineno is the actual line number, not the literal string "lineno".
So `line is basically copying this CPP output, with minor variations.
What you also have to know to complete the picture, but confuse you completely,
is that there is also a CPP INPUT directive,
#line lineno "filename"
where "filename" is optional. No additional tokens are permitted on the
directive line after the #line directive.
(1) The intent of `line is to represent the OUTPUT of a Verilog
pre-processor/source-to-source/verilog-to-verilog translator,
such as a code coverage tool which instruments the input files,
both to deal with include files and to deal with lines added or deleted by the
translator, causing the line numbering of the output files to differ from those
of the input files.
It is assumed that the translator is intelligent and bug-free, and does not
insert nonsense into the `line directives.
'line is NOT intended to be a compiler directive manually inserted by the user.
This was not clear from 19.7 as currently worded. A sentence needs to be added
to that effect.
Note that the use of the directive is optional.
(2) All the arguments of the directive are required. This simplifies parsing.
The directive may be spread over more than one line.
However, there is an ambiguity about what follows the directive.
The LRM says that the "number parameter is the new line number of the next
line." What happens if there is code text following the directive on the same
line?
In order to prevent that ambiguity, I propose that the LRM not allow any code,
except maybe a one-line comment, following the directive on the same line.
Note that this overlaps issue #90.
(3) Small editorial improvements: in 19.7, para. 1:
- Change "reset the current line number" to "set the current line number".
- Change "file; if" to "file if".
- Change "addition or reduction of lines" to "addition or deletion of lines".
- Change "For example error messages" to "For example, error messages".
(4) In para. 3, change
"The level parameter indicates whether an include file has been entered (value is 1),
an include file is existed (value is 2), or neither has been done (value is 0)."
TO:
"The level parameter indicates the following line is the first line after an include
file has been entered (level=1), the first line after an include file has been
exited (level=2), or any other such line (level=0)."
(5) The LRM says, "The filename can be a full or relative path name."
In point of fact, the filename parameter can be any string, even nonsense.
The Verilog compiler and PLI will not know the difference unless they try to
access the file. However, the LRM is trying to explain the intention.
Recommend no change.
(6) Add a couple of examples.
This archive was generated by hypermail 2.1.4
: Fri Apr 25 2003 - 03:11:10 PDT
and
sponsored by Boyd Technology, Inc.