Compiling embedded Concurrency for armv6

Hi!

I managed to get Embedded Swift running on my 3DS (armv6-none-none-eabi) and the target is even provided by toolchains out of the box, but when I try to import _Concurrency it seems that it is not provided for this particular target. I was able to implement a thread wrapper in terms of syscalls there but I'd like to now add a more idiomatic actor and async/await executor on top, as there's a lot of APIs like obtaining software keyboard input which would benefit from background tasks and async.

I always get really lost with all the build scripts, but maybe this time things can work out, could someone explain the easiest path to getting the _Concurrency swiftmodule for armv6? I tried doing it manually without cmake but that did not end well :D


Edit:

In case anyone is ever interested in doing something like this I am putting the code here GitHub - TeamPuzel/Citrus: Swift framework for 3DS homebrew development. · GitHub

This kind of thing isn't well documented and required a lot of trial and error to get working so hopefully it is a useful reference.

5 Likes

It looks like some ABI-affecting flags also prevent the unicode tables from linking properly so strings don't actually work. I would have to build those with my flags as well. It would be nice if Embedded Swift could have the option to build these (and the standard library) automatically as part of the user build, which I believe is something Rust can do when no pre-built libraries exist for a target.

Or if the process to build those was at least somewhat less esoteric.

[Experiment] Optionally use a package for the Swift standard library by DougGregor · Pull Request #9868 · swiftlang/swift-package-manager · GitHub :slight_smile:

2 Likes

Yay :slight_smile:

That's really nice to see after spending the entire day trying to get the unicode tables to build (with absolutely zero success of course)

I've been attempting to use Swift on various weird platforms for many years now and every time I check back it's way more usable. I'm not sure how this would work but if it does solve my issue that's pretty cool, I can't wait to have the ability to try it.

1 Like

I had to add a missing file to the unicode package file list and but now it works, I can build the libraries and use unicode glyphs in my tile-fonts which is really cool to have. It was surprisingly painless :smiley:

If I understand correctly concurrency is not possible yet? Is there maybe a way I can work around that limitation?

It actually is possible, but even more annoying to properly build with all the build-script goop. cc @Max_Desiatov to share how he was able to do it for WASM.

Speaking for @Douglas_Gregor and @dschaefer2: we want to make it easy to build all of the standard libraries on-demand from source for the desired target embedded platform via SwiftPM including _Concurrency.

The next step for that library is enabling mixed source targets in SwiftPM which should be possible (very soon) now that the swiftbuild backend is available.

3 Likes

You'll need a libc for your embedded platform that you can build libc++ on top of, as Embedded Swift Concurrency depends on <chrono>.

I recently did this with newlib for armv7em. I provided the Swift patches in the project, which may be helpful to you.

Note: I used the regular Swift build to build a standard library. Not the experimental method mentioned above.

1 Like

That's an unfortunate dependency :pensive_face:

I do believe a gnu C++ standard library is provided by the 3DS toolchain so it might work, though I'm not happy I have to link with it in the first place.

Thank you, having a working reference should be very helpful, I'll try and implement it

It's nice that the compiler doesn't crash when defining Swift runtime symbols in Swift anymore, but it seems that it has instead been hardcoded to warn about declaring swift_* symbols outside of hardcoded module names? It does not seem to be enough to use -parse-stdlib, I have to declare my code as part of _Concurrency which is also annoying as then I can't import it

I was able to manually build _Concurrency itself but not the C++ part, and I think I'd rather port the C++ runtime code to Swift after spending way too much time on it. It seems way less painful than getting the C++ code to work.

Well, I guess I'll not use the package and instead build the standard modules in my makefile, then I think I can get it to work

Is there still anything stopping me from porting all the required C++ code to Swift? :D