Multicore support

[aykevl]

We need to support multi core systems some day:

• Some microcontrollers have more than one core that we'd like to use (RP2040, ESP32)
• Most operating systems have multiple cores.

At the same time, support for multi core shouldn't (significantly) regress single-core performance on microcontrollers, because almost all microcontrollers are single core.

To support multi core, there need to be changes to:

• the scheduler, to schedule over more than one core
• channels (implemented in the runtime)
• the garbage collector (it needs to stop all goroutines to scan their stacks)
• wrappers for atomic instructions (see runtime: implement __sync libcalls as critical sections #2307)
• packages like sync
• ... probably more

I propose we add a new unicore (or singlecore, singlethread, ...) build tag for single core chips and schedulers, so that we can know at build time whether a configuration can assume it's only running in a single (hardware) thread and optimize accordingly.

I suspect it's easiest to not add multi core support first to a chip (RP2040, ESP32) but to an operating system. Operating system threads are already well defined and require the vast majority of changes that are also required for multi core support on a chip (see the list above). I propose we add a -scheduler=threads for that, where each goroutine is running in a separate OS thread. This is much simpler to implement than Go runtime style green threads because it doesn't require special handling of blocking system calls.

[Nerzal]

Guess we can update the Non-Goals of the readme.md now

[eyz]

Perhaps target a FreeRTOS or similar to start?

EDIT: I now see you mentioned you would rather start with an OS, and did not actually imply that it would be on a RTOS.

[aykevl]

Guess we can update the Non-Goals of the readme.md now

Yes, feel free to send a PR :)

Perhaps target a FreeRTOS or similar to start?

No, that would be far more difficult. We already have a RTOS-like scheduler, adding FreeRTOS or similar would make things quite complicated. And add an external dependency that I'd really like to avoid.

[migueleliasweb]

Hi all, any updates on this?

Although I haven't worked much with embedded systems I would like to lend a hand to add support for this.

[couillonnade]

I am curious if any progress has been made for supporting multiple cores? Did not find any hack or PR about it. Should we consider this is not a primary goal for TinyGo? Thank you!

[aykevl]

There hasn't been any development on this feature.

Should we consider this is not a primary goal for TinyGo?

It is not, because only very few microcontrollers have multiple cores (the rp2040 and esp32 are the only two I know of).

[couillonnade]

Thank you for the feedback @aykevl.
I'm mainly targeting RP2040 that has more power than many other MCU for a fraction of the price.

[improvisor40]

is this still a goal? or is it gone?.
just as said this will really benefit the rp2040's architecture.

[aykevl]

is this still a goal? or is it gone?.

Yes, eventually, but other things have been of higher priority so far.

[kingsquirrel152]

Was wondering if there was a middle ground here? What would it look like if there was support like what Arduino's stack does? Letting us fire up the other core as an independent entity.

[aykevl]

I've actually been investigating this. Spent a few days trying to get channels to work but it's quite difficult. I've paused it for now because Go 1.23 support (and the coming release) is more important right now.

The first step for parallelism will be to add a new "scheduler" that just puts every goroutine on a separate OS thread in Linux. Why not on a MCU? Because 90% or so of the work is shared between Linux and MCU multicore support, and it's much easier to debug stuff on Linux.