You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
id = ( "_" | letter ) , { "_" | letter | digit_dec } | literal_id ;
Incidentally, this is also the syntax used for the right-hand-side of a defname:
[ "defname" , "=" , id , newline ] ,
However, SystemVerilog lets us define components with names that cannot be represented with this grammar due to its support for escaped identifiers (IEEE 1800-2017 §5.6.1):
Escaped identifiers shall start with the backslash character (\) and end with white space (space, tab,
newline). They provide a means of including any of the printable ASCII characters in an identifier (the
decimal values 33 through 126, or 21 through 7E in hexadecimal).
Neither the leading backslash character nor the terminating white space is considered to be part of the
identifier. Therefore, an escaped identifier \cpu3 is treated the same as a nonescaped identifier cpu3.
I was wondering if FIRRTL could adopt a similar notion of escaped identifiers, but the fact that MLIR itself doesn't seem to support escaped identifiers might make this a no-go. An alternative would be to allow defname to take a string rhs (it looks like strings can be escaped although this isn't specified). This still wouldn't allow defining a native FIRRTL module with an escaped name, but perhaps defname could be allowed on regular modules too?
The text was updated successfully, but these errors were encountered:
Making the defname take a string makes sense to me. The current identifier approach is fine for referencing the results of other FIRRTL compilations, but, as you mention, doesn't work for arbitrary Verilog module names.
The current syntax for identifiers is:
Incidentally, this is also the syntax used for the right-hand-side of a
defname
:However, SystemVerilog lets us define components with names that cannot be represented with this grammar due to its support for escaped identifiers (IEEE 1800-2017 §5.6.1):
I was wondering if FIRRTL could adopt a similar notion of escaped identifiers, but the fact that MLIR itself doesn't seem to support escaped identifiers might make this a no-go. An alternative would be to allow
defname
to take a string rhs (it looks like strings can be escaped although this isn't specified). This still wouldn't allow defining a native FIRRTL module with an escaped name, but perhapsdefname
could be allowed on regularmodule
s too?The text was updated successfully, but these errors were encountered: