RE: [sv-bc] 4.10.4 "Enumerated types in numerical expressions" - unclearness

>From: "Bresticker, Shalom" <shalom.bresticker@intel.com>

>So what you and Dave seem to be saying is that the next() method
>increments the enum value by 1 and then casts it back to the enum type.

No, that would be too efficient.  I'm not sure how we implied that.


>I had interpreted the text to mean that next() goes to the next member
>in the list of members. Otherwise, why not simply say that it increments
>the value, as I wrote above? Especially as the description of next()
>immediately follows the descriptions of first() and last(), which
>likewise refer to order in the list, as opposed to maximum and minimum
>values.

This interpretation is correct.  You have to take the enum value, find
it in the list, and then return the next value in the list.  If you let
the compiler define the values, then this is equivalent to computing
(value+1)%number_of_values.  But if you explicitly define non-incrementing
values, then it is something much less efficient.


>Assuming that I interpret you correctly, that still leaves some open
>questions.

Since the assumption doesn't hold, that changes most of the open questions.


>It means for example, that the example in 4.10.4.7, of how to display
>the name and values of all the members of an enumeration, is not
>general, as is implied. It would only work if indeed each member has a
>value incremented by 1 from the member preceding it in the list.

It is general, given the actual meaning of next().


>Also, you wrote,
>" And if you haven't
>>explicitly
>>defined an enum member with an all-X value (which you generally
>>won't),
>>subsequent next() calls will continue to produce X"
>
>It would seem to me that this will occur even if you have defined an
>enum member with an X value. Incrementing X by 1 will still give you X.
>So if you start from X, next() will leave you stuck there. And if you
>start from a non-X value, next() will never bring you to the X value.

But with the actual definition of next(), if you defined an enum constant
with an X value, then calling next() on that value would return the next
constant in the list, which will not be the X value.

And if you start with a non-X value that is not one of the legal enum
constant values, next() will give you an X value.  So if you are using
an 4-state enum in a state machine, and using next() to go to the next
state in sequence in some cases, and the state somehow gets into an
invalid state, then next() will take you to an X state.  And if you have
left X as an invalid state, then subsequent next() calls will keep you
in the X state.

>By the way, I can declare a net as an enum, can't I? In that case, its
>default initial value would be Z, not X, right?

You can if it is a 4-state enum.  And if you don't drive the net, then
it will come out Z.  But the "default initial value" for the enum type is
still X.  The "default initial value" of the enum type is a property of
the type, and is defined in a table in the LRM.  The next() method will
return the same result for a given input value of a given enum type,
regardless of where the value came from.

The term "default initial value" is somewhat misleading, since an
undriven net will come out Z regardless of the "default initial value."
It is less verbose than saying "the same value that would be used as the
default initial value if you declare a variable of this type" or "the
value defined for this type in Table XX, which is used for default initial
values of variables as well as out-of-range indexing and other things."

Note that you can also declare a net of integer type, and the default
initial value for an integer is X, but an undriven net of integer type
will have a value of Z.


>Another question is about what is written is that "A wrap to the start
>of the enumeration occurs when the end of the enumeration is reached."
>So what happens if the last member in the enumeration list is not the
>maximum value in the list?
>Similarly, prev() mentions "when the start of the enumeration is
>reached".

Again, since next() is defined in terms of the enumeration list, not
adding 1, it doesn't matter whether the last member is the maximum
value.  If you apply next() to a value that is the last value in the
enumeration list, you get the first value in the list.


>But does this mean it is allowed to assign the same value twice
>explicitly? If so, what would name() give me in this case?

The intent is that it should be illegal to have the same numeric value
twice in the enumeration.  But instead of saying that, the LRM describes
different rules for when the value is set explicitly, and implicitly by
incrementing.  These rules may or may not be sufficient to make the
intended restriction.  They certainly aren't clear.

Since not only name(), but next() and prev(), are defined in terms of
finding the value in the list, the definitions only work if the values
are unique.

Steven Sharp
sharp@cadence.com