Subject: Re: Forward typedefs and file order dependancies
From: Paul Graham (pgraham@cadence.com)
Date: Thu Aug 22 2002 - 08:29:50 PDT
> 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 - 08:31:44 PDT