Hi,

I've just discovered this project and I really like that it can run on MCUs too.

I'm from LVGL and I wonder if you are interested in integrating a UI engine into wasm3.

Every time I trying to use something complex in wasm sources I got "WASM3 error: restricted opcode".

For example std:string in cpp:

#include <string>
extern "C" {
    #define WASM_EXPORT __attribute__((used)) __attribute__((visibility ("default")))
   
    extern void exPrint(const char* str);
    
    WASM_EXPORT
    void printHello() {
        std::string helloString {"Hello From Wasm!"};
        exPrint(helloString.c_str());
    }
}

compiled with emcc src.cpp -o src.wasm -s STANDALONE_WASM -s ERROR_ON_UNDEFINED_SYMBOLS=0 -O0 --no-entry

Or Array<> in typescript:

declare function exSendInt8Array(len : i32) : void;

export function getInt8Array() : void {
  let arr = new Array<i8>(100)
  for (let i:i8 = 0; i < arr.length; i++) {
    arr[i] = i;
  }
  exSendInt8Array(arr.length)
}

compiled with asc src.ts --binaryFile src.wasm --optimize

Is it a problem of compiling WASM? Or I have to attach every single libraries by hand?

I've seen m3_api_lib.c where is m3_LinkLibC function. But do I have to create the similar for all libraries that is used in my WASM sourcec?

Looks like this problem connected whith allocating on a heap commands / instructions, cause I also have the same problem with malloc...

I will be grateful for any help

By simply invoking String.UTF8.encode(someStr) from the sample I'm receiving a panic on my ESP32 developer board. Any suggestions?

Guru Meditation Error: Core  1 panic'ed (IllegalInstruction). Exception was unhandled.
Core 1 register dump:
PC      : 0x746e656d  PS      : 0x00060d30  A0      : 0x800d25a3  A1      : 0x3ffb1bf0  
A2      : 0x3ffb2068  A3      : 0x000000fb  A4      : 0x3f4010dc  A5      : 0x3ffb1c30  
A6      : 0x05010007  A7      : 0x00000000  A8      : 0x800d24c5  A9      : 0x400d1a60  
A10     : 0x3ffb2068  A11     : 0x000000fb  A12     : 0x3f401b74  A13     : 0xffffffff  
A14     : 0x3f401b74  A15     : 0x000000e2  SAR     : 0x00000020  EXCCAUSE: 0x00000000  
EXCVADDR: 0x00000000  LBEG    : 0x4000c2e0  LEND    : 0x4000c2f6  LCOUNT  : 0x00000000  

About two weeks ago, we were able to run several WebAssembly modules on NodeMCU ESP microcontrollers following the esp32-pio and esp8266 platform examples.

In the meanwhile, work on wasm3 has clearly continued - we are particularly happy with the WASI support!

I am, however, now unable to run our WASM modules using the latest code base. For instance, on adapting the esp8266 example as follows:

#include <stdio.h>

#include "Arduino.h"

#define FATAL(msg, ...) { printf("Fatal: " msg "\n", ##__VA_ARGS__); return; }

#include "m3/m3.h" 
#include "m3/m3_env.h"

#include "m3/extra/fib32.wasm.h"

void run_wasm()
{
    M3Result result = c_m3Err_none;

    uint8_t* wasm = (uint8_t*)fib32_wasm;
    size_t fsize = fib32_wasm_len-1;

    IM3Environment env = m3_NewEnvironment ();
    if (!env) FATAL("m3_NewEnvironment failed");

    IM3Runtime runtime = m3_NewRuntime (env, 64*1024, NULL);
    if (!runtime) FATAL("m3_NewRuntime failed");

    IM3Module module;
    result = m3_ParseModule (env, &module, wasm, fsize);
    if (result) FATAL("m3_ParseModule: %s", result);

    result = m3_LoadModule (runtime, module);
    if (result) FATAL("m3_LoadModule: %s", result);
    
    /*result = m3_LinkWASI (runtime->modules);
    if (result) FATAL("m3_LinkWASI: %s", result); 
    
    result = m3_LinkLibC (runtime->modules);
    if (result) FATAL("m3_LinkLibC: %s", result);*/
    
    IM3Function f;
    result = m3_FindFunction (&f, runtime, "fib");
    if (result) FATAL("m3_FindFunction: %s", result);

    const char* i_argv[2] = { "3", NULL };
    result = m3_CallWithArgs (f, 1, i_argv);

    if (result) FATAL("Call: %s", result);

    long value = *(long*)(runtime->stack);

    Serial.println(value);

}

void setup()
{
  Serial.begin(115200);
  delay(10);

  Serial.print("\nwasm3 on ESP8266, build " __DATE__ " " __TIME__ "\n");

  u32 start = millis();
  run_wasm();
  u32 end = millis();

  Serial.print(String("Elapsed: ") +  (end - start) + " ms\n");
}

void loop()
{
  delay(100);
}

... one of our ESP8266's throws the following error:

wasm3 on ESP8266, build Dec 27 2019 18:59:05
Fatal: m3_NewRuntime failed
Elapsed: 6 ms

Also, updating the code of the esp32-pio example along the same lines throws a Guru Meditation error, followed by a boot loop.

Might it be possible to provide a minimal working example that runs, for instance, fib32_wasm on ESP8266 and ESP32 using the latest version of wasm3?

(Separately, linking WASI gives rise to the following error on the ESP8266: /home/earle/src/esp-quick-toolchain/repo/newlib/newlib/libc/time/clock.c:62: undefined reference to _times_r ... but that is of course a different issue)

Bring wasm3 to a level where it can run itself. JFF ;)

Actions list:

• [x] Improve interpreter so it can execute itself
• [x] Build in 32-bit mode (normal native x86 build) and fix spec tests
• [x] Build wasm3.wasm
• [x] Improve test script so we can run spec tests on wasm3.wasm
• [x] Fix spec tests for wasm3.wasm
• [x] Fix imported (native) function calls
• [x] Implement MetaWASI (redirect WASI calls to the host WASI environment)
• [x] Run WASI apps in self-hosted mode
• [x] Run spec tests in self-hosted mode

All the platforms use the same fib32.wasm.h but I haven't found an example that interacts with the hardware peripherals like GPIO. Is that possible, even if with a bit of wasm<>C++ glue code? I could imagine something like wasm-bindgen be helpful here, or Interface Types when that's ready. But for now blinking an LED would be great :)

This PR adds the ability to print and also to obtain via the API backtraces when a trap is encountered during WASM execution, for this issue: https://github.com/wasm3/wasm3/issues/190

$ ./wasm3 panic_test.wasm
thread '<unnamed>' panicked at 'Argh!', src/lib.rs:14:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Error: [Fatal] repl_call: [trap] unreachable executed
wasm backtrace:
  0: 0x45c2 - .unnamed!__rust_start_panic
  1: 0x43e3 - .unnamed!rust_panic
  2: 0x4059 - .unnamed!_ZN3std9panicking20rust_panic_with_hook17h072472ae3822b936E
  3: 0x342 - .unnamed!_ZN3std9panicking11begin_panic28_$u7b$$u7b$closure$u7d$$u7d$17h071e97ff39f73a93E
  4: 0x309 - .unnamed!_ZN3std10sys_common9backtrace26__rust_end_short_backtrace17hef704c5aa373cc3aE
  5: 0x38d - .unnamed!_ZN3std9panicking11begin_panic17hec272784e336dab5E
  6: 0x2d0 - .unnamed!_ZN10panic_test3bar3baz17h1cc59b36f6073eaaE
  7: 0x2b9 - .unnamed!_ZN10panic_test3foo17hfc394019100935fbE
  8: 0x2b0 - .unnamed!_start
Error: [trap] unreachable executed ()

There are two main parts to this PR:

1. Reporting function frames when a trap is encountered to the runtime
2. Creating a mapping back from VM code to WASM bytecode offset

Reporting function frames is done by the addition of a new field on the M3Runtime struct for holding backtrace information. This seems like the simplest and least-invasive method since within an instruction we don't have access to too much context, but we do have a pointer back to the runtime. The basic idea is that when a trap occurs, the stack will look like this:

+-----------+
| trap site |
+-----------+
|  op_Entry |
+-----------+
|  op_Call  |
+-----------+
|  op_Entry |
+-----------+
|  op_Call  |
+-----------+
|  op_Entry |
+-----------+
|    ...    |

The trap site and all the op_Calls have the relevant program counter that we actually want to report to the backtrace frame, and the op_Entrys have the relevant M3Function that the trap site/op_Call is in. So when a trap is encountered, we push a new backtrace frame onto the runtime before returning the trap, and when unwinding through op_Call we check to see if we actually have a trap, and push a backtrace frame if so. When we unwind through an op_Entry, we check to see if we actually have a trap, and then fill in the function information on the last backtrace frame if so.

Since this only happens when a trap is encountered and we have to check the return value anyway in op_Call and op_Entry instructions the effect on performance should hopefully be minimal.

The second part is mapping the program counter back into WASM byte offsets. I've done kind of the most naive thing I can think of here, which is to allocate some space for this along with every code page and then store the mapping there. The current implementation wastes far too much memory unnecessarily so I'm very open to ideas for how to do this in a better way.

Otherwise, the method for generating the mapping entries is fairly simple - I store the byte offset just before every single opcode on the M3Compilation struct, and when an opcode is emitted I use that byte offset to emit an entry. This also generates the correct mapping for bridge instructions.

We need to come up with some stack access API, as currently we can only get function results by tampering with the stack directly. I.e. this has to be revised: https://github.com/wasm3/wasm3/blob/99bdcabdcd06c278d3ffd290348effb2f7b8fbbd/platforms/arduino/src/main.cpp#L48-L55

Please comment if you have any suggestions on the API.

• esp32-idf: Remove unneeded files
• Simplify main.c, remove leftovers from IDF hello-world example
• Sync ESP32 examples for IDF and PIO, check in CI that the source is kept the same
• Add a build job for esp32-idf
• Run the test in QEMU for esp32

./wasm3 smallpt-ex.wasm 4 32 | sha1sum Produces (correctly) ea05d85998b2f453b588ef76a1256215bf9b851c

However if smallpt-ex.wasm is build with -O3 or -Os flags, it produces wrong output. With -O2 or -Oz, it works as expected. They all execute fine in wasmer.

Pre-built binaries: smallpt.zip

As pointed out in https://github.com/wasm3/wasm3/issues/28#issuecomment-569831125, Xtensa port suffers from lack of tail call optimization in the compiler. Tail calls are possible on the ESP8266 (but not implemented in GCC) and aren't possible on the ESP32, due to the ABI limitation.

This PR aims to provide an alternative to tail calls as means of chaining primitive operations.

The idea is to modify the operation function signature as follows:

m3_ret_struct_t OP(pc_t _pc, u64 * _sp, m3reg_t _r0, f64 _fp0);

where return structure m3_ret_struct_t has the same layout (in registers) as the input arguments:

typedef struct {
    union {
        pc_t pc;
        m3ret_t err;
    };
    m3stack_t sp;
    m3reg_t r0;
    f64 fp0;
} m3_ret_struct_t;

No tail calls are performed, instead all the operations are called from the following loop:

    while (true) {
        m3_ret_struct_t rs = ((IM3Operation) *_pc)(_pc+1, _sp, _r0, _fp0);
        _pc = rs.pc;
        _sp = rs.sp;
        _r0 = rs.r0;
        _fp0 = rs.fp0;
        if (_sp == NULL) {
            return rs.err;
        }
    }

Zero/non-zero _sp is used to indicate whether execution should be continued (operation wants a tail call) or the loop should return (operation wants to return).

The theory (which I haven't tested yet) is that the C loop above can be implemented in a few assembly instructions. This is because the return values after function call are already in the right registers. So we only need to check if _sp is zero, increment the PC, and jump to the PC again.

At the moment this modification seems to pass the spec tests.

Another change is converting _mem into a global value. This is needed to make the operation arguments fit into the registers, as on Xtensa only 6 32-bit registers are used for argument passing. The rest of the arguments would have to be spilled onto the stack. If necessary, _mem can be made thread-local instead of global.

Currently, users of the C++ API cannot pass

1. a callable object
2. or a combination of C function pointer and its associated userdata

to the module::link method.

This makes implementing some features difficult, like linking a function with state.

Expected behavior:

There are some way for users of C++ API to link a function with associated userdata.

Thanks for your work! In the doc it's written that Windows is supported, do you know to what extent? Can I run it in Windows XP or Windows Vista or I must use recent OS?

Are there any examples of loading and running a .wasm file?

I've managed to parse/load module and find the function but cannot find anything on getting the function to execute successfully without throwing "missing imported function".

N.B. my .wasm file is just a simple rust function and print statement ATM (tried a few different things to export the function) compiled with wasm32-wasi targets.

Any pointers would be much appreciated. Thanks

When OpProfiling or OpTracing is enabled, wasm3 fails to build with clang-16 because the signature of the function with __attribute__(musttail) are incompatible with the calling function. For instance, the funciton profileOp has 6 parameters, but its caller function RunCode only has 5. Therefore, to satisfy the requirement of using __attribute__(musttail), I modify function signatures of these functions.

To test the effect of tail-call optimization, I disassembled the executable file of wasm3-0.5.0 compiled by clang-14 and clang-16. Other functions mentioned in Interpreter Architecture, such as op_u64_Or_rs, are truly optimized by tail-call optimization. When I check the assembly code of function op_Call, I expect it to not require the creation of a function stack. However, it does so in the assembly code I list below, so I speculate the tail-call optimization doesn't work on it.

After comparing other functions, such as p_f32_Sqrt_r, I discovered that if a function has a callq instruction, the function must create a function stack. So, I'm wondering if there are any operations in function op Call that prevent tail-call-elimination, such as this pull request, or if there are any limitations that prevent tail-call optimization from optimizing function op Call?

Issue reproducer

download wam3-0.5.0 source code 
cd wasm3-0.5.0
mkdir build
cd build
cmake -GNinja -DCLANG_SUFFIX="-16" ..
ninja
objdump -d wasm3

The result of disassembling

0000000000044bf0 <op_Call>:
   44bf0:	55                   	push   %rbp
   44bf1:	41 57                	push   %r15
   44bf3:	41 56                	push   %r14
   44bf5:	41 55                	push   %r13
   44bf7:	41 54                	push   %r12
   44bf9:	53                   	push   %rbx
   44bfa:	48 83 ec 18          	sub    $0x18,%rsp
   44bfe:	c5 fb 11 44 24 10    	vmovsd %xmm0,0x10(%rsp)
   44c04:	48 89 4c 24 08       	mov    %rcx,0x8(%rsp)
   44c09:	49 89 d4             	mov    %rdx,%r12
   44c0c:	49 89 f6             	mov    %rsi,%r14
   44c0f:	49 89 ff             	mov    %rdi,%r15
   44c12:	48 8b 2f             	mov    (%rdi),%rbp
   44c15:	48 63 5f 08          	movslq 0x8(%rdi),%rbx
   44c19:	4c 8b 2a             	mov    (%rdx),%r13
   44c1c:	e8 3f 92 ff ff       	callq  3de60 <m3_Yield>
   44c21:	48 85 c0             	test   %rax,%rax
   44c24:	75 49                	jne    44c6f <op_Call+0x7f>
   44c26:	49 8d 34 9e          	lea    (%r14,%rbx,4),%rsi
   44c2a:	48 8d 7d 08          	lea    0x8(%rbp),%rdi
   44c2e:	c5 f8 57 c0          	vxorps %xmm0,%xmm0,%xmm0
   44c32:	4c 89 e2             	mov    %r12,%rdx
   44c35:	31 c9                	xor    %ecx,%ecx
   44c37:	ff 55 00             	callq  *0x0(%rbp)
   44c3a:	48 85 c0             	test   %rax,%rax
   44c3d:	75 30                	jne    44c6f <op_Call+0x7f>
   44c3f:	49 8b 95 b8 29 00 00 	mov    0x29b8(%r13),%rdx
   44c46:	49 8b 47 10          	mov    0x10(%r15),%rax
   44c4a:	49 83 c7 18          	add    $0x18,%r15
   44c4e:	4c 89 ff             	mov    %r15,%rdi
   44c51:	4c 89 f6             	mov    %r14,%rsi
   44c54:	48 8b 4c 24 08       	mov    0x8(%rsp),%rcx
   44c59:	c5 fb 10 44 24 10    	vmovsd 0x10(%rsp),%xmm0
   44c5f:	48 83 c4 18          	add    $0x18,%rsp
   44c63:	5b                   	pop    %rbx
   44c64:	41 5c                	pop    %r12
   44c66:	41 5d                	pop    %r13
   44c68:	41 5e                	pop    %r14
   44c6a:	41 5f                	pop    %r15
   44c6c:	5d                   	pop    %rbp
   44c6d:	ff e0                	jmpq   *%rax
   44c6f:	48 83 c4 18          	add    $0x18,%rsp
   44c73:	5b                   	pop    %rbx
   44c74:	41 5c                	pop    %r12
   44c76:	41 5d                	pop    %r13
   44c78:	41 5e                	pop    %r14
   44c7a:	41 5f                	pop    %r15
   44c7c:	5d                   	pop    %rbp
   44c7d:	c3                   	retq   
   44c7e:	66 90                	xchg   %ax,%ax