When the underlying value of an interface does not fit in a pointer, a
pointer to the value was correctly inserted in the heap. However, the
receiving method still assumed it got the underlying value instead of a
pointer to it leading to a crash.
This commit inserts wrapper functions for method calls on interfaces.
The bug wasn't obvious as on a 64-bit system, the underlying value was
almost always put directly in the interface. However, it led to a crash
on the AVR platform where pointer are (usually) just 16 bits making it
far more likely that underlying values cannot be directly stored in an
interface.
Make sure package initializers show up in backtraces, as they should. In
practice, it doesn't actually break backtraces as these functions are
usually inlined anyway, but it may help to debug an error in
initialization code.
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.
xml.etree.ElementTree is much easier to work with. This also fixes a few
small bugs in the parser. And as an added bonus, device generation got a
lot faster: apprently etree is a lot faster than minidom.
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.
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).
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?
Ayke van Laethem
Ron Evans