Subject: FW: Forward typedefs and file order dependancies
From: David W. Smith (david.smith@synopsys.com)
Date: Thu Aug 22 2002 - 11:35:02 PDT
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Kevin Cameron x3251
Sent: Thursday, August 22, 2002 11:26 AM
To: sv-ec@eda.org; burisch@co-design.com
Subject: Re: Forward typedefs and file order dependancies
> From owner-sv-ec@server.eda.org Thu Aug 22 08:12:23 2002
> To: sv-ec@server.eda.org
> From: "Christian Burisch" <burisch@co-design.com>
>
> Hi again,
>
> Here is an explanation why we allow forward typedefs:
>
> It is very common that you define a type in a file separate from where
> it
> is used. (The same applies to classes in C++.)
>
> It is horrible to have file order dependances, where your source files
> need to be specified in a particular order for the simulation to work.
>
> (If you have file order dependances you have a lot of unwanted
complexity
> if you use wild cards (*.v) because the order depends on the
filenames. If you
> use .f files then it gets tricky when you use multiple .f files or
even hierarchical
> ones. In short: file order dependances are highly undesirable.)
>
> Here are three ways to avoid file order dependances:
>
> 1) Let the simulator figure it out in a separate preprocessing pass
where each
> identifier is tagged to be a type, class, interface, variable etc.
> Pro: This is easiest and cleanest for the user
> Con: There are technical implementation difficulties in the
parser, which have
> to do with telling declarations from expressions.
> May make the code harder to read.
Con: It works against modular compilation, so although it is "easier" it
isn't
necessarily more efficient.
> 2) Use a C type `include structure where header files containing the
relevant typedefs
> and included at the top of each file.
> Pro: Works in C
> Con: Alien to Verilog. The file becomes a code partitioner.
Normally only modules or
> interfaces should partition the code. header files included
add complexity and
> in practise always contain many more declarations than
> strictly necessary.
Pro: Lets you do modular compile, much more efficient for small
localized changes.
> 3) Allow an empty typedef to tell the parser that the identifier is a
type which is
> defined later. For example you can use this, at the $root level or
inside a module
> or interface:
> typedef data_t; // defined later
> data_t a [7:0]; // data structure using this type
> Without having to worry about the place where data_t is defined.
>
> Pro: clean and readable solution. Not only tags the identifier to
be a type
> for the parser, but also for the people reading the code.
> Flexible, can be used together with Solution 2.
> Does not preclude Solution 1.
> Is absolutely necessary anyway, if the language is later
extended to support
> pointers, in order to be able to have two structs with
> pointers to each other.
Pointers are fixed size, only the code that dereferences the pointer
needs to know the structure of the object i.e. that is a different case
from declaring 'a' above.
> Con: Not much.
Con: Requires an extra pass through the source. Also, it might be
readable but reading
it doesn't tell you much.
> Cheerio,
> Christian
IMO this is way more trouble than it is worth. I'm bored watching VCS
spend minutes recompiling my entire Verilog source every time I make a
small change, I'd like something that's more efficient not less
efficient.
Kev.
This archive was generated by hypermail 2b28 : Thu Aug 22 2002 - 11:36:42 PDT