essential-contributions / essential-base

Core items shared by both the intent language and protocol.
https://essential.builders
Apache License 2.0
4 stars 2 forks source link

Introduce an ASM shorthand? #139

Open mitchmindtree opened 5 months ago

mitchmindtree commented 5 months ago

Currently we don't really have a way of handwriting ASM besides writing bytes or specifying the whole enum variant for each op in Rust code, but this is very Rust-specfic and doesn't feel very "universal".

It'd be nice to have some universal terse shorthand for each op that could be used to show operations in debugging tools, used to handwrite ASM (e.g. in hypothetical ASM blocks, as consts in Rust or potentially even in raw ASM files).

Declaration in asm.yml

We could have an optional shorthand field in the asm.yml that specifies this shorthand, defaulting to the uppercase of the op name in the case that one is not specified, e.g.

Ops where the behaviour would be otherwise ambiguous using this default name could specify their shorthand in the asm.yml, e.g. StateSlots(LoadWord) could be something like:

        LoadWord:
          opcode: 0x93
          shorthand: SSLOADWORD
          # ...

Convention?

As a convention, I'd propose we ensure all shorthands are fully uppercase with no underscores. The benefit of requiring no underscores is that ops can also be written sequentially purely separated by whitespace and still be readable (to the extent asm is readable), e.g.

PUSH 1 PUSH 2 PUSH 1 REPEAT REPEATCOUNTER PUSH 1 ADD DUP DECISIONVAR PUSH 2 MUL SWAP PUSH 0 DECISIONVAR ADD DECISIONVAR EQ AND REPEATEND

the ops are above are a little easier to distinguish than below, where its easy to confuse a space and an underscore:

PUSH 1 PUSH 2 PUSH 1 REPEAT REPEAT_COUNTER PUSH 1 ADD DUP DECISION_VAR PUSH 2 MUL SWAP PUSH 0 DECISION_VAR ADD DECISION_VAR EQ AND REPEAT_END

Of course, this is arguably not that important though as most asm tends to be written line-by-line:

PUSH 0x0F0F0F0F0F0F0F0F
PUSH 0xF0F0F0F0F0F0F0F0
ADD
PUSH 0xFFFFFFFFFFFFFFFF
EQ

but I think the flexibility could be nice for UIs where there might be more horizontal space than vertical.

Fwiw, this shorthand would follow the EVM convention too.