Sometimes, tests suddenly hang somewhere (in particular in emulators
where crashes often lead to hangs). Setting a limit has two advantages:
1. Quickly killing test processes that are frozen (as opposed to
waiting for the default 10min go test timeout).
2. The output becomes visible, hopefully giving a clue what went
wrong.
QEMU doesn't support the RTC peripheral yet so work around it for now.
This makes the following command work:
tinygo run -target=hifive1-qemu ./testdata/coroutines.go
We have long since moved towards a different location for these headers
in the git checkout, so update where getClangHeaderPath looks for these
headers.
Also add an extra check to make sure a path has been detected.
Some mapassign operations cannot (yet) be done by the interp package.
Implement a fallback mechanism so that these operations can still be
performed at runtime.
Eventually, open files should be closed when the GC runs and the
finalizer is called. However we shouldn't rely on that.
Using `ioutil.ReadFile` as it's a simpler pattern anyway.
These globals are (and must be!) never modified by the reflect package.
By marking them as constant, they will be put in read-only memory. This
reduces RAM consumption on microcontrollers.
This simplifies the code. The fields are blank anyway so there is no way
to access them anyway (volatile or not).
Also do some other related simplifications of the code that result from
this change.
These all-caps constants aren't in the Go style, so rename it to
CPUFrequency (which is more aligned with Go style). Additionally, make
it a function so that it is possible to add support for changing the
frequency in the future.
Tested by running `make smoketest`. None of the outputs did change.
This should make it more maintainable. Another big advantage that
generation time (including gofmt) is now 3 times faster. No real attempt
at refactoring has been made, that will need to be done at a later time.
Since LLVM 9, CGo sometimes randomly breaks with weird error messages on
Windows. I'm not sure why this is the case, but it might be related to
concurrency.
Disable concurrency for now, and hope that will make the errors go away.
Now that we use LLVM 9, RISC-V support in LLVM has far fewer bugs and we
can avoid the GNU toolchain.
* replace GNU linker with lld
* replace GCC with clang
Additionally, RISC-V was promoted to stable so it can be enabled by
default in CI.
This brings a big speedup. Not counting gofmt time,
`make gen-device-avr` became about 3x faster. In the future, it might be
an idea to generate the AST in-memory and write it out already
formatted.
The .sdata and .sbss sections are created by the compiler, but were not
present in the linker script. That means that the linker put them after
all other data/bss section, which happens to be where the heap also
resides.
This commit adds the .sdata and .sbss sections to the linker script,
which gets the blinky examples to work again on RISC-V.
This commit makes a number of changes:
* It avoids a dependency on Compiler.emitStartGoroutine.
* It moves the func-lowering pass to the transform package.
* It adds testing to func lowering.
No functionality should have changed with this commit.
This commit replaces most panics in interp/frame.go and interp/scan.go
with real error messages. The remaining ones are panics that should not
happen when working with valid IR.
This kind of code might be generated by the switch implementation of
func values. The func value is represented as a ptrtoint, and before
calling it, it is compared against 0.
This commit improves error reporting in several ways:
* Location information is read from the intruction that causes the
error, as far as that's available.
* The package that is being interpreted is included in the error
message. This may be the most useful part of the improvements.
* The hashmap update intrinsics now doesn't panic, instead it logs a
clear error (with location information, as in the above two bullet
points).
This is possible thanks to improvements in LLVM 9. This means that after
this change, TinyGo will depend on LLVM 9.
