L1A/L1B: FAIL (phys stack bug); L2: PARTIAL (unsupported)

[opencode-agent]

Spec compliance report

Compiler	Status	Issues
l1a	❌ FAIL	Physical stack manipulation assumes 4 operand values (Form 1 only), corrupts stack for Forms 2, 3, 4. Virtual stack logic is correct.
l1b	❌ FAIL	Same physical stack bug as l1a. NEW virtual stack logic is correct and improved over l1a.
l2	⚠️ PARTIAL	Explicitly unsupported - falls back to L1. Not a bug per se, but incomplete support.

---

Details

JVM Spec Reference

• Instruction: dup2_x2 (opcode 0x5e = 94)
• Spec Page: https://docs.oracle.com/javase/specs/jvms/se6/html/Instructions2.doc3.html
• Operand Stack Effect (four forms based on computational type categories):

Form	Stack Before (top at right)	Stack After (top at right)	Conditions
1	..., value4(c1), value3(c1), value2(c1), value1(c1)	..., value2, value1, value4, value3, value2, value1	All category 1
2	..., value3(c1), value2(c1), value1(c2)	..., value1, value3, value2, value1	v1=cat2, v2,v3=cat1
3	..., value3(c2), value2(c1), value1(c1)	..., value2, value1, value3, value2, value1	v1,v2=cat1, v3=cat2
4	..., value2(c2), value1(c2)	..., value1, value2, value1	v1,v2=cat2

Category 1: int, float, reference (single slot). Category 2: long, double (double slot).

---

l1a Implementation

• Status: ❌ FAIL
• Files: core/src/core/org/jnode/vm/x86/compiler/l1a/X86BytecodeVisitor.java:1670, core/src/core/org/jnode/vm/x86/compiler/l1a/VirtualStack.java, core/src/core/org/jnode/vm/x86/compiler/l1a/ItemStack.java
• Issues:

1. Physical stack manipulation bug (lines 1681-1691): The code always executes a fixed register-based POP/PUSH sequence assuming exactly 4 values on the physical stack. This is only correct for Form 1 (4 category-1 values). For Form 2 (3 values), Form 3 (3 values), and Form 4 (2 values), this incorrectly pops/pushes values below the relevant operands, corrupting the physical stack.

2. Virtual stack logic (lines 1693-1729): Correctly handles all 4 forms with proper category checks. The virtual stack updates match the spec for all forms.

3. Forced stack flush: vstack.push(eContext) at line 1674 flushes all virtual items to physical stack before manipulation, but the subsequent register manipulation doesn't account for variable operand counts per form.

---

l1b Implementation

• Status: ❌ FAIL
• Files: core/src/core/org/jnode/vm/x86/compiler/l1b/X86BytecodeVisitor.java:2002 (NEW), :1933 (OLD, commented), core/src/core/org/jnode/vm/x86/compiler/l1b/VirtualStack.java, core/src/core/org/jnode/vm/x86/compiler/l1b/ItemStack.java
• Issues:

1. Physical stack manipulation bug (lines 2014-2024): Identical bug to l1a - same fixed 4-pop/6-push register sequence that only works for Form 1.

2. NEW virtual stack logic (lines 2026-2066): Improved over l1a. Checks c1 (top value) first, correctly handles all 4 forms with more readable logic.

3. OLD virtual stack logic (lines 1933-1995, commented): Same as l1a.

4. Debug output: Line 2007 prints "NEW dup2_x2" to stdout - should be removed in production.

---

l2 Implementation

• Status: ⚠️ PARTIAL
• Files: core/src/core/org/jnode/vm/x86/compiler/l2/L2ByteCodeSupportChecker.java:131, core/src/core/org/jnode/vm/compiler/ir/IRGenerator.java:574
• Issues:

1. Explicitly unsupported in L2ByteCodeSupportChecker (line 131-133): notSupported() call rejects methods with dup2_x2 from L2 compilation.

2. IRGenerator throws exception (line 574-576): IllegalArgumentException("byte code not yet supported") - even if support checker were modified, IR generation would fail.

3. Impact: Methods with dup2_x2 fall back to L1 compilation only. Known limitation, not a correctness bug, but incomplete L2 coverage.

---

Root Cause Analysis

The fundamental issue in L1A/L1B is the "push all on stack" fallback strategy (comment: "since this opcode is just too complicated"). The compilers flush the virtual stack to the physical stack, then attempt a register-based shuffle assuming the maximum operand count (Form 1: 4 values) rather than adapting to the actual form.

The virtual stack tracking in both L1A and L1B is spec-compliant; only the physical code emission is broken.

---

Recommendation

1. Fix L1A/L1B physical emission: Replace fixed POP/PUSH sequence with form-specific logic matching the virtual stack updates.
2. Implement L2 support: Add dup2_x2 handling to L2ByteCodeSupportChecker and IRGenerator, then implement in GenericX86CodeGenerator/X86CodeGenerator.
3. Add test coverage: Create bytecode test cases exercising all 4 forms of dup2_x2.

Closes #257

opencode session  |  github run