Subject: RE: [sv-ec] System Include Proposal - Version 2
From: Jay Lawrence (lawrence@cadence.com)
Date: Thu Mar 13 2003 - 09:00:47 PST
The proposal says that "" is unchanged from 1364 and all vendors provide
+incdir like functionality today. If we want to clean up that wording it
should be done in the 1364 ETF, not sv-ec.
I explicitly exclude having +incdir affect the <> syntax so that vendors
control where the files are and the user can't play around trying to
substitute their own copies of them. If you use <> you get the language
defined headers. If you want user defined headers use "".
Jay
===================================
Jay Lawrence
Architect - Functional Verification
Cadence Design Systems, Inc.
(978) 262-6294
lawrence@cadence.com
===================================
> -----Original Message-----
> From: Francoise Martinolle
> Sent: Thursday, March 13, 2003 11:56 AM
> To: Jay Lawrence; sv-ec
> Subject: Re: [sv-ec] System Include Proposal - Version 2
>
>
> Shouldn't we also add in the proposal that the list of the
> directories
> searched for "" or <> can be altered in some vendor specific
> way (I am
> thinking of for example the +incdir option).
>
> . At 09:33 AM 3/13/2003 -0500, Jay Lawrence wrote:
>
> >Here is a second shot at the system include proposal.
> >
> >This proposal extends the Verilog 1364 include mechanism to define an
> >installation specific include mechanism. This is provided
> so that the
> >language standard can use the include mechanism to refer to standard
> >extensions to the language that are available in source
> form. Typically
> >a vendor will provide a tool installation to the customer, embedded
> >within this tool installation or at some other vendor known
> location,
> >the standard language extensions should be found.
> >
> >Various comments have been made over the last few days which
> have caused
> >me to actually simplify the proposal even more to make it clear and
> >unambiguous. A paraphrase of each of the comments and my response is
> >given here. Hopefully this will accellerate discussion of
> the proposal
> >in Friday's meeting so we can get it behind us. Following these
> >comments a new version of the proposal is given.
> >
> >Jay
> >
> >-----------------------------
> >Comment 1: (in sv-ec meeting)
> >-----------------------------
> >
> > - Don't change the behavior of "file"
> >
> >I agree, the searching of the system include after the -I lines might
> >cause backward compatibility problems and is just not worth
> changing.
> >The proposal now states that "file" is unchanged.
> >
> >-------------------------
> >Comment 2: Stephen Willis
> >-------------------------
> >
> > - I believe if you are introducing a C-like
> feature, you should
> >follow C-like practice as well. Maybe even extract the description
> >from the C standard?
> >
> >So far I've found 3 different definitions of how this works with GNU,
> >Visual Studio, and SunWSPro. If there was one consistent
> definition I
> >would agree with this comment whole heartedly, but alas there is not
> >one. I've simplified the proposal so that <> only searches
> the system
> >include area.
> >
> >-------------------------------
> >Comment 3: Kevin Cameron
> >-------------------------------
> >
> > - Use [] instead of <>. This was suggested to separate
> >OS-specific includes from tool specific includes.
> >
> >This proposal only deals with code defined by the language
> standard. If
> >there are OS specific extensions to the language standard
> in the future
> >then they will also live here. Kevin continues to want to
> share 'C' and
> >'SV' headers after running them through a pre-processor. I would
> >suggest you can do this by just defining your own -I
> directory that you
> >place the pre-processed headers in and reference them with
> the existing
> >"file" syntax like any other source in your design.
> >
> >-----------------------------------------------
> >Comment 4: on sv-ec mailing list (I forget who)
> >-----------------------------------------------
> >
> > - How do I provide my own copy of these?
> >
> >We may want to address this with further wording in the Annex'es for
> >each element, but it is not pertinent to the semantics of <>. One
> >important point is that for Lists the body of the methods is not
> >provided. This leaves a vendor the ability to provide an optimized
> >implementation that could not be written in SystemVerilog, providing
> >your own bodies would either cause them to be ignored or cause severe
> >performance penalties. User's always try to do this in VHDL and it is
> >always a disaster (providing there own version of STD
> packages). To use
> >your own version a different name in a diffent directory is
> the safest
> >course (It may inherit the standard class).
> >
> >------------------------
> >Comment 5: Neil Korpusik
> >------------------------
> >
> > - Why provide relative paths under <>?
> >
> >This is just a more generic extension. Just like 'C' allows
> >
> > #include <sys/signal.h>
> >
> >As the amount of code grows under <> it may make sense to
> divide it up
> >by subdirectories in the standard itself.
> >
> > `include <types/list.vh>
> > `include <types/semaphore.vh>
> > `include <math/trig.vh>
> >
> >----------------------
> >Comment 6: Brad Pierce
> >----------------------
> >
> > - The syntax is incomplete because it doesn't handle macros
> >
> >No Verilog syntax explicitly calls out macros. They can be used
> >anywhere, anytime.
> >
> >--------------------
> >Proposal - Version 2
> >--------------------
> >
> >The syntax of the include compiler directive will be as follows:
> >
> > include_compiler_directive ::=
> > `include "filename"
> > | `include <filename>
> >
> >When the filename is an absolute path, only that filename is included
> >and only the double quote form of the `include can be used.
> >
> >When the double quote ("filename") version is used, the behavior of
> >`include is unchanged from Verilog-1364.
> >
> >When the angle bracket ("<>") notation is used, then only the vendor
> >defined location containing files defined by the language
> standard is
> >searched. Relative pathnames given inside the <> are interpreted
> >relative to the vendor-defined location in all cases.
> >
> >
> >
> >===================================
> >Jay Lawrence
> >Architect - Functional Verification
> >Cadence Design Systems, Inc.
> >(978) 262-6294
> >lawrence@cadence.com
> >===================================
>
>
This archive was generated by hypermail 2b28 : Thu Mar 13 2003 - 09:03:07 PST