Subject: FW: Forward typedefs and file order dependancies
From: David W. Smith (david.smith@synopsys.com)
Date: Thu Aug 22 2002 - 10:09:44 PDT
-----Original Message-----
From: owner-sv-ec@eda.org [mailto:owner-sv-ec@eda.org] On Behalf Of Paul
Graham
Sent: Thursday, August 22, 2002 8:30 AM
To: burisch@co-design.com
Cc: sv-ec@eda.org
Subject: Re: Forward typedefs and file order dependancies
> 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.
>
> 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.
Hi, Christian. This is Paul Graham, formerly from Ambit.
If the language is extended to allow pointers, it will only be necessary
to allow an empty typedef to be used in an opaque pointer type
definition, just as in C or Pascal:
typedef data_t;
typedef data_t *ptr_type;
But you want to allow an empty typedef to be used in any circumstance:
typedef data_t;
data_t x;
assign y1 = x[3]; // is x an array?
assign y2 = x[3][4]; // is x a two-dimensional array?
assign z = x.f1; // is x a struct? if so, does it have a
field f1?
This means that very low-level semantic checking, like whether the type
can be used in an array or struct context, must be deferred to
elaboration.
It's true that parameters cause some checks to be deferred to
elaboration time, but these checks mainly have to do with array bounds:
parameter p = 4;
wire [p-1:0] x;
assign y = x[7]; // range check deferred until value of p is
known
It's still clear at parsing time that x is a one-dimensional vector of
bits.
Paul
This archive was generated by hypermail 2b28 : Thu Aug 22 2002 - 10:11:51 PDT