RE: [sv-bc] 10.8 Named blocks and statement labels - question

>It seems that the clear answer is that there is no basis for making
>multiple labels for a single statement illegal.  It was just done that
>way.

I can think of one minor issue with multiple alternate names for a
single block.  It would not be clear which alternative name should
be used by things like the %m format and VCD dumps, which could result
in different behavior in different implementations.  This could be
resolved by specifying that one of the names has priority for such
things.


>There you leave us, assuming we would recognize some inherent problem
>with the above.

At best, it is evidence that someone believed that a label on a block
would be treated as the block name, rather than creating a new named
block around the statement.  The examples are similar evidence.  But
it doesn't mean that is what the standard actually specifies.  There
is a clear and unambiguous specification (hidden in 17.2) that it
creates a new named block around the statement.

If it is desired that a label on a block become the block name, then
this needs to be changed.


>It would seem least surprizing that the variable be known as A.B.foo in
>this case, and that the source text "label : statement;" consistantly
>mean that we treat the the text as if it was:
>"begin : label statement; end"  without regard for what statement
>consists of.
>
>If statement is "begin :B integer a; a = b + c; d = a; end" then and
>label is "A", we process this as if we had read: "begin : A begin :B
>integer a; a = b + c; d = a; end end"
>which is well defined, well behaved verilog.
>
>Bottom line: We should have good reasons for introducing special cases
>to a language.  Orthaganality is a virtue.

Agreed.  However, I don't really see much use for statement labels
anyway.  On a block that declares variables, a block name could be used
instead, for the same amount of typing.  On statements other than blocks,
they are only useful for disables.  Disables are rarely used and should
be discouraged, especially now that return/break/continue and disable
fork are available for the most common and safe uses.  They are even
less likely to be needed on a single statement, as opposed to a sequence
of statements.  In the tiny number of remaining situations, putting in
a named block isn't much of a hardship.  Adding statement labels never
made much sense to me.

The one thing that they might be slightly useful for does require this
special non-orthogonal case.  In an enhanced for-loop that declares its
loop variables as part of the loop syntax, there is no way to give the
implicit scope a name.  If you accept the rule about using a label on
a block as the block name, and apply it to the implicit block created
by the enhanced for-loop, then it provides a way to give the block a
name.

Steven Sharp
sharp@cadence.com