There is no reason to specialize this per chip as it is only ever used
for JavaScript. Not only that, it is causing confusion and is yet
another quirk to learn when porting the runtime to a new
microcontroller.
This commit improves the timers on various microcontrollers to better
deal with counter wraparound. The result is a reduction in RAM size of
around 12 bytes and a small effect (sometimes positive, sometimes
negative) on flash consumption. But perhaps more importantly: getting
the current time is now interrupt-safe (it previously could result in a
race condition) and the timer will now be correct when the timer isn't
retrieved for a long duration. Before this commit, a call to `time.Now`
more than 8 minutes after the previous call could result in an incorrect
time.
For more details, see:
https://www.eevblog.com/forum/microcontrollers/correct-timing-by-timer-overflow-count/msg749617/#msg749617
On some boards the FPU is already enabled on startup, probably as part
of the bootloader. On other chips it was enabled as part of the runtime
startup code. In all these cases, enabling the FPU is currently
unsupported: the automatic stack sizing of goroutines assumes that the
processor won't need to reserve space for FPU registers. Enabling the
FPU therefore can lead to a stack overflow.
This commit either removes the code that enables the FPU, or simply
disables it in startup code. A future change should fully enable the FPU
so that operations on float32 can be performed by the FPU instead of in
software, greatly speeding up such code.
This commit refactors both determining the current time and sleeping for
a given time. It also improves precision for many chips.
* The nrf chips had a long-standing TODO comment about a slightly
inaccurate clock. This should now be fixed.
* The SAM D2x/D5x chips may have a slightly more accurate clock,
although probably within the error margin of the RTC. Also, by
working with RTC ticks and converting in the least number of places,
code size is often slightly reduced (usually just a few bytes, up to
around 1kB in some cases).
* I believe the HiFive1 rev B timer was slightly wrong (32768Hz vs
30517.6Hz). Because the datasheet says the clock runs at 32768Hz,
I've used the same conversion code here as in the nrf and sam cases.
* I couldn't test both stm32 timers, so I kept them as they currently
are. It may be possible to make them more efficient by using the
native tick frequency instead of using microseconds everywhere.
This is the kind that is used in Go (actually CGo) for exporting
functions. I think it's best to use //export instead of our custom
//go:export pragma, for consistency (they are equivalent in TinyGo).
Therefore I've updated all instances to the standard format (except for
two that are updated in https://github.com/tinygo-org/tinygo/pull/1024).
No smoke tests changed (when comparing the output hash), except for some
wasm tests that include DWARF debug info and tend to be flaky anyway.
This commit lets the compiler know about interrupts and allows
optimizations to be performed based on that: interrupts are eliminated
when they appear to be unused in a program. This is done with a new
pseudo-call (runtime/interrupt.New) that is treated specially by the
compiler.
Before this commit, goroutine support was spread through the compiler.
This commit changes this support, so that the compiler itself only
generates simple intrinsics and leaves the real support to a compiler
pass that runs as one of the TinyGo-specific optimization passes.
The biggest change, that was done together with the rewrite, was support
for goroutines in WebAssembly for JavaScript. The challenge in
JavaScript is that in general no blocking operations are allowed, which
means that programs that call time.Sleep() but do not start goroutines
also have to be scheduled by the scheduler.
The default priority is 0 (highest) which is reserved by the SoftDevice.
For normal operation the exact priority level doesn't matter, only the
relative priority matters. So this change makes the code compatible with
the SoftDevice without actually changing the behavior.
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.
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).
This increases code size by 1 instruction (2 bytes) because LLVM isn't
yet smart enough to recognize that it doesn't need to clear a register
to use 0: it can just use r1 which is always 0 according to the
convention. It makes initialization a lot easier to read, however.
time.Sleep now compiles on all systems, so lets use that.
Additionally, do a few improvements in time unit handling for the
scheduler. This should lead to somewhat longer sleep durations without
wrapping (on some platforms).
Some examples got smaller, some got bigger. In particular, code using
the scheduler got bigger and the blinky1 example got smaller (especially
on Arduino: 380 -> 314 bytes).
This is the last critical part of the C runtime.
Code size is reduced by 4 bytes for examples/blinky2 (probably due to
inlining) and is unchanged for examples/test.
This has the benefit of not requiring a 'runtime' IR file, so that
complete relocatable files can be built without requiring input IR.
This makes the compiler a lot easier to use without the Makefile.
Code size is not affected.
CGo depends on syscall, which (in the standard library) depends on sync,
which depends on the runtime. There are also other import cycles. To be
able to use the syscall package from upstream, stop using CGo.
Ayke van Laethem
Jaden Weiss
Ron Evans