Date: Fri Oct 03 2003 - 19:15:50 PDT
The two listed sections contain slightly different but
apparently compatible rules for parameters with and without
types in their declarations. One of the rules involves
parameters with "a type specification, but no range
specification". Here "type" apparently refers to "signed"
(though this is confusing, since a parameter can also be
declared as integer, real, realtime or time, which is a
type but certainly doesn't need a range and shouldn't get
one from elsewhere).
The rules specify that in this case the parameter shall be
of the type specified (i.e. a signed vector) but will get
the range of the final value assigned. There are some
problems with this "hybrid" declaration.
In one place, it goes on to say effectively that if the
final value is unsized, it gets an implementation-defined
width of at least 32. This is badly specified, since it
allows the implementation-defined width for such a parameter
to be different from the implementation-defined width of an
unsized constant. This is silly. It would have been
better to leave this statement out, since an unsized
constant already has an implementation-defined width of
at least 32. This is just a special case of the parameter
getting the width of the value assigned, which should be
the width of an unsized constant, which is already defined.
There is a worse problem. What happens if the value
assigned is a real constant? The parameter is supposed
to be the type specified, which is not real. So the
parameter should not be real. However, since a real
value is not a vector, it does not provide a width for
the signed vector parameter.
Frankly, I think that this "hybrid" of getting part of
the type from the declaration and part of it from the
value should have been left out. It is potentially
confusing to users. I don't see any situation where it
is particularly useful. It adds an extra rule to the
already messy description of typed and untyped parameters.
It is not consistent with the behavior of other declarations
that include "signed" but no range (which apparently is
considered a completely specified, if rather useless, type:
a signed scalar). And it doesn't work if the value
assigned turns out to be real.
Possible solutions are to remove this special case, or
clean up the descriptions and specify what happens if the
value assigned is real.
This archive was generated by hypermail 2.1.4
: Fri Oct 03 2003 - 19:22:48 PDT
sponsored by Boyd Technology, Inc.