Discussion: Let's minimize our instruction set

[jonasstrehle]

Soo, just stumbled across the question if we really want to introduce instruction codes per operator and keyword etc.
Like there is the advantage that the decompilation would look great if we get a 1 to 1 mapping of the initial script, but also here we're going to run into issues once we implement branching or other more complex stuff such as loops, where without specific markers the decompiler can not tell what the initial script did exactly look like. Yeah, this is fancy and nice to have but shouldn't be our key focus here.

We should try to keep the whole instruction set as minimum as possible, not just because we are already on like 190 instructions by now (not all of them are implemented but you get the point).

Let's consider the operators for equality, do we have a point to declare operands such as

• EQUAL_VALUE
• EQUAL_STRICT
• NOT_EQUAL_VALUE
• NOT_EQUAL_STRICT
• EQUAL_OR_GREATER
• EQUAL_OR_SMALLER
• ...

or does it make sense to implement some negation (what we need in any case for boolean toggles !) to at least break it down to half of the instructions so the chain looks more like neg(strict_equal(a, b)) instead of neg_strict_equal(a, b)? The issue is that we don't know if the operator used a negation or the negative variant of the operator then for decompilation, but I suppose this is a good tradeoff.

Furthermore we could also get rid of such things as EQUAL_OR_SMALLER and just switch both of the operands for the compilation for the reverse case and use EQUAL_OR_GREATER then (or even (a EQUALS b || a GREATER b). All of this shortcuts will nevertheless mean, that it is necessary that the order of operations doesn't consider the allowed order of operands if we would allow weird arbitrary type comparison such that 1 == "1" is okay but "1" == 1 is nok (or some better example I did not come up with yet). Also for strict vs loose equality we could store it as a flag inside the same instruction code do don't explode the opcode table as such:

InstructionEquality(
    type = GEQ,
    lhs = ...
    rhs = ...
)

Some unverified information by gpt in the following

Language/VM	How comparisons are handled
.NET IL	Few opcodes (ceq, clt, cgt), use neg or operand swap for others
LLVM IR	Single icmp with a predicate (eq, ne, lt, etc.) as parameter
Python	One opcode COMPARE_OP, uses an immediate enum for operator type
Lua	3 opcodes (EQ, LT, LE) with a not flag + operand swapping
WebAssembly	Separate opcode per comparison (i32.eq, i32.ne, etc.)

Common strategies:

• Use a single opcode with flags or enums.
• Implement negation (!) as a separate opcode.
• Swap operands to reduce instruction count (e.g., a >= b → b <= a).
• Store original source operator in debug metadata if needed for decompilation.
• Most languages avoid duplicating opcodes and prioritize a minimal, orthogonal instruction set.

[jonasstrehle]

@benStre @janiejestemja @TeeB3utel @HuskyRight