-
Notifications
You must be signed in to change notification settings - Fork 855
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
Comments
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. |
Yes, feel free to send a PR :)
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. |
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. |
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! |
There hasn't been any development on this feature.
It is not, because only very few microcontrollers have multiple cores (the rp2040 and esp32 are the only two I know of). |
Thank you for the feedback @aykevl. |
is this still a goal? or is it gone?. |
Yes, eventually, but other things have been of higher priority so far. |
We need to support multi core systems some day:
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
(orsinglecore
,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.The text was updated successfully, but these errors were encountered: