Compile Wasm without Wasi, scheduler, gc

[willemneal]

I have a use case where I want to create a Wasm module that only imports my runtime functions and doesn't require a scheduler or gc. This also means that I don't need the Wasi imports as I will implement my own log function, etc.

The gc cli flag seemed to work fine. However, when I tried to compile without the scheduler I get: /usr/local/Cellar/tinygo/0.14.1/src/runtime/runtime_wasm.go:60:2: attempted to start a goroutine without a scheduler

Is there any way to specify the runtime instead of using the one packaged with the project?

I found this issue: #1123 but the resolution seems to be just use Wasi.

[aykevl]

What is your use case? You can't just remove the runtime. The runtime provides many important bits necessary in all kinds of normal Go, such as everything related to scheduling (goroutines, channels, locks, ...) but also other important bits like map operations and slice copying/appending. Even converting between string and []byte is done in the runtime. So, the runtime is absolutely essential for normal Go code to work.

[willemneal]

My use case is for creating a smart contract for NEAR protocol. So we only have a set of c-like functions to interact with the host, which don't include Wasi. Also each time that a contract is run it is a short lived so there is no need for garbage collection. The size of binary is another cost for the app developer so the smaller the footprint for the runtime the better.

I'm not saying throwing away the runtime completely, rather just point to a file that I can edit.

As for the scheduler, under a single threaded instance, does it just act as a run loop queueing up async calls? I had wanted to remove it for the binary size, but if it is needed to by go deps that users might use, it's worth it.

Honestly I just want to have no Wasi imports and GC and that'd be enough for a PoC.

[aykevl]

TinyGo is already heavily optimized for code size. All bits that the compiler can prove are unnecessary will already be optimized out. So as an example, if you never append a slice the runtime won't contain the sliceAppend function.

Honestly I just want to have no Wasi imports and GC and that'd be enough for a PoC.

How do you use the binary without WASI imports? At some point, it will need to communicate with the outside world (for example, to log a panic message).

[willemneal]

I'd use these imports: https://github.com/near/near-sdk-as/blob/master/sdk-core/assembly/env/env.ts

[c0mm4nd]

I agree with that compiling a pure wasm. Currently browser is not the only runtime for deploying wasm modules, we use wasm as a sandbox or plugin in some future products.

take an example:

we want a packed fibonacci func, helping host program do reliable calculation

package main

func main() {}

//export fibonacci
func fibonacci(in uint32) uint32 {
	if in <= 1 {
		return in
	}
	return fibonacci(in-1) + fibonacci(in-2)
}

but tinygo's wasm will blindly import a fd_write, no use at all.

When we are using WASI on wasmer or wasmtime, we have to switch WASI support on and specify the files on read and write, which do not relate to our actual business.

In this circumstance, rust's wasm32-unknown-unknown works best with a pure wasm output and we can bind all our host func on it, and I hope tinygo can provide a similar target like this.

[toonsevrin]

+1 for omitting the wasi runtime import if not used: there are other execution environments then the browser nowadays and the one I use does not allow execution of wasm files that have unlinked imports.

[codefromthecrypt]

I think the best issue to use for this is #3068 as it elaborates the solution and has one in progress. If you agree @willemneal, do you mind closing this one? Less issues == more focus

[willemneal]

@codefromthecrypt Great! closing now!