This directive caused the code to be put in a non-executable area on
Windows which caused a segmentation fault. This patch fixes the issue by
removing `.section` directives, fixing windows/arm64 support.
I'm surprised this worked as long as it did, since it looks like the
goroutine stack did not get scanned. Or maybe the RCX register contained
the stack pointer by accident. In any case, it now uses the correct
register (RCX instead of RDI on Windows) for passing the stack pointer
as the first parameter.
This adds support for the well-known Boehm GC. It's significantly faster
than our own naive GC and could be used as an alternative on bigger
systems.
In the future, this GC might also be supported on WebAssembly with some
extra work. Right now it's Linux only (though Windows/MacOS shouldn't be
too difficult to add).
For example, with -gc=none and -gc=leaking, no heap needs to be
allocated when initializing the runtime. And some GCs (like -gc=custom)
are responsible for allocating the heap themselves.
* machine/rp2350: add flash support for rp2350
* combine duplicate files
* clean things up and group by source file
* add stubbed out xip cache clean func if needed in the future
* update flash_enable_xip_via_boot2
* remove unused macros and fix inconsistent formatting
* make flash size configurable like rp2040
* add missing flash size configs
* retain big Go CGo compatibility per #4103
* clarify CS0_SIZE source and remove single-use typedef
Don't block forever if there's nothing to receive. On the other hand,
process the entire FIFO, not just a single byte.
This fixes an issue where the rp2350 would hang after programming through
openocd, where the UART0 interrupt would be spuriously pending.
Right now it doesn't compile, with errors like the following:
# machine
/app/tinygo/src/machine/board_pico.go:7:13: undefined: GPIO0
/app/tinygo/src/machine/board_pico.go:8:13: undefined: GPIO1
/app/tinygo/src/machine/board_pico.go:9:13: undefined: GPIO2
/app/tinygo/src/machine/board_pico.go:10:13: undefined: GPIO3
[...etc...]
This patch should fix that.
* machine: add support for core voltage adjustments to rp2040
In preparation for bumping the core frequency of the rp2040, this
change implements the required core voltage adjustment logic.
* machine: bump rp2040 to 200MHz
Follow-up to #4728 which implemented the algorithm for finding the
dividers.
The calculation is computed at compile time by interp, as verified by
building example/blinky1 for -target pico.
The upstream one assumes it's running on a Unix system (which makes
sense), but this package is also used on baremetal. So replace it on
systems that need a replaced syscall package.
We can't use the bytes package in Go 1.24 since it would result in an
import cycle. Therefore, use bytealg.Index instead.
(I'm not sure this code is correct - just searching for a range of bytes
seems brittle. But at least this commit shouldn't change the code).