WebAssembly to Lua translator, with runtime

Due to it being kind of annoying, no code is currently generated for an assert_trap that takes a module argument. The intended behavior here is for its start function to run and trap.

https://github.com/Rerumu/Wasynth/blob/master/dev-test/tests/luajit_translate.rs#L90 https://github.com/Rerumu/Wasynth/blob/master/dev-test/tests/luau_translate.rs#L103

Many 32 bit tests are only failing due to the usage of 64 bit libraries. For example, int_literals.wast.lua loads a constant 4294967295 and compares it with -1 in one of its tests, but this fails due to the usage of rt.eq.i64 in luau_assert.lua. There are several more complex cases like this.

I am making a note of this for discussion. I'm not sure if it relates to #8 or not, but the br_table.wast test fails to compile in luau due to the following error message:

/home/hexcede/programming/Wasynth/target/tmp/br_table.wast.lua:1076: Exceeded allowed recursion depth; simplify your expression to make the code compile
stacktrace:

The referenced line is the creation of loaded["temp"] and my syntax highlighter fails to highlight this section making it difficult to tell exactly what's going on. My understanding of this error is that the wasm module is generating too many nested functions at compile time, however I could be wrong there.

This would likely require some sort of codegen changes to account for.

When the loop.wast test is ran under luau, it hangs due to a non-breaking loop somewhere. Is this a regression, or is it due to better compatibility allowing the test to run far enough to hang?

Perhaps loop.wast is added to the DO_NOT_RUN list.

P.s. I am not familiar with rust tests, but, it should be possible to use rust's own test filtering instead of what is present, that way the number of skipped tests will be present in the log which would help with watching for regressions.

So far, this contains store.f32, store.f64, store.i64_n32, store.i64_n16, and store.i64_n8 implementations for luau.

I would additionally like to implement all of these load variants:

• load.i32_u16
• load.i64_i32
• load.i64_i16
• load.i64_i8
• load.i64_u32
• load.i64_u16
• load.i64_u8

This would satisfy the conditions for address.wast.lua and align.wast.lua to both pass under luau.

This PR fixes several implementation issues in numeric.lua and runtime.lua and migrates math.min and math.max to runtime.lua to account for luau discrepancy (math.min(0, NaN) and math.max(0, NaN) return 0 instead of NaN)

This allows the f64.wast test to pass along with three others (33 passing tests -> 37 including f64.wast)

We were noticing behavioral differences with our program transpiled with Wasynth running on Roblox on Windows and other platforms.

@vegorov-rbx investigated this; thanks a ton! His (paraphrased) findings are below:

In the Luau Wasynth runtime, to_u32 is defined as bit32.band.

https://github.com/Rerumu/Wasynth/blob/0394aa8895e7f0429342adb2a88b3b3d6cbcf67c/codegen/luau/runtime/runtime.lua#L3

In div.i32 and div.u32, the results of division is passed directly to to_u32.

https://github.com/Rerumu/Wasynth/blob/0394aa8895e7f0429342adb2a88b3b3d6cbcf67c/codegen/luau/runtime/runtime.lua#L78-L91

Luau 5.2, from which Luau was forked, specifies the following:

Unless otherwise stated, all functions accept numeric arguments in the range (-251,+251); each argument is normalized to the remainder of its division by 232 and truncated to an integer (in some unspecified way), so that its final value falls in the range [0,232 - 1].

The behavior varies based on platform:

• Lua 5.2 x86 depends on processor rounding mode (default round to +Inf)
• Lua 5.2 x64 uses round to +Inf
• Luau x86 depends on processor rounding mode (default round to +Inf)
• Luau x64/arm truncates (round to 0)

Some differences can be observed in the Luau codebase. For example, here is how numbers are converted to unsigned integers on Windows x86.

This can be fixed by changing the runtime to truncate the numbers before passing to bit32.band. One potential way of doing this is using modf:

local i, _ = math.modf(lhs / rhs)
return to_u32(i)

The LuaJIT runtime also seems to have some truncation logic baked in which could be adopted for Luau as well.

I can confirm adding the math.modf fix resolves the behavioral differences on the Windows Roblox client for our transpiled program. I was unable to get a minimal CLI repro as Luau Windows CLI appears to be compiled to an x64 target and the bug affects x86. It should be pretty straightforward to repro this in Roblox if necessary by observing the rounding/truncation on a published place on the Windows Roblox client (note that the bug doesn't repro in Studio.)

There are better, much faster ways to calculate these. When I wrote them it was to get things working, and haven't had the time to properly revise it.

https://github.com/Rerumu/Wasynth/blob/5eb85523adc5d532186a74c33c430b043f135c83/codegen/luajit/runtime/runtime.lua#L145-L213

(Referencing luau codegen files) This was previously discussed in the Roblox Developer Discord server but I wanted to make a note of it here.

In statement.rs line 277 and expression.rs line 95 there are usages of the i64_K_ZERO constant and the i64_from_u32 function which are not automatically emitted by these paths.

The most likely solution that was discussed is to just emit these in the header from the rust side of things IIRC.

The BrTable AST node is currently not emitted with any form of optimization, as it used to be. The reason being that this causes problems consolidating the stack as different branches have different alignments that must be emitted before doing the jump.

Nonetheless, it should still be possible to at least generate a binary search instead of a linear search for the branch or otherwise optimize the lookup.

https://github.com/Rerumu/Wasynth/blob/master/codegen-luajit/src/backend/statement.rs#L31 https://github.com/Rerumu/Wasynth/blob/master/codegen-luau/src/backend/statement.rs#L42

The WebAssembly specification is not very clear on what a well-formed constant looks like, or how many constant instructions it may allow. As such, right now write_constant implementations for offsets and other values end up creating an entire function just to call it and receive its value.

This makes would would otherwise be 1 line (the expression of the constant) turn into at least 5 lines. It would be great if all this noise could be removed without breaking any unspoken rules.

https://github.com/Rerumu/Wasynth/blob/master/codegen-luajit/src/translator.rs#L51 https://github.com/Rerumu/Wasynth/blob/master/codegen-luau/src/translator.rs#L50

For very complex programs, often Wasynth will generate Lua code which exceeds the limit of 255 registers (local variables/function arguments.) For example, attached is a program which, when translated and run, tries to allocate 402 registers.

Is there a way to work around this, either in Wasynth or upstream? Or is there no way to avoid this besides implementing more sophisticated algorithms in Wasynth to handle allocation and spilling?

hello.zip

I don't have much idea of what's going on here, but I think this is a step in the right direction. Please be very vigilant for mistakes as I'm sure they are present. I hope that I can quickly learn and become a net-positive contributor. I started working on this because of this issue.

A few questions that came up when writing this:

1. The source of the operators, wasmparser, seems to have some fields listed in the structs, but others are missing. For example, their struct for MemoryCopy only has the src and dst fields, whereas there is also a third parameter according to the spec, the amount of memory to copy n. I assumed that this was popped off the stack explicitly - I have no idea why it's like this. MemoryFill is even weirder, only containing one field in the struct, mem and having two more in the spec, value and len. Any context on this?

2. Why are the parameters not listed in wasmparser Box<Expression> rather than u32, which I'm pretty sure they are according to the spec? Why are they visited in visit.rs?

3. How do I test this? I try running cargo test but that seems to have a ton of failures. Not sure if it's like that normally. I inspected some of the generated files and I see code which looks approximately right but the tests still fail unfortunately. Not sure if there is a way that people usually manually test this.

Thanks for your help in taking a look at this!

Trying to compile CPython for a challenge and see the error

thread 'main' panicked at 'Unsupported instruction: MemoryCopy { src: 0, dst: 0 }', wasm-ast/src/factory.rs:616:18

The spec has more details about these instructions.

For reference, the wasm file is here: python.wasm.zip

Might have a go at implementing this if I have some spare time.

Right now LuaJIT code suffers a performance penalty because the JIT is not always capable of inferring that operations on i32 are for integers. This causes a lot of f64-oriented native code to be generated that could have been i32 operations.

I don't know of any good ways of passing in strong type hints to the JIT other than just replacing all uses of i32 with the i64 type and truncating results.

Right now when BrTable is translated, it always uses a combination of a lookup table and binary search tree. This is efficient, but not necessarily optimal for when the number of targets is small. In this case it is preferable to just emit a binary search tree directly for about a dozen items or less.