[Moore] Support the display system task.

[hailongSun2000]

Add moore.display and moore.write to represent all $display and $write series ops. Such as $display(boh) and $write(boh). b is binary; o is octal; h is hexadecimal. However, I noticed that slang didn't distinguish them. So I didn't distinguish them too.

I only implemented the $diplay system task for the time being. Others will be introduced later.

[fabianschuiki]

Really cool! The SV standard makes it sound like $write and $display are equivalent except for display adding a newline automatically. Maybe these could be just one op, something like moore.builtin.display, with a boolean argument to indicate the newline, and maybe another enum argument to encode the binary b, octal o, hex h, or decimal flavor of the task.

Another thing we need to think about is how we deal with formatting specifiers in the string, stuff like %s and the like. In the sim/verif dialect we've started to destructure such formatting strings into separate ops, to make things easier to compose. Should we do this here as well? Because at some point in the pipeline we'll have to parse the format string and figure out how the arguments have to be converted to a string for printing. That would require quite a few additional ops to represent the different formatting specifiers. Alternatively, we could also do the format string parsing in the MooreToCore conversion, but the problem there is that we wouldn't be able to produce any error messages if the user typed some invalid formatting string.

[hailongSun2000]

I have learned the sim dialect recently. However, due to slang thinking $displayo("The value of a is: %b", a(int)) is right. So I haven't distinguished boh. For this example, we need to transfer a(int) onto the binary(%b), and then print it in octal, right 🤔 ?
I'll merge moore.write and moore.display.

[fabianschuiki]

My suspicion is that the [boh] suffix affects how integer arguments are handled if they are not part of the formatting string. I'd expect something like the following:

$display(x);  // print x as decimal
$displayb(x);  // print x as binary
$displayo(x);  // print x as octal
$displayh(x);  // print x as hex

$display("foo %x", x, y);  // print x as hex, y as decimal
$displayb("foo %x", x, y);  // print x as hex, y as binary
$displayo("foo %x", x, y);  // print x as hex, y as octal
$displayh("foo %x", x, y);  // print x as hex, y as hex

The spec also makes it sound like there can be multiple formatting strings passed to display, like the following:

$display("foo %d", x, "bar %d", y); // print "foo <x>" followed by "bar <y>"

Maybe it would be worthwhile to have a moore.builtin.display op and then have a lowering somewhere that parses all the format strings and converts the single display op into multiple formatting and concatenation ops, like what the Sim dialect does?

[fabianschuiki]

I just took a look through the circt-verilog failures in sv-tests, and a large chunk of them fail because we do not yet support $display. This PR will make sv-tests very happy 😺 🥳

[hailongSun2000]

I just took a look through the circt-verilog failures in sv-tests, and a large chunk of them fail because we do not yet support $display. This PR will make sv-tests very happy 😺 🥳

Yeah, ur right! I also noticed that. I'm tweaking the HierarchicalName, and then I'll implement this PR.