wasm dialect

[oovm]

I want to learn pliron by writing a wasm translator.

• https://github.com/nyar-vm/pliron-wasm/blob/dev/projects/pliron-wasm/src/attrs/defs.rs
• https://github.com/nyar-vm/pliron-wasm/blob/dev/projects/pliron-wasm/src/ops/defs.rs

I have some questions about understanding.

1. Is there any problem with Attr, Op being defined like this?

2. Should Printable be implemented as the idiomatic form in this ir? (i.e. wat)

Or should it be implemented as the idiomatic form in pliron?

[vaivaswatha]

1. Is there any problem with Attr, Op being defined like this?

Your definitions look fine to me. The only issue I see is that you use names like table.grow, that has a . in it. The parser doesn't allow . in an identifier (at least not today. Maybe someday in the future, I don't know). So maybe replace that with an _ ?

2. Should Printable be implemented as the idiomatic form in this ir? (i.e. wat)

I'm not sure what you mean. Right now I see a printable.rs file that has the implementations (mostly todos). They look fine to me.

Overall, what you have seems fine to me. But I must warn you, pliron is still not ready for production use. There's a lot of work to be done (which I'm slowly working on, whenever I get time). But seeing people (like you) interested in it motivates me to give it more time :-)

[oovm]

I haven't implemented Printable yet, I mean it should be implemented as

   (func $add (param $a i32) (param $b i32) (result i32)
     (i32.add (get_local $a) (get_local $b))
   )

or things like

    builtin.func @add: wasm.function <(wasm.i32) -> (wasm.i32)> {
      entry():
        l1 = local_get_i32 %1
        l2 = local_get_i32 %2
        result = i32_add %1 %2
        wasm.return result 
    }

[vaivaswatha]

The latter one seems right to me. Although I'm writing the parsing infrastructure such that each operation (or type or attribute) can have its own parser, to be able to call that custom parser, we'll need the op_id (builtin.func in your example, for example) to be at the start (or at least in the form res1, res1, ... = op_id ...). After that, you can have your own syntax for which you'll write a parser.

[oovm]

Your definitions look fine to me. The only issue I see is that you use names like table.grow, that has a . in it. The parser doesn't allow . in an identifier (at least not today. Maybe someday in the future, I don't know). So maybe replace that with an _ ?

Probably should use ::, since this is similar to operation variants, just like enums and variants in rust.

[vaivaswatha]

Your definitions look fine to me. The only issue I see is that you use names like table.grow, that has a . in it. The parser doesn't allow . in an identifier (at least not today. Maybe someday in the future, I don't know). So maybe replace that with an _ ?

Probably should use ::, since this is similar to operation variants, just like enums and variants in rust.

At a source level it may be anything. But as an IR, I don't see why names should allow ::. It's an operation identifier (i.e., a name for an operation). The operation itself can represent anything you want at the source level though (including ::).