Compared to the already supported stm32f103xx "bluepill" board this:
- features 128 KiB flash memory size ("RB" suffix) instead of 64 KiB, see `targets/stm32f103rb.ld`
- has onboard ST-LINK/V2-1 programmer and debugger requiring different OpenOCD configuration file
- uses USART2 connected to ST-LINK/V2-1 debugger as virtual COM port over USB for `putchar()`
- has a user-accessible button besides the reset button
This scheduler is intended to live along the (stackless) coroutine based
scheduler which is needed for WebAssembly and unsupported platforms. The
stack based scheduler is somewhat simpler in implementation as it does
not require full program transform passes and supports things like
function pointers and interface methods out of the box with no changes.
Code size is reduced in most cases, even in the case where no scheduler
scheduler is used at all. I'm not exactly sure why but these changes
likely allowed some further optimizations somewhere. Even RAM is
slightly reduced, perhaps some global was elminated in the process as
well.
Strings are emitted in .rodata sections, which are not yet mentioned in the linker script.
I can't exactly explain why it didn't work before, as these sections should have been included in .bss and thus properly aligned, but it appears to work reliably.
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/
dumb -> leaking:
make it more clear what this "GC" does: leak everything.
marksweep -> conservative:
"marksweep" is too generic, use "conservative" to differentiate
between future garbage collectors: precise marksweep / mark-compact /
refcounting.
This is very useful for debugging. It differentiates between a stack
overflow and other errors (because it's easy to see when a stack
overflow occurs) and prints the old stack pointer and program counter if
available.
This commit avoids setting the working directory to the TinyGo root when
invocating Clang. This helps to weed out issues before we add support
for bundling Clang in a release.
LLD version 8 has added support for armv6m:
https://reviews.llvm.org/D55555
This means we can use LLD instead of arm-none-eabi-ld, eliminating our
dependency on GNU binutils.
There are small differences in code size, but never more than a few
bytes.
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
So far, we've pretended to be js/wasm in baremetal targets to make the
stdlib happy. Unfortunately, this has various problems because
syscall/js (a dependency of many stdlib packages) thinks it can do JS
calls, and emulating them gets quite hard with all changes to the
syscall/js packages in Go 1.12.
This commit does a few things:
* It lets baremetal targets pretend to be linux/arm instead of
js/wasm.
* It lets the loader only select particular packages from the src
overlay, instead of inserting them just before GOROOT. This makes it
possible to pick which packages to overlay for a given target.
* It adds a baremetal-only syscall package that stubs out almost all
syscalls.
The wasm_exec.js file copied from the main Go repository did write those
values to address 4096 in linear memory, which led to memory corruption
in linear memory. Remove these things for now, until they're actually
supported, if support is ever added.
Unfortunately, the olin/cwa emulator does not handle floats correctly.
Node.js does, and because it is also supported by the Go WebAssembly
implementation it has better support in general.
When building statically against LLVM, LLD is also included now. When
included, the built in wasm-ld will automatically be used instead of the
external command.
There is also support for linking ELF files but because lld does not
fully support armv6m this is not yet enabled (it produces a warning).
Before this commit, goroutine support was spread through the compiler.
This commit changes this support, so that the compiler itself only
generates simple intrinsics and leaves the real support to a compiler
pass that runs as one of the TinyGo-specific optimization passes.
The biggest change, that was done together with the rewrite, was support
for goroutines in WebAssembly for JavaScript. The challenge in
JavaScript is that in general no blocking operations are allowed, which
means that programs that call time.Sleep() but do not start goroutines
also have to be scheduled by the scheduler.
This commit does two things:
* It adds support for the GOOS and GOARCH environment variables. They
fall back to runtime.GO* only when not available.
* It adds support for 3 new architectures: 386, arm, and arm64. For
now, this is Linux-only.
* all: add support for specifying target CPU in target config
* avr: specify the chip name in the target CPU
This reduces code size by a large margin. For examples/blinky, it
reduces code size from 1360 to 1266 when compiling for the Arduino Uno
(94 bytes, or ~7%).
