|
|
|---|
|
|
|
|---|
Handling of identifiers.
The grammars of Verilog-2005 and SystemVerilog-2012 agree on:
identifier ::= simple_identifier
| escaped_identifier
simple_identifier ::= [ a-zA-Z_ ] { [a-zA-Z0-9_$ ] }
(no embedded spaces)
The Verilog-2005 grammar presents the rule for escaped identifiers as:
escaped_identifier ::= \ { any non-whitespace character } white_space
However, Section 3.7.1 of the Verilog-2005 standard appears to contradict the above definition. It says that escaped identifiers "provide a means of including any of the printable ASCII characters in an identifier (the decimal values 33 through 126...). Section 5.6.1 of the SystemVerilog-2012 standard says the same thing, and its grammar has been updated with this clarification:
escaped_identifier ::= \ { any printable non-whitespace character } white_space
We therefore restrict the name characters in escaped identifiers to the printable ASCII characters, i.e., characters whose codes are 33-126.
Both Verilog-2005 and SystemVerilog agree on the syntax for system identifiers:
system_tf_identifier ::= $[ a-zA-Z0-9_$ ] { [ a-zA-Z0-9_$ ] }
Well, that's arguably true. SystemVerilog adds certain pieces of syntax
such as
Per Section 3.7.1 of Verilog-2005, the leading backslash character and the
terminating whitespace character are not "considered to be part of the
identifier", i.e.,
Perhaps a reason for including this whitespace is found on page 351 of the
Verilog-2005 standard. A macro with arguments is introduced like
I have not found anything in the spec which explicitly prohibits the empty
escaped identifier, i.e.,
We are always careful to hons the names of the identifier tokens we create. One reason it's a good idea is that identifiers are often repeated many times, so making the actual string part a hons lets us use only one copy of the string. The other big reason is that identifier names are often used in fast-alist lookups, and if the string isn't a hons, then hons-get will have to hons it first anyway. So, by honsing as we create the identifier token, we potentially avoid a lot of repeated, redundant honsing later on.