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).
Do not try to use the ExectutionEngine of Go, instead compile the
program in the conventional way and run the binary.
This fixes some code duplication that causes slight (but problematic)
misbehavior between `tinygo build` and `tinygo run`.
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%).
This commit changes many things:
* Most interface-related operations are moved into an optimization
pass for more modularity. IR construction creates pseudo-calls which
are lowered in this pass.
* Type codes are assigned in this interface lowering pass, after DCE.
* Type codes are sorted by usage: types more often used in type
asserts are assigned lower numbers to ease jump table construction
during machine code generation.
* Interface assertions are optimized: they are replaced by constant
false, comparison against a constant, or a typeswitch with only
concrete types in the general case.
* Interface calls are replaced with unreachable, direct calls, or a
concrete type switch with direct calls depending on the number of
implementing types. This hopefully makes some interface patterns
zero-cost.
These changes lead to a ~0.5K reduction in code size on Cortex-M for
testdata/interface.go. It appears that a major cause for this is the
replacement of function pointers with direct calls, which are far more
susceptible to optimization. Also, not having a fixed global array of
function pointers greatly helps dead code elimination.
This change also makes future optimizations easier, like optimizations
on interface value comparisons.
To support the WebAssembly<->JS barrier, return values also have to be
passed in memory. i64 return values are used by syscall/js, so must be
supported across this ABI barrier.
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.
JavaScript does not support i64 directly, so make sure we pass a pointer
instead which can be read from JavaScript.
This is a temporary workaround which should be removed once JavaScript
supports some form of i64 (probably in the form of BigInt).
Panics don't usually happen nowadays, instead the compiler package
returns errors while compiling. If it still panics, this is usually from
within LLVM from where deferred functions are not run.
The list of options passed to build/run/gdb/etc commands was getting
unwieldly and hard to add extra options to. Put all common build options
in a single build config struct so that these options are more
centralized.
In most cases, it's useless. But in some cases it may be critical if the
OCD server (like openocd) has a problem.
It would be nice if openocd would differentiate between stdout and
stderr, and only write errors to stderr. But sadly it doesn't.
Be more compatible with the Go toolchain by setting GOPATH in the same
way. This makes it possible to flash and run examples from the standard
GOPATH instead of only from the source tree.
Apparently -Oz without inliner is the fastest, probably because it
removes code that would otherwise need to be emitted.
TODO: does this mean that the ExecutionEngine compiles the module before
running it? Can we control this?