Re: [sv-ec] System include proposal


Subject: Re: [sv-ec] System include proposal
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Mar 11 2003 - 12:52:25 PST


----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 108

> From owner-sv-ec@server.eda.org Tue Mar 11 11:53:25 2003
>
> Hi Jay,
>
> I agree with the bulk of your proposal. I do however have some questions in the
> case of the <> syntax.
>
>
> According to the proposal, when the <> include syntax is specified only the
> "system-wide installation" is searched. In general, one would expect that
> only a filename would need to be specified in this situation.
>
> Do you foresee situations where an absolute or relative path would be
> useful here?
>
> It appears that a relative path specified with the <> syntax only makes
> sense if I am currently sitting in this "system-wide installation".
>
> What happens if I specify an absolute path that happens to not be part of
> this "system-wide installation"?
>
> Comments on suggestions made by others on the system-include proposal
>
> - Kevin's suggestion for using []
>
> The reasoning behind this suggestion appears to be flawed. If the concept
> of a Verilog system include file is adopted then all vendors that provide
> tools that parse Verilog files will need to provide these standard include
> files in their release package. The use of <> is a natural choice for these
> installation specific files. Vendors already provide OS specific releases.
> If a vendor wants to provide other "tool specific" includes these can also
> reside in this same release area. The "system specific" files that Kevin
> refers to correspond to the standard include files required by the LRM.

I would like (as Stephen Williams suggests) that <> behave exactly like the
C <> so that I can migrate C code through an SV translator. As you say the
directory searched for <> would probably be supplied by vendors, but as a
user I would like to be able to redirect it to my own version if necessary
- E.g. if I was Sun Micro and was testing a new machine/OS in simulation
(which vendors can't support yet).

Overloading <> for tool-specific includes makes it difficult to handle any
file-name clashes that turn up.

NB: you can have it that using <> searches the OS-specific directories first
then the tool-specific and then the users directories, in which case [] would
only be needed if there is a name clash (it would search tool-specific
directories first).

Kev.

   
> - Stephen William's suggestion for following the C-standard
>
> I did a google web search and found a copy of what appears to be the
> C-standard. Stephen is correct in stating that the C-standard is somewhat
> vague in its search path description. The following is an excerpt
> "...searches a sequence of implementation-defined places...". I don't think
> that we want to follow this approach and leave it up to the vendors to
> decide what the search order should be. The LRM should state the search order
> rules.
>
> Some C implementations allow <> to refer to user-written include files. When
> the user inadvertently chooses the same filename that happens to correspond
> to a file contained in the installation area the user-written file gets
> ignored. Debugging this situation can be time-consuming. Avoiding this
> situation, as you have done in your proposal, appears to be an improvement.
>
> - The C standard
>
> I attached the relevant section from the C-standard document located at
>
> http://std.dkuug.dk/JTC1/SC22/WG14/www/docs/n843.htm
>
> Neil
>
>
>
> > X-Unix-From: lawrence@cadence.com Mon Mar 10 04:52:52 2003
> > X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
> > content-class: urn:content-classes:message
> > MIME-Version: 1.0
> > Subject: [sv-ec] System include proposal
> > Date: Mon, 10 Mar 2003 07:52:04 -0500
> > X-MS-Has-Attach: yes
> > X-MS-TNEF-Correlator:
> > Thread-Topic: System include proposal
> > Thread-Index: AcLnA9lXonDf3ShqR2CJ8GTXe+LgMg==
> > From: "Jay Lawrence" <lawrence@cadence.com>
> > To: <sv-ec@eda.org>
> > X-Received: By mailgate.Cadence.COM as EAA00677 at Mon Mar 10 04:52:04 2003
> >
> >
> > Attached is the proposal on a system-wide include mechanism.
> >
> > Jay
> >
> >
> >
> >
> > ===================================
> > Jay Lawrence
> > Architect - Functional Verification
> > Cadence Design Systems, Inc.
> > (978) 262-6294
> > lawrence@cadence.com
> > ===================================

----------
X-Sun-Data-Type: text
X-Sun-Data-Name: c_standard.include
X-Sun-Encoding-Info: 7bit
Content-MD5: 4QNsdzz7MfAmc1a8Jb+fbw==
X-Sun-Charset: us-ascii
X-Sun-Content-Lines: 114

[ISO/] [IEC] JTC1/SC22/WG14 N843

                       Programming languages -- C

       
       6.10.2 Source file inclusion

       Constraints

       [#1] A #include directive shall identify a header or source
       file that can be processed by the implementation.

       Semantics

       [#2] A preprocessing directive of the form

         # include <h-char-sequence> new-line

       searches a sequence of implementation-defined places for a
       header identified uniquely by the specified sequence between
       the < and > delimiters, and causes the replacement of that
       directive by the entire contents of the header. How the
       places are specified or the header identified is
       implementation-defined.

       [#3] A preprocessing directive of the form

         # include "q-char-sequence" new-line

       causes the replacement of that directive by the entire
       contents of the source file identified by the specified
       sequence between the " delimiters. The named source file is
       searched for in an implementation-defined manner. If this
       search is not supported, or if the search fails, the
       directive is reprocessed as if it read

         # include <h-char-sequence> new-line

       with the identical contained sequence (including >
       characters, if any) from the original directive.

       [#4] A preprocessing directive of the form

         # include pp-tokens new-line

       (that does not match one of the two previous forms) is
       permitted. The preprocessing tokens after include in the
       directive are processed just as in normal text. (Each
       identifier currently defined as a macro name is replaced by

       ____________________

       132As indicated by the syntax, a preprocessing token shall
          not follow a #else or #endif directive before the
          terminating new-line character. However, comments may
          appear anywhere in a source file, including within a
          preprocessing directive.

       6.10.1 Language 6.10.2

       WG14/N843 Committee Draft -- August 3, 1998 165

       its replacement list of preprocessing tokens.) The
       directive resulting after all replacements shall match one
       of the two previous forms.133) The method by which a
       sequence of preprocessing tokens between a < and a >
       preprocessing token pair or a pair of " characters is
       combined into a single header name preprocessing token is
       implementation-defined.

       [#5] The implementation shall provide unique mappings for
       sequences consisting of one or more letters or digits (as
       defined in 5.2.1) followed by a period (.) and a single
       letter. The first character shall be a letter. The
       implementation may ignore the distinctions of alphabetical
       case and restrict the mapping to eight significant
       characters before the period.

       [#6] A #include preprocessing directive may appear in a
       source file that has been read because of a #include
       directive in another file, up to an implementation-defined
       nesting limit (see 5.2.4.1).

       [#7] EXAMPLE 1 The most common uses of #include
       preprocessing directives are as in the following:

         #include <stdio.h>
         #include "myprog.h"

       [#8] EXAMPLE 2 This illustrates macro-replaced #include
       directives:

         #if VERSION == 1
             #define INCFILE "vers1.h"
         #elif VERSION == 2
             #define INCFILE "vers2.h" // and so on
         #else
             #define INCFILE "versN.h"
         #endif
         #include INCFILE

       Forward references: macro replacement (6.10.3).

       ____________________

       133Note that adjacent string literals are not concatenated
          into a single string literal (see the translation phases
          in 5.1.1.2); thus, an expansion that results in two
          string literals is an invalid directive.

       6.10.2 Language 6.10.2

       166 Committee Draft -- August 3, 1998 WG14/N843



This archive was generated by hypermail 2b28 : Tue Mar 11 2003 - 12:54:13 PST