Instead of trying to modify periperhals directly, external functions are
called. For example, __tinygo_gpio_set sets a GPIO pin to a specified
value (high or low). It is expected that binaries made this way will be
linked with some extra libraries that implement support for these
functions.
One particularly interesting case is this experimental board simulator:
https://github.com/aykevl/tinygo-play
Compiling code to WebAssembly with the correct build tag for a board
will enable this board to be simulated in the browser.
Atmel/Microchip based SAMD boards are not currently supported, because
their I2C/SPI support is somewhat uncommon and harder to support in the
machine API. They may require a modification to the machine API for
proper support.
The -DLLVM_TOOL_CLANG_TOOLS_EXTRA_BUILD=OFF option turning off the
building of the extra clang tools is required, otherwise linking
the tinygo binary fails.
This is a big commit that does a few things:
* It moves CGo processing into a separate package. It never really
belonged in the loader package, and certainly not now that the
loader package may be refactored into a driver package.
* It adds support for multiple CGo files (files that import package
"C") in a single package. Previously, this led to multiple
definition errors in the Go typecheck phase because certain C
symbols were defined multiple times in all the files. Now it
generates a new fake AST that defines these, to avoid multiple
definition errors.
* It improves debug info in a few edge cases that are probably not
relevant outside of bugs in cgo itself.
These two dependencies are optional but enabled by default when
available. Disable them in the Makefile so that the tinygo binary is
portable to systems that don't have them or have a different version
(for example, Arch has a newer version of libcurses and thus libtinfo).
This replaces the older way which just does the following:
go install .
and
go test -v .
Instead, `make` and `make test` will now build TinyGo statically linked
against LLVM, so that `go install` and `go test -v` should be used
manually.
This provides several advantages. Among others:
* Much faster and hopefully more reliable.
* Good caching support to store LLVM builds.
* Building and testing of release-ready artifacts.
Go 1.12 switched to using libSystem.dylib for system calls, because
Apple recommends against doing direct system calls that Go 1.11 and
earlier did. For more information, see:
https://github.com/golang/go/issues/17490https://developer.apple.com/library/archive/qa/qa1118/_index.html
While the old syscall package was relatively easy to support in TinyGo
(just implement syscall.Syscall*), this got a whole lot harder with Go
1.12 as all syscalls now go through CGo magic to call the underlying
libSystem functions. Therefore, this commit overrides the stdlib syscall
package with a custom package that performs calls with libc (libSystem).
This may be useful not just for darwin but for other platforms as well
that do not place the stable ABI at the syscall boundary like Linux but
at the libc boundary.
Only a very minimal part of the syscall package has been implemented, to
get the tests to pass. More calls can easily be added in the future.
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).
This interpreter currently complements the Go SSA level interpreter. It
may stay complementary or may be the only interpreter in the future.
This interpreter is experimental and not yet finished (there are known
bugs!) so it is disabled by default. It can be enabled by passing the
-initinterp flag.
The goal is to be able to run all initializations at compile time except
for the ones having side effects. This mostly works except perhaps for a
few edge cases.
In the future, this interpeter may be used to actually run regular Go
code, perhaps in a shell.
The size flag has two modes:
-size=short: prints data basically equivalent to the `size` program.
-size=full: tries to determine sizes per package (not entirely
accurate).