M3ErrorInfo originally used a fixed string array to simplify & avoid memory ownership issues. The pointer mechanism in use now is getting nullified when m3_GetErrorInfo is called so no actual error information is show.

Wasm3 is fast, but we didn't even get to profiling yet.

As noted by @dstogov:

Comparing wasm3 performance with PHP and converting this test to PHP... Actually, php master branch, compiled by GCC, with opcache/optimizer enabled (without JIT) is a bit (~15%) faster. I'm a bit surprised, because our VMs achieve very similar VM assembler code (by different ways), WASM code and data are simpler to interpret, and you made additional optimization for accumulator register. For some reason, wasm3 suffers from branch miss-prediction (more than 10 time more misses than PHP) and cache misses (almost 100 times more L1 DCache misses). Measured with Linux perf stat.
$ perf record -e L1-dcache-load-misses ./wasm3 mandel.wasm
$ perf report -n
It looks like, your virtual code segment evicted from CPU cache too often.
Fixing this, should significantly improve performance.
However, this also may be related to bad indirect branch prediction and speculative execution.

If you have any other ideas on how to improve performance, please comment here.

https://github.com/WebAssembly/bulk-memory-operations

For projects built with CMake build system, the natural way of using wasm3 would be to call add_subdirectory to include wasm3 as a static library. However the root CMakeLists file contains a lot of logic related to host app builds, so it may be not suitable for the purpose.

It seems that one way to expose a static library would be to add a CMakeLists.txt file into the source directory, then add this library using add_subdirectory and target_link_libraries in the CMakeLists files which want to use this library. This is in line with the "modern CMake" approach to structuring CMake projects. It helps eliminate hacks like symlinks in platform-specific examples (at least the ones which are built using CMake).

If noone sees a problem with this, I will open a PR for such refactoring.

How hard would be to add ability to execute multithreaded code (from WebAssembly app point of view) by a single system thread? Something like WebAssembly/design#1321?

https://github.com/WebAssembly/mutable-global

It seems that wasm3 runs quite slow in iOS. Anyone has similar cases?

I understand that the project is moving quite quickly, so some number of warnings may be acceptable. However I've already bumped into an issue which would have been very easy to spot, would it be not for the -w build flag.

I think selectively disabling certain warnings known for specific source files will be safer than disabling all the warnings for all the source files.

Opening this issue to track the clean-up and re-enabling of warnings.

This will allow us to easily embed in other programs and swap the runtimes without learning specific.

https://github.com/WebAssembly/wasm-c-api

If the WASI exit API is invoked, the runtime currently traps and prints an error and ignores the return code. The behavior (at least when not executing in REPL mode) should be to exit the runtime and return the code value used to call.

Here is a half solution that doesn't error and always returns 0. I'm not sure how to correctly read the top of the stack in main:

diff --git a/platforms/app/main.c b/platforms/app/main.c
index 97ead22..f633aa4 100644
--- a/platforms/app/main.c
+++ b/platforms/app/main.c
@@ -273,6 +273,11 @@ int  main  (int i_argc, const char* i_argv[])
             } else {
                 result = repl_call(runtime, argFunc, i_argc, i_argv);
             }
+            if (result && result == m3Err_trapExit) {
+                // TODO: correct thing here
+                // int ret = ((m3reg_t*)(runtime->stack))[runtime->stackSize];
+                return 0;
+            }
             if (result) FATAL("repl_call: %s", result);
         }
     }
diff --git a/source/m3_api_defs.h b/source/m3_api_defs.h
index fb9e7af..56df9f5 100644
--- a/source/m3_api_defs.h
+++ b/source/m3_api_defs.h
@@ -20,6 +20,7 @@
 
 #define m3ApiRawFunction(NAME)     const void * NAME (IM3Runtime runtime, uint64_t * _sp, void * _mem)
 #define m3ApiReturn(VALUE)         { *raw_return = (VALUE); return m3Err_none; }
+#define m3ApiExit(VALUE)           { *raw_return = (VALUE); return m3Err_trapExit; }
 #define m3ApiTrap(VALUE)           { return VALUE; }
 
 #endif // m3_api_defs_h
diff --git a/source/m3_api_wasi.c b/source/m3_api_wasi.c
index 437cb61..ad1639f 100644
--- a/source/m3_api_wasi.c
+++ b/source/m3_api_wasi.c
@@ -623,7 +623,7 @@ m3ApiRawFunction(m3_wasi_unstable_proc_exit)
         fprintf(stderr, M3_ARCH "-wasi: exit(%d)\n", code);
     }
 
-    m3ApiTrap(m3Err_trapExit);
+    m3ApiExit(code);
 }
 
 

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:

Please comment if you have any suggestions on the API.

the operations fields are actually not used for many operations. Could you please clean them up? It's quite confusing.

To access non-integer results from WebAssembly modules, I generally first retrieve respectively the location and the length of a result variable as previously allocated to the linear memory of the WebAssembly instance. This enables us to consequently read (or write) to that memory area. For a Golang example, see for instance:

https://github.com/wasmerio/go-ext-wasm#read-the-memory

memory := instance.Memory.Data()
// Reads the memory.
result := memory[pointer : pointer+length]
// now you can parse "result" 

I presume that in wasm3, I would need to access M3Memory? I am, however, unsure how to interface with it. Could you suggest how best to proceed to obtain access to linear memory from wasm3?

https://github.com/WebAssembly/sign-extension-ops

I get errors when compiling the "source" folder with a C++ compiler, here on macOS 10.13. Any plan to allow that?

Hi, while working on #38 I did some experiments like building libxml2 as a WASM module.
I'm not able to load it using the current master as it seems to trigger typeListOverflow. Not sure if this is temporary or something related to the specs.

If you want to try it out, you can grab libxml2.wasm from here. In the meantime I'm able to use the module by tweaking d_m3MaxNumFunctionArgs in m3_config.h:

index a10cf61..e5bd84d 100644
--- a/source/m3_config.h
+++ b/source/m3_config.h
@@ -11,7 +11,7 @@
 #include "m3_config_platforms.h"
 
 # ifndef d_m3MaxNumFunctionArgs
-#   define d_m3MaxNumFunctionArgs               16
+#   define d_m3MaxNumFunctionArgs               32
 # endif
 
 # ifndef d_m3CodePageAlignSize

Regards.

Bring wasm3 to the level where it can run CoreMark, so we have more reliable numbers of it's performance.
In general we need to:

• Build CoreMark to WASM
• Benchmark some popular wasm runtimes using CoreMark
• Implement the needed imported functions for wasi or emscripten interfaces
• Improve implementation (mostly by running spec tests and fixing inconsistencies)

It's due to that for each "Entry" operation, we have to copy all the arguments? I think we should definitely fix this.

It looks like that the wasmStack[0..args - 1] are not actually used. Can we leverage them to reference other slots vs copying the other slots?

Implement Rust bindings, so wasm3 can be easily used from Rust.

Most operations "know" exactly which type they are consuming. Notable exceptions are:

• Drop
• Select

According to this comment, we can deduce the type during compile time.

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)

Implement Go bindings, so wasm3 can be easily used from Go.

The wast2json tool was updated (WebAssembly/wabt#1275), and we can now switch to the latest spec tests release: https://github.com/WebAssembly/spec/releases/tag/v1.1
I did some preliminary tests and everything looks good except a few minor issues:

• in call.0.wasm, we now have a function with 100 arguments, so the whole module fails to load due to d_m3MaxNumFunctionArgs=16. Increasing the limit helps. I think we need to allow loading such modules, and fail on the event of function call.
• names.wast now checks more unicode characters => escaping mechanism has to be updated

This ticket is created to track the progress.

Hello, I was reading the README.md and saw the Thoughts & Questions about WebAssembly section asking for some answers.

Linear memory: Modules seem hardcoded to request 16MB of memory. What? Why?

This is just the default settings of the toolchain produced the modules. Most toolchains have flags for changing the memory size.

As the host, where can I safely allocate things in linear memory? Who's in charge of this 16MB?

In general, you can't. The application is in charge, and hosts shouldn't make any assumptions about how applications manage their memory. Often the way to avoid needing to do this is to ask the application to do an allocation, and pass the VM a pointer to it.

Traps: The spec says "Signed and unsigned operators trap whenever the result cannot be represented in the result type." Really? That's cool, but how can the behavior of source languages be modeled (efficiently)? C integer operations wrap and sometimes that's what you want.

It's admittedly subtle, but wasm's add, sub, and mul aren't considered signed or unsigned, so that rule doesn't apply to them and they wrap rather than trap.

https://github.com/vshymanskyy/wasm3/blob/f189e42c3e0eef77b6610b671ae642c566b8fe69/source/m3_exec.c#L46

To reproduce this problem, run the spec test:

./run-spec-test.py ./core/call_indirect.json

Actual result: It fails with a few items like this:

Expected result: spec test is passed

I've noticed that esp32-idf example doesn't define -DESP32, so d_m3MaxFunctionStackHeight is not overridden in m3_config_platforms.h:

Once I add -DESP32, the example stops working, and crashes with null pointer dereference at

Not sure how to interpret this, as it was reported in #26 (comment) that esp32-pio example (which I assume defines -DESP32) works okay. I don't have a working PIO environment so can't verify that.

In CopyTopSlot, we can just use op_CopySlot_64. op_CopySlot_32 is unnecessary.

In which situation we need this and why it's not implemented yet?

https://github.com/WebAssembly/tail-call

Currently return_call (0x12) and return_call_indirect (0x13) are just aliases of call and call_indirect.
For these operations, we could actually reuse the stack frame to optimize memory usage.

Basically, just need to implement 2 wasi functions:

The call could be nested. So numActiveCodePages should be added beforehand.

should be
∼ 4.5x slower

Currently, memory addresses in Load and Store operations are cast to u64 to workaround address overflow (i.e. on 32-bit platforms):

• Find more efficient way of checking overflows, that would also work for 64-bit address space in future
• Add compile-time flag to skip those checks (i.e. for benchmarks)

Currently, when running run-spec-test.py, assert_exhaustion and action is just skipped.
To support this, we need:

1. Modify wasm3 to fail gracefully when running out of resources (stack, for now?)
2. Update run-spec-test.py to run/verify those tests

Test:

./run-spec-test.py ./core/fac.json --line 89

Actual Result:

Warning: Skipped fac.wast:89 assert_exhaustion

Expected Result: test is passed

The "Empty Stack" case is not correctly verified by the test script.
Currently "Empty Stack" is printed every time when the function has no return values (but this is not an indicator of an empty stack). I think we can add a new repl command to print the actual stack state.

Basically, just need to implement 2 wasi functions:

It seems that it's used to defer the unwind of stack. Could anyone elaborate more on this?

I would like to point out that an identifier like “__wasi_core_h” does eventually not fit to the expected naming convention of the C language standard.
Would you like to adjust your selection for unique names?

In Ubuntu Xenial 16.04 it does not have /usr/include/sys (there is a /usr/include/linux/random.h, but no getrandom defined)

It appears in Bionic (18.04) however.

What is the minimum version of glibc is recommended?

Do you intend to support 16.04 ?

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 :)

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

Actions list:

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

https://github.com/WebAssembly/nontrapping-float-to-int-conversions

https://github.com/WebAssembly/multi-value

I have been trying to embed WASM in vim as default. I had send one PR on embedding JS to vim vim/vim#5198.

Is it possible to just have 2 files wasm3.h and wasm3.c in the output similar to how duktape does it to make it easy to embed in other programs? This way I can just #include "wasm3.h" and don't have to worry about it.