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.
* 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.
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.
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.
When doing a slice operation on a slice, use the capacity value instead
of the length. Of course, for strings and arrays, the slice operation
checks the length because there is no capacity. But according to the
spec, this check should be based on cap for slice instead of len:
> For slices, the upper index bound is the slice capacity cap(a) rather
> than the length.
https://golang.org/ref/spec#Slice_expressions
Fixes: https://github.com/aykevl/tinygo/issues/65
It is stubbed out currently, but may be useful in the future.
Note that this function is implemented for a future change to the init
system, it is not yet useful.
It is allowed to index with an int64 even on a 32-bit platform, so we
have to handle that case. But make sure the normal case isn't penalized
by using 32-bit numbers when possible.
Bigger hashmaps (size > 8) use multiple buckets in a chain. The lookup
code looked at multiple buckets for a lookup, but kept checking the
first bucket for key equality.
Let each target handle its own initialization/finalization sequence
instead of providing one in the runtime with hooks for memory
initialization etc. This is much more flexible although it causes a
little bit of code duplication.
A few changes to make sure compiler-rt is correctly compiled (and
doesn't include host headers, for example).
This improves support for AVR, but it still doesn't work. Compiler-rt
itself doesn't really work for AVR either.
This code:
foo & 0xffffff
Is equivalent to this code:
foo % 0x1000000
However, to drop the high 8 bits, this calculation was used:
foo % 0xffffff
This is far more expensive (and incorrect), as it needs an actual modulo
operation which increases code size and probably reduces speed on a
Cortex-M4 and needs library functions for a Cortex-M0 increasing code
size by a much bigger amount.
This is one step towards removing unnecessary special casts in most
cases. It is also part of removing as much magic as possible from the
compiler (the pragma is explicit, the special name is not).
