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
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.
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.
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
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.
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.
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
It's kind of a weird setup but I pulled the stdlib/gyb code into the repository itself and got everything building with make. Even though I don't use Swift's build system the Package.swift build was very helpful as a reference on how to actually bypass the CMake, which is split across so many places I wouldn't even know how to try and understand what it does.
With that I can now easily patch and cross compile things without dealing with Swift's build systems; I am kind of halfway in porting Unicode support out of C++ as a test (I mostly ported the runtime but I need to also change the table generator to emit inline-arrays instead of C)
If that works out I imagine I will try porting the concurrency runtime as well.
Are the unicode table generation scripts used for anything?
I see that the generated files are committed to the Swift repository, and trying to compile the code for GenEmoji actually fails here
for chunk in chunks { // line 127
var chunkBA = BitArray(size: chunkSize)
let lower = chunk * chunkSize
let upper = lower + chunkSize
let chunkDataIdx = UInt64(dataIndices.endIndex) // dataIndices is not actually defined anywhere
I'm not entirely sure how the tables in the repository were generated if the script doesn't work, but it does seem to be the case as far as I can tell
If I wanted to work with the Embedded Swift runtime how/where would I do that?
For example, Job is a C++ class and inherits from HeapObject, I don't believe that kind of thing is representable in Swift; I'd need a way to implement types for the raw objects directly in Swift if I want to actually implement the concurrency runtime with Swift/intrinsics/assembly instead of C++.
Would it be enough to recreate the layouts with rawLayout or is there something that would break if I do that?
I'm trying to add a default executor for main and I think this might need a less abstract error message because I can't figure out what it wants me to do
Yes, that's one more reason why you need to have a libc for your Embedded Swift platform that you build libc++ on top of to make these runtime types available.
I don't think that reimplementing everything from scratch in Swift is currently viable within constraints of a hobby project. There's enough written in C and C++ that if you were ever interested in migrating that to Swift, you should consider an incremental approach instead.
It would work best if such incremental rewrite is contributed upstream so that it's aligned with upstream changes in the first place, as this area of the runtime is being actively developed and changes quite frequently. Otherwise, updating a runtime in a downstream fork for each new version of Swift can become untenable.
The problem here is that main.swift file name is special for Swift and is not compatible with @main. You either call a file main.swift and consider that an entrypoint with top-level code, or use @main, and then call it anything other than main.swift (I personally prefer Entrypoint.swift) to avoid the conflict.
I could do it that way, but I can't deal with the CMake, so I would at least have to wait for the package build to try.
I don't think what I'm doing is contradictory with that; I have to read all the code to understand it anyway, it's far less tedious to actually write it along the way, even if it doesn't turn out particularly useful. The knowledge is very valuable on further attempts (or working with the original code) because in the process I get to learn how it works.
I think it's still valuable to quickly make something generally unmaintainable and terribly hacked together if it means I can actually fully remember and understand every line of code and use that as reference to do things properly.
I don't think that's it, I am using make directly with swiftc and -parse-as-library and the issue is caused by adding async to the static main function signature. I'm kind of confused because I think it worked before too. Just to make sure though I did try a clean build with a different name
I suppose it could be something breaking due to the experimental flags, extracting _Concurrency and building it with make or a number of other things, not sure how to debug this
