Iâm going to attempt to fiddle with the compiler again this evening with the goal of getting the new triple added and cross-compiling parts of the runtime.
Some potential problems:
- foundation will almost certainly not be supported at first (and never entirely) as it relies on libc we canât use.
- Unicode support is pretty big
- I think parts of stdlib also require clib, so more stubbing might be necessary
- allocators need to use the one provided by the C sdk, that shouldnât be too problematic but it is something to note, as using simulator often masks this problem (once we are linking swift dylibs based on the pd allocator we should see changes to the malloc log we donât see now)
Some of the better news is that once we can compile, linking shouldnât be so bad, and things should pretty much âjust workâ.
Somewhat related but I think it would be way easier to compile swift for something with an RTOS, like freeRTOS or mbed. Then you wouldnât need to deal with all the libc headaches. We canât take that approach since we want access to the C api and Iâm pretty sure the only way to get it is through the event handler.
Ninja edit: we also wonât be supporting things like concurrency or libdispatch (no GCD) anytime soon since there is no threading we can latch onto. Again, another point for the RTOSes, they can provide that. We should look toward SwiftWASM for how they handled the libc problem. WASI is similar to clib but definitely not the same.
Edit 2: I have the swift project setup with targets and presets for playdate, including targeting the correct architecture, it gets pretty far along with trying to cross compile the runtime but I have quite a bit more work to do in order to ensure that all the right tools are being used. On a side note, it appears we can likely include the playdate c api as part of the stdlib, so when using this toolchain you will get that out of the box! I also have plenty of stubbing / things to disable. WASI is helpful in that we have somewhat similar limitations, and referencing embedded-swift + the madmachine repos is proving fruitful as well. Ideally, this wonât become as easily defunct as previous attempts for providing this functionality.
Edit 3: making it a little over halfway through compiling the runtime, the new concurrency changes are making a lot of assumptions about the existence of threads. There are levers to turn most of that off, but itâs not used everywhere it seems.
Edit 4: Iâm able to get a substantial amount of the runtime to compile & link but there are bugs in the swift side of compiling stdlib. Went too far down the rabbit hole trying to keep everything within the swift build scripts themselves. Going to revert my edits to the scripts and instead attempt to build and link standalone, with the intention of putting the scripts backs. Most of the edits in source can stay, theyâre straight forward and shouldnât change. Some of the checks can be cleaned up (the messy script problem started seeping into everything), but otherwise it should be good. A big problem I was having with the baremetal approach to scripting was how it glommed on to the other Apple / Darwin based SDKs in order to get similar treatment. Itâs an extremely brittle approach as these build scripts change between minor versions of swift in a pretty substantial way. There is not much work that actually is to be done in order to support a new platform, itâs figuring out the right incantations in the build script that is hard.
Edit 5: went back to the approach that adding WASI support took, including adding playdate as a proper OS to llvm. Having stared at all of this code long enough and seeing approaches people have taken inside and outside of the swift project, this one seems to most manageable to get working, further, it should make keeping up with a fork easier. Most of the other attempts at this seem to alter swift in such a way that itâs very hard to keep in sync with upstream. It could also be worth upstreaming this code, with the biggest difference from the other embedded attempts being that we arenât exactly targeting baremetal. This means less change in general to the overall swift project, is actually more correct, and doesnât open the can of worms that attempting to bring true baremetal support would. Another benefit would be the folks who keep refactoring the build scripts would need to do (most) that work for us, which is also the bulk of the work typically. More challenging is creating an environment for running stdlib tests, which would be required for upstream, challenging because it needs to be run on qemu or the like in a semi-hosted fashion.
