This can be used in the future to trigger garbage collection. For now,
it provides a more useful error message in case the heap is completely
filled up.
Make sure every to-be-implemented GC can use the same interface. As a
result, a 1MB chunk of RAM is allocated on Unix systems on init instead
of allocating on demand.
Move attaching debug info to where the function is defined. As LLVM does
not allow setting debug info on declarations, this makes more sense and
is less error-prone.
This commit fixes debug info when using CGo.
* Use 64-bit integers on 64-bit platforms, just like gc and gccgo:
https://golang.org/doc/go1.1#int
* Do not use a separate length type. Instead, use uintptr everywhere a
length is expected.
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.
* Loading from a dirty global must be done at runtime (!). For some
reason this wasn't already the case.
* Global variables somehow had IsConstant() the wrong way round,
returning the inverse from what they should.
* Do binary and logical operations at runtime if necessary, relying on
const propagation in the IR builder.
* Don't try to interpret functions that take a dirty parameter. Call
them at runtime.
Cast operations will still be evaluated at compile time in all cases
they did before because of the built-in constant propagation of the
IRBuilder, but when one of the parameters is not a constant it will
transparently be evaluated at runtime.
This avoids some errors in the partial evaluator. It is not yet complete
as all binops will need a similar treatment.
This makes it easier to get an overview of everything interface related,
because interfaces are quite complicated and were scattered through the
(huge!) compiler.go file.
Let the standard library think that it is compiling for js/wasm.
The most correct way of supporting bare metal Cortex-M targets would be
using the 'arm' build tag and specifying no OS or an 'undefined' OS
(perhaps GOOS=noos?). However, there is no build tag for specifying no
OS at all, the closest possible is GOOS=js which makes very few
assumptions.
Sadly GOOS=js also makes some assumptions: it assumes to be running with
GOARCH=wasm. This would not be such a problem, just add js, wasm and arm
as build tags. However, having two GOARCH build tags leads to an error
in internal/cpu: it defines variables for both architectures which then
conflict.
To work around these problems, the 'arm' target has been renamed to
'tinygo.arm', which should work around these problems. In the future, a
GOOS=noos (or similar) should be added which can work with any
architecture and doesn't implement OS-specific stuff.
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.
There is a problem with this version, but fixing it requires some
changes to ir/interpreter.go which will be replaced soon anyway.
Remove master from the tests. It probably wasn't such a great idea
anyway during the development cycle of Go.
I don't know why they sometimes have them, but apparently some packages
do. Don't panic in that case, the interpreter will stop anyway on the
first branch.
In Go, function pointers are not comparable. This means that the address
itself is not significant and functions can therefore be merged.
Add the unnamed_addr attribute to all functions to learn LLVM about this
fact. At the moment the mergefunc pass hasn't been enabled, but it
should be in the future to reduce code size.
Package encoding/binary uses reflect and is needed by image/png, but
image/png doesn't actually need the reflect-using parts of
encoding/binary. So stub them out for now to get it to compile.
Thanks to Stephen Solka who wrote the patch.
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).
