LFX Workspace: Support for the Wide Arithmetic Proposal (2026 Term 3)

Project Title

Support for the Wide Arithmetic Proposal — #5153

Motivation

Wide arithmetic is useful for big-integer libraries and cryptographic code. The proposal gives runtimes operations that can be lowered efficiently to native instructions. I want to add this support to WasmEdge and make sure it behaves consistently in the interpreter, JIT, and AOT compiler.

Expected Outcome

• Implement i64.add128, i64.sub128, i64.mul_wide_s, and i64.mul_wide_u, including proposal configuration, binary decoding, validation, and execution.
• Support all four instructions in the interpreter, JIT, and AOT compiler, with the implementation and tests pinned to the same proposal revision.
• Pass the corresponding proposal specification tests and add regression tests for feature gating, invalid inputs, arithmetic boundaries, and result ordering.
• Document how to enable and use the feature in WasmEdge/docs.

Details

Hi @hydai and @q82419, I'm YE-YU LIN (@Lewis-panda), the accepted mentee for this project. I've outlined my plan below and will start with the Week 1 work. Please let me know if you'd like any changes to the scope, milestones, or PR sequence.

Starting point

My August 17 pre-test report records an Ubuntu 24.04 x86-64 build using GCC 13 and LLVM 18 at WasmEdge commit ba7328af264276bac3398154bf4ac87b416084cf. The locally instrumented pre-test build passed 33/33 CTest targets. That work used a Codex-assisted workflow, as disclosed in the report.

For the project, I will establish a fresh build and test baseline on current master, keeping the pre-test patch separate. I'll record the source revision, toolchain, commands, and results here.

Implementation and testing

I will first trace the opcode, configuration, loader, serializer, validator, interpreter, and LLVM paths, then post a short design note. The initial PR sequence I have in mind is:

1. Proposal/opcode configuration, loader and serializer support, and validation, with focused tests.
2. Interpreter addition/subtraction, followed by signed and unsigned widening multiplication, with arithmetic tests alongside each change.
3. LLVM lowering for JIT/AOT and tests comparing the execution modes.
4. Remaining spec-test integration and user documentation.

I'll split these into reviewable PRs and adjust the grouping based on your feedback. Tests and review fixes will be part of the work throughout the term.

I'll use the proposal spec tests as the semantic reference and run the same test vectors across the interpreter, JIT, and AOT. Focused cases will cover carry/borrow, 128-bit add/sub wraparound, signed versus unsigned multiplication, low/high 64-bit ordering, invalid stack types, and rejection when the feature is disabled. Randomized cases will use a fixed seed and an independent arbitrary-precision oracle, comparing the result bit patterns.

Milestones

These are proposed working dates for September 7–November 27, based on my application plan. I will update this issue as the work and reviews progress, and record any changes to the plan here.

Week / dates (2026)	Planned work and output
1 · Sep 7–11	Record the proposal revision used as the starting point, establish a clean current-master build/test baseline, and post a code-path map and short design note for review.
2 · Sep 14–18	Prepare proposal/opcode configuration and loader/serializer changes for review. Add encoding/decoding and disabled-feature tests.
3 · Sep 21–25	Add validator support for all four instructions, with valid/invalid stack-type and multi-value ordering tests. Address feedback on the initial changes.
4 · Sep 28–Oct 2	Implement interpreter addition and subtraction. Submit carry, borrow, wraparound, and asymmetric low/high operand tests with the changes.
5 · Oct 5–9	Implement both interpreter widening-multiply instructions. Add boundary cases and fixed-seed comparisons with an independent oracle.
6 · Oct 12–16	Prepare LLVM lowering for all four instructions for review, with initial JIT/AOT execution tests. Check extension and low/high result ordering.
7 · Oct 19–23	Post the midterm progress summary and PR/test links on Oct 19, ahead of the evaluation deadline. Continue proposal spec tests and cross-mode comparisons, documenting and fixing any gaps.
8 · Oct 26–30	Lower-capacity exam week: respond to reviews, triage test results, and update documentation and the progress log.
9 · Nov 2–6	Finish outstanding cross-mode/spec-test integration and resolve semantic or feature-configuration differences. Publish an updated test matrix.
10 · Nov 9–13	Run the full relevant suite and sanitizer checks. Resolve portability or CI issues on the agreed targets, with small reproductions for failures.
11 · Nov 16–20	Finish user documentation and review fixes. Prepare the final report with PR links, test results, and any remaining limitations by Nov 20.
12 · Nov 23–27	Complete the required final-evaluation materials before the Nov 24 UTC deadline. Use the remaining term for follow-up review fixes and handoff notes.

The published CNCF schedule sets the evaluation deadlines as:

• Midterm: October 20, 18:00 UTC / October 21, 02:00 Asia/Taipei.
• Final: November 24, 18:00 UTC / November 25, 02:00 Asia/Taipei.

By midterm, I aim to have interpreter support for all four instructions, plus LLVM lowering and initial cross-mode tests available for review.

Appendix

Availability and progress updates

I can commit around 30–40 hours per week, based in Asia/Taipei (UTC+08:00). My midterm exams are October 26–30, when I will have less time available. I've kept that week focused on review and smaller follow-up work.

I will post an update here each week with completed work and PR/test links, current work, questions or blockers, and the next week's plan. I'll raise blockers as they come up and flag schedule changes in advance.

References

• Project issue #5153
• Wide Arithmetic proposal
• WasmEdge mentorship policy