BNZ/BZ semantics after comparisons: alternative pseudo-opcodes?

[hernandp]

One thing that may confuse new TEAL assembly experimenters (and it catches occasionally on my head) is that if you do a "is equal" comparison, == will be 1 if true, so you must test with bnz opcode. But typically, in CPUs and other architectures you must test for zero (JZ) after a comparison since a CMP op basically is a substraction operation. Historically, and to avoid this kind of confusion, Intel and other manufacturers added the semantically-oriented "JE" (jump-if-equal) opcode (and it's JNE counterpart).
Maybe the TEAL & compiler team can include similar kind of pseudo-opcodes that are finally translated by the compiler to the elementary group of comparison + bnz and bz opcodes?

Thanks.

[jannotti]

Do you want je to mean EXACTLY bnz, and it should/can only be used after ==? That feels very confusing. But I think I'd be interested in some pseudo-ops that combine == and bnz, so you only write je and that becomes both opcodes. (I suspect that's what you want too.)

Another possibility is simply btrue and bfalse as synonyms for bnz and bz, because they read better.

On Mon, Sep 27, 2021 at 3:56 PM Hernán Di Pietro @.***> wrote:

One thing that may confuse new TEAL assembly experimenters (and it catches occasionally on my head) is that if you do a "is equal" comparison, == will be 1 if true, so you must test with bnz opcode. But typically, in CPUs and other architectures you must test for zero (JZ) after a comparison since a CMP op basically is a substraction operation. Historically, and to avoid this kind of confusion, Intel and other manufacturers added the semantically-oriented "JE" (jump-if-equal) opcode (and it's JNE counterpart). Maybe the Algorand guys can include similar kind of pseudo-opcodes that are finally translated by the compiler to the elementary bnz and bz opcodes?

Thanks.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/algorand/go-algorand/issues/2964, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADL7T4XQX2KVEADL3F3BIDUEDD7TANCNFSM5E3KZOYQ .

[hernandp]

Do you want je to mean EXACTLY bnz, and it should/can only be used after ==? That feels very confusing. But I think I'd be interested in some pseudo-ops that combine == and bnz, so you only write je and that becomes both opcodes. (I suspect that's what you want too.) Another possibility is simply btrue and bfalse as synonyms for bnz and bz, because they read better. … On Mon, Sep 27, 2021 at 3:56 PM Hernán Di Pietro @.***> wrote: One thing that may confuse new TEAL assembly experimenters (and it catches occasionally on my head) is that if you do a "is equal" comparison, == will be 1 if true, so you must test with bnz opcode. But typically, in CPUs and other architectures you must test for zero (JZ) after a comparison since a CMP op basically is a substraction operation. Historically, and to avoid this kind of confusion, Intel and other manufacturers added the semantically-oriented "JE" (jump-if-equal) opcode (and it's JNE counterpart). Maybe the Algorand guys can include similar kind of pseudo-opcodes that are finally translated by the compiler to the elementary bnz and bz opcodes? Thanks. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2964>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADL7T4XQX2KVEADL3F3BIDUEDD7TANCNFSM5E3KZOYQ .

Sorry for the confusion, my proposal would be indeed e.g:

beq target (branch if equal)

would be synthesized by the TEAL compiler to:

 ==
 bnz target

Thanks for your reply.

[hernandp]

Addendum: this of course would imply a related set of comparison pseudoopcodes:

beq Branch if equal bneq Branch if not equal bgt Branch if greater than blt Branch if less than bgeq Branch if greater or equal bleq Branch if less or equal.

Names may be more or less different, but you get the idea. This would make the compiler sequence the opcode pair consisting of comparison followed by primitives bz / bnz.

Regards, Hernán

[jannotti]

I think the #define macro PR would essentially give this functionality. What do you think? #4502

#define beq ==; bnz