Subject: Re: Forward typedefs and file order dependancies
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Aug 22 2002 - 11:25:47 PDT
> 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:28:14 PDT