Subject: RE: Forward typedefs and file order dependancies
From: David W. Smith (david.smith@synopsys.com)
Date: Thu Aug 22 2002 - 10:09:30 PDT
Should this discussion be forwarded to the SV-BC where I believe this
issue was raised?
Regards
David
David W. Smith
Synopsys Scientist
Synopsys, Inc.
Synopsys Technology Park
2025 NW Cornelius Pass Road
Hillsboro, OR 97124
Voice: 503.547.6467
Main: 503.547.6000
FAX: 503.547.6906
Email: david.smith@synopsys.com
http://www.synopsys.com
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of
Christian Burisch
Sent: Thursday, August 22, 2002 9:17 AM
To: sv-ec@eda.org
Subject: Forward typedefs and file order dependancies
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.
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.
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.
Con: Not much.
Cheerio,
Christian
This archive was generated by hypermail 2b28 : Thu Aug 22 2002 - 10:21:41 PDT