Bump version to 1.1.2 in order to support darwin/arm64 within tinygo.
See bugst/go-serial#96 for more information.
Signed-off-by: Tobias Kohlbau <tobias@kohlbau.de>
This avoids external commands from finishing after the TinyGo command
exits. For example, when testing out compiler-rt on AVR, I got the
following error:
$ go install; and tinygo run -target=atmega1284p ./testdata/calls.go
[... Clang error removed ...]
error: failed to build /home/ayke/src/github.com/tinygo-org/tinygo/lib/compiler-rt/lib/builtins/extendsfdf2.c: exit status 1
error: unable to open output file '/tmp/tinygo361380649/build-lib-compiler-rt/ffsdi2.c.o': 'No such file or directory'
1 error generated.
That last error ("unable to open output file") is a spurious error
because the temporary directory has already been removed. This commit
waits until all running jobs have finished before returning, so that
these errors won't happen.
With this change, it is possible to fully use CGo on ESP32/ESP8266
chips. The following will work:
tinygo flash -target=d1mini -port=/dev/ttyUSB0 ./testdata/cgo/
tinygo flash -target=esp32-mini32 -port=/dev/ttyUSB0 ./testdata/cgo/
Previously it would produce output like the following:
/tmp/tinygo905539688/main.o:(.literal.runtime.run$1$gowrapper+0x150): undefined reference to `strcpy'
/tmp/tinygo905539688/main.o:(.literal.runtime.run$1$gowrapper+0x154): undefined reference to `strlen'
With this change, it is possible to compile ./testdata/float.go for the
ESP8266 and run it successfully. Previously it would result in many
linker error like this:
/tmp/tinygo494494333/main.o:(.literal.runtime.printfloat64+0x0): undefined reference to `__unorddf2'
/tmp/tinygo494494333/main.o:(.literal.runtime.printfloat64+0x4): undefined reference to `__gtdf2'
/tmp/tinygo494494333/main.o:(.literal.runtime.printfloat64+0xc): undefined reference to `__nedf2'
/tmp/tinygo494494333/main.o:(.literal.runtime.printfloat64+0x10): undefined reference to `__ltdf2'
/tmp/tinygo494494333/main.o:(.literal.runtime.printfloat64+0x1c): undefined reference to `__gedf2'
I have verified that the output on the serial console matches
./testdata/float.txt when run on the ESP8266.
This flag is important for the Xtensa backend because by default a more
powerful backend (ESP32) is assumed. Therefore, compiling for the
ESP8266 won't work by default and needs the -mcpu flag.
This key was intended as some sort of cache key (as the name indicates)
but that never happened. Let's remove it to avoid clutter. The cacheLoad
and cacheStore functions are only used for C libraries (libc,
compiler-rt) so their caching behavior is a bit different from other
things worth caching.
This doesn't yet add support for actually making use of variadic
functions, but at least allows (unintended) variadic functions like the
following to work:
void foo();
Move element description formatting to a function
Export struct fields for use in the template
Add template helper functions
Multiline comments for interrupts and peripherals
Export more fields
Move comments to the top of each element
Do not remove line breaks from descriptions
The template code should gracefully handle line breaks now
go fmt gen-device-svd.go
Because of a bug in the ARM backend of LLVM, the cmpxchg instruction is
lowered using ldrexd/strexd instructions which don't exist on Cortex-M
cores. This leads to an "undefined instruction" exception at runtime.
Therefore, this patch works around this by lowering directly to a call
to the __sync_val_compare_and_swap_8 function, which is what the backend
should be doing.
For details, see: https://reviews.llvm.org/D95891
To test this patch, you can run the code on a Cortex-M3 or higher
microcontroller, for example:
tinygo flash -target=pca10040 ./testdata/atomic.go
Before this patch, this would trigger an error. With this patch, the
behavior is correct. The error (without this patch) could look like
this:
fatal error: undefined instruction with sp=0x200007cc pc=nil
Moving settings to a separate config struct has two benefits:
- It decouples the compiler a bit from other packages, most
importantly the compileopts package. Decoupling is generally a good
thing.
- Perhaps more importantly, it precisely specifies which settings are
used while compiling and affect the resulting LLVM module. This will
be necessary for caching the LLVM module.
While it would have been possible to cache without this refactor, it
would have been very easy to miss a setting and thus let the
compiler work with invalid/stale data.
This fixes a longstanding TODO comment and similar to
https://github.com/tinygo-org/tinygo/pull/1593 it removes some code out
of the compiler.CompileProgram function that doesn't need to be there.
This is a small refactor to move code away from compiler.CompilePackage,
with the goal that compiler.CompilePackage will eventually be removed
entirely in favor of compiler.CompilePackage.
Since https://github.com/tinygo-org/tinygo/pull/1571 (in particular, the first
commit that sets the main package path), the main package is always named
"main". This makes the callMain() workaround in the runtime unnecessary and
allows directly calling the main.main function with a //go:linkname pragma.
This package was long making the design of the compiler more complicated
than it needs to be. Previously this package implemented several
optimization passes, but those passes have since moved to work directly
with LLVM IR instead of Go SSA. The only remaining pass is the SimpleDCE
pass.
This commit removes the *ir.Function type that permeated the whole
compiler and instead switches to use *ssa.Function directly. The
SimpleDCE pass is kept but is far less tightly coupled to the rest of
the compiler so that it can easily be removed once the switch to
building and caching packages individually happens.
This change extends defer support to all supported builitin functions.
Not all of them make sense (such as len, cap, real, imag, etc) but this
change for example adds support for `defer(delete(m, key))` which is
used in the Go 1.15 encoding/json package.
This commit parallelizes almost everything that can currently be
parallelized. With that, it also introduces a framework for easily
parallelizing other parts of the compiler.
Code for baremetal targets already compiles slightly faster because it
can parallelize the compilation of supporting assembly files. However,
the speedup is especially noticeable when libraries (compiler-rt,
picolibc) also need to be compiled: they will be compiled in parallel
next to the Go files using all available cores. On my dual core laptop
(4 cores if you count hyperthreading) this cuts compilation time roughly
in half when compiling something for a Cortex-M board after running
`tinygo clean`.
