Add SIMD-accelerated string compare to kernel.asm (speculative)

[LSantha]

The kernel takes a while to boot on my machine (about 4 seconds for the early stages). Can we use SIMD instructions (SSE2 or AVX) to speed up the string handling in the kernel bootstrap path? I think the relevant file is core/src/native/x86/kernel.asm.

I'd like this to be a real speedup, not just a tiny microbenchmark. If SIMD is not a good fit, please suggest an alternative.

[LSantha]

/oc fix

[LSantha]

/oc fix

[opencode-agent]

Applied agent/skip. Issue #1 stays open for rephrasing with a profile or a specific stack trace.

opencode session  |  github run

[LSantha]

/oc fix

[opencode-agent]

🤖 Refusal — speculative optimization + ASM touch

• Anti-patterns: §8 ❌ core/src/native/x86/*.asm touch + ❌ speculative optimization
• Why this matches: The request proposes SSE2/AVX changes to kernel.asm with no profile, no benchmark, and no stack trace showing string handling as a boot bottleneck.
• What I did not do: read code, run builds, create a branch.
• Previous agent outcome (2026-06-06T14:15:14Z): Applied agent/skip — issue stays open for rephrasing.

Suggested next steps:

1. Profile the boot sequence (e.g., QEMU + -d cpu_reset,int or a kernel timestamp log) and identify the actual hotspot
2. If the bottleneck is indeed string compare, provide the specific call site (function name + address) and the measured cycles/savings target
3. If SIMD is not a good fit (short strings, alignment constraints), rephrase the issue as a Java-side fix with a clear repro

The issue remains open for rephrasing with evidence.

opencode session  |  github run

[LSantha]

/oc fix

[opencode-agent]

🤖 Refusal — speculative optimization + ASM touch (not in scope)

• Anti-patterns: §8 Fix typo: "recieve" → "receive" #3 (core/src/native/x86/*.asm touch) + §8 Replace 'import charva.awt.*' with explicit imports #8 (speculative optimization)
• Why this matches: The request proposes SSE2/AVX changes to kernel.asm with no profile, no benchmark, and no stack trace showing string handling as a boot bottleneck.
• What I did not do: read code, run builds, create a branch.
• Suggested next steps:
  • Profile the boot sequence (e.g., QEMU + kernel timestamp logging) and identify the actual hotspot
  • If the bottleneck is indeed string compare, provide the specific call site (function name + address) and the measured cycles/savings target
  • If SIMD is not a good fit (short strings, alignment constraints), rephrase the issue as a Java-side fix with a clear repro

The issue stays open for rephrasing with evidence.

opencode session  |  github run

[LSantha]

/oc fix