Subject: Re: [sv-ec] System Include Proposal - Version 2
From: Francoise Martinolle (fm@cadence.com)
Date: Thu Mar 13 2003 - 08:56:22 PST
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 - 08:57:28 PST