Advocating for Static ABI Layouts in Component Model to Support Constrained IoT Devices

[snowyu]

Hi WAMR team,

I am currently discussing a critical issue with the WebAssembly Component Model working group regarding the future of the Canonical ABI and WIT. I believe this conversation is vital for the IoT and embedded Wasm ecosystem that WAMR serves.

The Problem:
The current direction of the Component Model (Preview 3 + Lazy Lowering) is moving toward a "Dynamic Runtime Protocol" instead of a "Static Binary Interface (ABI)". To share high-level types (like strings or arrays) between languages, the current proposal requires guest modules to implement complex "core function imports" to negotiate memory locations at runtime.

My Concern for WAMR/IoT:
For MCU-level devices with very limited memory (KB, not GB), this dynamic negotiation adds:

1. Unnecessary Code Size: Forcing lightweight languages (like AssemblyScript or Zig) to include complex state machines for lowering logic.
2. Runtime Overhead: Multiple function calls and dynamic "handshaking" just to pass an immutable string or array.
3. Complexity: It treats a local function call like a remote RPC, which is overkill for native, in-process interop.

My Proposal:
I am advocating for the inclusion of "Static Declarative Layouts" in the specification—allowing WIT to optionally define fixed, predictable memory structures (e.g., [u32 len][content]). This would allow true zero-copy or minimal-copy library sharing without the heavy dynamic logic.

How you can help:
I’ve opened an issue on the Component Model repo and would value the input of the WAMR team. Your experience with real-world hardware constraints is the "reality check" the spec group needs.

Issue Link: WebAssembly/component-model#581

I'd love to hear your thoughts on whether the current "Lazy Lowering" path is sufficient for your use cases, or if a "Static Profile" is necessary for the embedded world.

Best regards,

[lum1n0us]

I'm not sure I fully understand the concepts of Dynamic Runtime Protocol, Static Binary Interface, and Static Declarative Layouts, but the downsides you listed about the Component model, such as unnecessary code size, runtime overhead, and complexity, are familiar to the WAMR community.

These problems are indeed real and have been challenged since day one. I'm sure you already know that there are at least two root causes: 1) Components cannot access each other across sandboxes, and 2) Different languages use different memory layouts for the same type, making it unpredictable how another component model will represent specific types.

In certain guest language constraints or usage scenarios, solutions superior to the current proposal certainly exist.

WAMR has been continuously seeking suitable implementation forms and solutions for a component model in the embedded domain.

[snowyu]

Thank you for pinpointing those two "root causes." While I agree they are the primary drivers of the current design, I believe the current Component Model (CM) proposal misinterprets how to solve them for the embedded domain.

I would like to propose a different perspective that addresses these points while considering Wasm's role as a "Firmware Logic Layer" (similar to MicroPython) rather than just a "Cloud Plugin":

1. On Sandboxing vs. Predictable Contracts:
   Standardizing a static layout (e.g., a fixed [u32 len][content] structure) does not require breaking the sandbox. It simply provides a predictable binary contract. Even if the host must copy data from a guest, a static layout allows for a direct, optimized memcpy. The current dynamic protocol forces a "negotiation" via multiple function calls just to locate data. In a real-time firmware context—such as reading a sensor 1000 times a second—this dynamic overhead is a fatal flaw that static layouts easily resolve.
2. On Language Layout Differences vs. Boundary Standards:
   The goal of a Static ABI isn't to force a language to change its internal memory model, but to define a Universal Boundary Format. While Rust and AssemblyScript have different internal representations, both can easily "pack" data into a simple, standard static format. Forcing a lightweight language like AssemblyScript to implement a complex dynamic state machine for "Lazy Lowering" is far more burdensome than simply adhering to a fixed, pre-agreed memory structure.
3. The Misalignment of Use Cases:
   The current CM design assumes a "Cloud/Microservice" model where host and guest are strangers. But in IoT, Wasm is often used as Firmware Logic where the developer controls both sides. In this "firmware-style" usage:
   • Security is a baseline handled by the Wasm memory boundary, not a complex protocol.
   • Latency and Binary Footprint are the top priorities.
   • A heavy, dynamic negotiation layer just to pass an array makes Wasm unviable for the very MCU-level devices WAMR aims to support.