Subject: Re: [sv-ec] System include proposal
From: Neil Korpusik (Neil.Korpusik@eng.sun.com)
Date: Tue Mar 11 2003 - 14:40:20 PST
> > - 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).
If the vendors don't support that OS and you want to run simulations on that
OS, you would only be able to run your own simulator, which would presumably
provide you with an installation area that contains the standard include files.
As a user you should have no need to use your own version of the standard
include files.
Won't the "standard" include files we pre-defined such that you as a user
would have no need to re-define them?
The C standard says
[#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.
It sounds like you are suggesting that the vendors determine what the
"sequence of implementation-defined places" are for each OS and do the
same thing. This doesn't sound like a very good idea to me. Having a
well-defined search order should simplify matters for the users.
> 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 - 14:42:04 PST