tinygo
tinygo copied to clipboard
tinygo-org
feat:add new target to support wasm freestanding
I want to bikeshed the tag. unknow_wasm should probaby be unknown_wasm at least (to fix the spelling error), but I wonder if we want something like barewasm (similar to baremetal) to indicate exactly what we're building for?
@dgryski barewasm seems a reasonable tag name. I think developers are very much in need of https://github.com/tinygo-org/tinygo/issues/3068. Although WASM was originally designed for browser front-end development, new use cases are being raised for VMs in the blockchain dev communities, and various cross-platform algorithm implementations. One of the most important things is that WASM can take good advantage of the existing technical capabilities of various languages. This PR aims to better support the Go standard library and the existing Go code on github to be ported to wasm with minimal changes. In fact, Rust achieves this goal through a similar approach (like this PR). As a result, A lot of developers use this feature in RUST to build the WASM projects. If TinyGo can merge this approach, I believe it will help the TinyGo project to have an even larger adoption rate in regard to WASM projects.
for the bikeshed I think 'freestanding' is in use for wasm for something similar (maybe zig?) would be cool to use common conventions esp if there aren't strong feelings about it. @mathetake do you have any opinion?
for the bikeshed I think 'freestanding' is in use for wasm for something similar (maybe zig?) would be cool to use common conventions esp if there aren't strong feelings about it. @mathetake do you have any opinion?
its better to use freestanding than unknown. @dgryski any better idea
zig cc -target wasm32-freestanding test.c -o test -lc
From the looks of those CI errors, someone needs to rebase this branch against the latest dev
How far is the progress on this? I would really like to use this to make an shfmt plugin for dprint.
How far is the progress on this? I would really like to use this to make an shfmt plugin for dprint.
dprint？this pr remove all print support
dprint is a code formatter written in Rust that supports plugins in bare wasm. The only thing These wasm files have to do is export some functions that dprint will then call, but it does not provide WASI or emscripten or any other interface. The dprint wasm plugins written in Rust all target wasm32-unknown-unknown. It has nothing to do with printing.
dprint is a code formatter written in Rust that supports plugins in bare wasm. The only thing These wasm files have to do is export some functions that dprint will then call, but it does not provide WASI or emscripten or any other interface. The dprint wasm plugins written in Rust all target
wasm32-unknown-unknown. It has nothing to do with printing.
so you are planning to use golang formatter to generate wasm plugin?
Yes. I want to create a wasm binary including the shfmt shell formatter that is written in Go. Thus the plugin itself must also be written in Go, as it depends on shfmt.
But back to the original question, how far is the progress on this? Is it already somehow usable? I am sure this target is what I need for my use case.
Yes. I want to create a wasm binary including the shfmt shell formatter that is written in Go. Thus the plugin itself must also be written in Go, as it depends on shfmt.
But back to the original question, how far is the progress on this? Is it already somehow usable? I am sure this target is what I need for my use case.
there are still some behaviors that cannot be determined which method is better, especially the time part,should be panic or follow behavior suggested by @codefromthecrypt. If the current demand is strong, you can also consider this idea https://github.com/ipfs-force-community/go_tinygo_patch
for using increasing value for time return, this could make ramdom worked, but increase risk because randomness can be predicted.
Any update on this? Happy to contribute if needed, or are you still trying to establish behavior?
Any update on this? Happy to contribute if needed, or are you still trying to establish behavior?
This pr should work normally, but I don't know how to make tinygo accept this target. The behavioral aspect tends to keep the existing implemented behavior. There is a security risk in using self increasing time. development usually use time.Now as a random seed. especially in the financial smart contract.
We're nearing a year since @hunjixin raised this. The last question was "how to make tinygo accept this target"
Could someone lay out what is required to get this in, sounds like getting the build to pass is a given. What else can be checked off?
Valid point @codefromthecrypt
@dgryski @aykevl what are your thoughts on this? Also while keeping in mind upcoming changes for Go1.21+
when I build it tinygo build -o main.wasm -target=unknow_wasm main.go, and run it with wasmer. The following error shows:
error: Unable to instantiate the WebAssembly module
╰─▶ 1: Error while importing "env"."tinygo_getCurrentStackPointer": unknown import. Expected Function(FunctionType { params: [], results: [I32] })
I would like to have this sort of functionality myself to be able to run TinyGo compiled code on WAMR.
I think since the naming of wasm32-unknown-unknown is the most standard, so probably -target=wasm32-unknown and build tag wasm32_unknown would be the best option since there are more people doing this sort of thing with WASM in C or Rust at the moment.
Regarding getting this change accepted, there needs to be some tests showing that it works as expected. Some tests similar to the wasi target is the most likely place to look for inspiration.
Thanks for working on this, and let me know how I can help out.
Now that #4125 has been merged, I am closing this one. Thanks again everyone!