Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Multicore support #2446

Open
aykevl opened this issue Dec 30, 2021 · 9 comments
Open

Multicore support #2446

aykevl opened this issue Dec 30, 2021 · 9 comments
Labels
enhancement New feature or request

Comments

@aykevl
Copy link
Member

aykevl commented Dec 30, 2021

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:

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
Copy link

Nerzal commented Dec 30, 2021

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

@deadprogram deadprogram added the enhancement New feature or request label Dec 30, 2021
@eyz
Copy link
Contributor

eyz commented Dec 30, 2021

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
Copy link
Member Author

aykevl commented Dec 30, 2021

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
Copy link

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
Copy link

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
Copy link
Member Author

aykevl commented Apr 27, 2023

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
Copy link

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
Copy link

improvisor40 commented May 28, 2023

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

@aykevl
Copy link
Member Author

aykevl commented May 31, 2023

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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

7 participants