Subject: Re: [sv-ec] System include proposal
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Mar 11 2003 - 16:04:31 PST
> From Neil.Korpusik@eng.sun.com Tue Mar 11 14:40:26 2003
>
> > > - 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.
I was thinking more of cross-compiling.
Either way, I still view the two sets of files as distinct and think it
would be a bad idea to confuse them by using <> for both.
> Won't the "standard" include files we pre-defined such that you as a user
> would have no need to re-define them?
>
I would say yes if it wasn't for the fact that I've had to edit "system"
headers on Linux/Unix machine for compatibility issues before now.
> 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.
If you want to be able to do a (simple) direct 1-to-1 translation of the system
include files that the C compiler will use into SV and get the same behavior
for SV includes as C includes you're going to have to follow the convention
for the given platform/compiler. If different C compilers use different paths
and headers (e.g. SunPro vs GNU) then it's desirable that the paths are not
hard-coded into SV so that you can get the SV compiler to use the right set.
I think what I'd prefer to see is that vendors supply some useful subset
of the system headers (e.g. stdio,stdlib,unistd) which can be included with
<>, and that the location of <> can be redefined/extended by the user if
necessary. Tool specific include files would use [], and whichever you use
of <>,[],"" all locations would be searched so just using "" works fine unless
you have a name clash.
Just using [] (with Jay's semantics) for 3.1 and leaving <> available for 3.2
would be a reasonable compromise (in my opinion).
Kev.
> > 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 - 16:09:36 PST