runtime: implement __sync libcalls as critical sections

[niaow]

This change implements __sync atomic polyfill libcalls by disabling interrupts.
This was previously done in a limited capacity on some targets, but this change uses a go:generate to emit all of the calls on all microcontroller targets.

[niaow]

At this point it seems to pass all tests. However, this should probably be extended so that everything that can be tested.
Right now:

1. The min/max atomics are not tested (and unfortunately not documented properly anywhere I thought of looking)
2. Various bitwise atomics are not tested

[aykevl]

Thanks!

At this point it seems to pass all tests. However, this should probably be extended so that everything that can be tested. Right now:

1. The min/max atomics are not tested (and unfortunately not documented properly anywhere I thought of looking)

2. Various bitwise atomics are not tested

I think it's best to leave those out. If we don't use them, there isn't really a reason to write atomic functions for them. It looks like we only use add, cas, load, store, and swap, and only for 2, 4, and 8 bytes in size.

[niaow]

I think it's best to leave those out. If we don't use them, there isn't really a reason to write atomic functions for them. It looks like we only use add, cas, load, store, and swap, and only for 2, 4, and 8 bytes in size.

I was less worried about us directly using them, and more worried about cgo'ed code or an LLVM optimization generating them. However, searching through the llvm-project code, I can't find a way for that to happen. I think I will just comment it out for now in case this turns up later.

[niaow]

Hmm. Actually, it looks like it may be necessary to leave the bitwise atomics in for cgo.

[niaow]

Hmm. This is not close to ready - this seems to be quite a bit more complicated.

[niaow]

I think it's best to leave those out. If we don't use them, there isn't really a reason to write atomic functions for them.

So I looked into this and concluded that while we don't, cgo'ed code can potentially. I am adding some tests through CGo for the ones which can be easily hit.

[niaow]

Or specifically the bitwise atomics. The min/max atomics are not currently accessible so I am leaving them out for now.

[niaow]

Hmm. It looks like we might need to flush stdout, and also like something is ignoring the -std=c11.

[aykevl]

Clang defaults to -std=gnu17, so I don't think this is needed. Source: https://clang.llvm.org/docs/UsersManual.html#differences-between-various-standard-modes

[aykevl]

So I looked into this and concluded that while we don't, cgo'ed code can potentially. I am adding some tests through CGo for the ones which can be easily hit.

Yes, that's possible. I can't see why LLVM would generate different atomic instructions but it's definitely possible for C code to do so. Still, that's IMHO not needed yet - but I'm also not against adding support for it in advance (I just don't see the need).

[niaow]

I can't see why LLVM would generate different atomic instructions

These atomic libcalls all correspond to parts of the stdatomic.h standard library in C11 (except for nand which I think I left in by accident).

Still, that's IMHO not needed yet

Alright, I will split C atomics support out into another PR at a later time.

[niaow]

The old version has been preserved at https://github.com/niaow/tinygo/tree/critical-atomics-old

[niaow]

Note that some atomics still do not work on AVR (but this seems out of scope):

[niaow@finch tinygo]$ build/tinygo build -size short -o test.hex -target=arduino ./testdata/atomic.go
LLVM ERROR: Cannot generate unaligned atomic store

[aykevl]

Looks good, thanks!