github
/
tinygo
mirror of https://github.com/tinygo-org/tinygo.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
3565 Commits
99 Branches
41 Tags
26 MiB
Tree: 5b581d83b3
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '5b581d83b3'
${ noResults }
tinygo/targets/wasm.json

27 lines
650 B
Raw Normal View History

all: add WebAssembly backend
6 years ago
{
build: normalize target triples to match Clang This commit changes a target triple like "armv6m-none-eabi" to "armv6m-unknown-unknow-eabi". The reason is that while the former is correctly parsed in Clang (due to normalization), it wasn't parsed correctly in LLVM meaning that the environment wasn't set to EABI. This change normalizes all target triples and uses the EABI environment (-eabi in the triple) for Cortex-M targets. This change also drops the `--target=` flag in the target JSON files, the flag is now added implicitly in `(*compileopts.Config).CFlags()`. This removes some duplication in target JSON files. Unfortunately, this change also increases code size for Cortex-M targets. It looks like LLVM now emits calls like __aeabi_memmove instead of memmove, which pull in slightly more code (they basically just call the regular C functions) and the calls themself don't seem to be as efficient as they could be. Perhaps this is a LLVM bug that will be fixed in the future, as this is a very common occurrence.
3 years ago
"llvm-target": "wasm32-unknown-wasi",
targets: add CPU property everywhere This is for consistency with Clang, which always adds a CPU flag even if it's not specified in CFLAGS. This commit also adds some tests to make sure the Clang target-cpu matches the CPU property in the JSON files. This does have an effect on the generated binaries. The effect is very small though: on average just 0.2% increase in binary size, apparently because Cortex-M3 and Cortex-M4 are compiled a bit differently. However, when rebased on top of https://github.com/tinygo-org/tinygo/pull/2218 (minsize), the difference drops to -0.1% (a slight decrease on average).
3 years ago
"cpu": "generic",
wasm: use newer WebAssembly features This commit will start to use a few more WebAssembly features, such as bulk memory operations. This results in a significant code size saving. How much it saves varies a lot but it's typically around 1300 bytes. This change is possible by bumping our minimum Node.js version to 14. The previous LTS version (12) has been marked end of life, so we can start to depend on features in the current oldest LTS version, which is version 14. Browsers have been supporting these features for a long time now, it's just Node.js that prevented us doing this before.
2 years ago
"features": "+bulk-memory,+nontrapping-fptoint,+sign-ext",
wasi: remove wasm build tag The wasm build tag together with GOARCH=arm was causing problems in the internal/cpu package. In general, I think having two architecture build tag will only cause problems (in this case, wasm and arm) so I've removed the wasm build tag and replaced it with tinygo.wasm. This is similar to the tinygo.riscv build tag, which is used for older Go versions that don't yet have RISC-V support in the standard library (and therefore pretend to be GOARCH=arm instead).
3 years ago
"build-tags": ["tinygo.wasm"],
wasm: add GOOS/GOARCH properties This was an oversight in commit 107fccb288.
6 years ago
"goos": "js",
"goarch": "wasm",
main: use wasm-ld instead of wasm-ld-8 on macOS This commit does a few things: * remove the -8 suffix on macOS, where it is not necessary * add smoke tests for compiling wasm files on Linux and macOS
6 years ago
"linker": "wasm-ld",
wasi: specify wasi-libc in a different way This way is more consistent with how picolibc is specified and allows generating a helpful error message. This error message should never be generated for TinyGo binary releases, only when doing local development.
4 years ago
"libc": "wasi-libc",
internal/task: use asyncify on webassembly This change implements a new "scheduler" for WebAssembly using binaryen's asyncify transform. This is more reliable than the current "coroutines" transform, and works with non-Go code in the call stack. runtime (js/wasm): handle scheduler nesting If WASM calls into JS which calls back into WASM, it is possible for the scheduler to nest. The event from the callback must be handled immediately, so the task cannot simply be deferred to the outer scheduler. This creates a minimal scheduler loop which is used to handle such nesting.
3 years ago
"scheduler": "asyncify",
targets (wasi/wasm): raise default stack size to 16 KiB In some cases, 8 KiB is not enough for both the C stack and the asyncify stack. This gets the compress/zlib tests to fail without crashing.
3 years ago
"default-stack-size": 16384,
wasm: use newer WebAssembly features This commit will start to use a few more WebAssembly features, such as bulk memory operations. This results in a significant code size saving. How much it saves varies a lot but it's typically around 1300 bytes. This change is possible by bumping our minimum Node.js version to 14. The previous LTS version (12) has been marked end of life, so we can start to depend on features in the current oldest LTS version, which is version 14. Browsers have been supporting these features for a long time now, it's just Node.js that prevented us doing this before.
2 years ago
"cflags": [
"-mbulk-memory",
"-mnontrapping-fptoint",
"-msign-ext"
],
wasm: fix .json file after compiler updates
6 years ago
"ldflags": [
wasm: do not allow undefined symbols --allow-undefined can be a problem: it allows compiling code that will fail when loaded. This change makes sure that if some symbols are undefined, they are reported as an error by the linker. Previously, people could get away with importing a function that was not defined, like this: func add(int a, int b) int func test() { println(add(3, 5)) } This was always unintended but mostly worked. With this change, it isn't possible anymore. Now every function needs to be marked with //export explicitly: //export add func add(int a, int b) int func test() { println(add(3, 5)) } As before, functions will be placed in the `env` module with the name set from the `//export` tag. This can be overridden with `//go:import-module`: //go:import-module math //export add func add(int a, int b) int func test() { println(add(3, 5)) } For the syscall/js package, I needed to give a list of symbols that are undefined. This list is based on the JavaScript functions defined in targets/wasm_exec.js.
2 years ago
"--allow-undefined-file={root}/targets/wasm-undefined.txt",
wasm: set the stack at the start of linear memory This makes sure that a stack overflow will cause a "memory access out of bounds" error instead of a corruption of a global variable. Here is more background on a very similar stack overflow protection: https://blog.japaric.io/stack-overflow-protection/
5 years ago
"--stack-first",
wasi: specify wasi-libc in a different way This way is more consistent with how picolibc is specified and allows generating a helpful error message. This error message should never be generated for TinyGo binary releases, only when doing local development.
4 years ago
"--no-demangle"
all: add WebAssembly backend
6 years ago
],
wasm: fix GC scanning of allocas Scanning of allocas was entirely broken on WebAssembly. The code intended to do this was never run. There were also no tests. Looking into this further, I found that it is actually not really necessary to do that: the C stack can be scanned conservatively and in fact this was already done for goroutine stacks (because they live on the heap and are always referenced). It wasn't done for the system stack however. With these fixes, I believe code should be both faster *and* more correct. I found this in my work to get opaque pointers supported in LLVM 15, because the code that was never reached now finally got run and was actually quite buggy.
2 years ago
"extra-files": [
"src/runtime/asm_tinygowasm.S"
],
wasm: remove i64 workaround, use BigInt instead Browsers previously didn't support the WebAssembly i64 type, so we had to work around that limitation by converting the LLVM i64 type to something else. Some people used a pair of i32 values, but we used a pointer to a stack allocated i64. Now however, all major browsers and Node.js do support WebAssembly BigInt integration so that i64 values can be passed back and forth between WebAssembly and JavaScript easily. Therefore, I think the time has come to drop support for this workaround. For more information: https://v8.dev/features/wasm-bigint (note that TinyGo has used a slightly different way of passing i64 values between JS and Wasm). For information on browser support: https://webassembly.org/roadmap/
2 years ago
"emulator": "node {root}/targets/wasm_exec.js {}"
all: add WebAssembly backend
6 years ago
}