I have successfully compiled a single piece of runtime!
/Users/ericlewis/developer/swift-toolchain-exp/host-build/Ninja-Release/llvm-macosx-arm64/bin/clang++ --target=thumbv7em-unknown-playdate -DGTEST_HAS_RTTI=0 -DLLVM_DISABLE_ABI_BREAKING_CHECKS_ENFORCING=1 -DSWIFT_INLINE_NAMESPACE=__runtime -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/Users/ericlewis/developer/swift-toolchain-exp/target-build/swift-stdlib-playdate-thumbv7em/stdlib/public -I/Users/ericlewis/developer/swift-toolchain-exp/swift/stdlib/public -I/Users/ericlewis/Developer/swift-toolchain-exp/swift/stdlib/include -I/Users/ericlewis/developer/swift-toolchain-exp/target-build/swift-stdlib-playdate-thumbv7em/include -I/Users/ericlewis/Developer/swift-toolchain-exp/swift/include -I/Users/ericlewis/developer/swift-toolchain-exp/target-build/llvm-playdate-thumbv7em/include -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wdelete-non-virtual-dtor -Wno-comment -fdiagnostics-color -DOBJC_OLD_DISPATCH_PROTOTYPES=0 -O3 -DNDEBUG -fvisibility=hidden -fvisibility-inlines-hidden -fno-exceptions -fno-rtti -Werror=gnu -Werror=c++98-compat-extra-semi -DswiftCore_EXPORTS -DSWIFT_SUPPORT_OLD_MANGLING=0 -DSWIFT_STDLIB_HAS_TYPE_PRINTING -DSWIFT_TARGET_LIBRARY_NAME=swiftDemangling -DSWIFT_RUNTIME -target thumbv7em-unknown-playdate -O2 -g0 -DNDEBUG -I/ -DSWIFT_OBJC_INTEROP=0 -DSWIFT_LIBRARY_EVOLUTION=0 -DSWIFT_STDLIB_SUPPORT_BACK_DEPLOYMENT -DSWIFT_ENABLE_REFLECTION -DSWIFT_STDLIB_HAS_DLADDR -DSWIFT_STDLIB_HAS_DARWIN_LIBMALLOC=1 -DSWIFT_STDLIB_HAS_STDIN -DSWIFT_STDLIB_HAS_ENVIRON -DSWIFT_STDLIB_HAS_LOCALE -DSWIFT_STDLIB_SINGLE_THREADED_RUNTIME -DSWIFT_RUNTIME_OS_VERSIONING -DSWIFT_STDLIB_SHORT_MANGLING_LOOKUPS -DSWIFT_STDLIB_ENABLE_VECTOR_TYPES -DSWIFT_STDLIB_SUPPORTS_BACKTRACE_REPORTING -D SWIFT_STDLIB_ENABLE_UNICODE_DATA -MD -MT stdlib/public/CMakeFiles/swiftDemangling-playdate-thumbv7em.dir/__/__/lib/Demangling/Context.cpp.o -o Context.cpp.o -c /Users/ericlewis/developer/swift-toolchain-exp/swift/lib/Demangling/Context.cpp -I/Users/ericlewis/Downloads/gcc-arm-none-eabi-10.3-2021.10/usr/include/c++/10.3.1 -I/Users/ericlewis/Downloads/gcc-arm-none-eabi-10.3-2021.10/usr/include/c++/10.3.1/arm-none-eabi --sysroot=/Users/ericlewis/Downloads/gcc-arm-none-eabi-10.3-2021.10
Yes, this is using the wrong arm toolchain but it also works with the playdate distributed one, and yes some of the flags are most certainly incorrect. There are also some changes that I made to the folder in order for this to work, such as moving c++ bits to the top level and hacking on this to include newlib. Another noteworthy change is this is not using arm-none-eabi-gcc, but rather using clang and LLVMs support for the thumb architecture (which is considered experimental). Changing the compiler used is definitely a more complex task so my first effort is going to be seeing if what clang outputs is usable on device. The thesis mentions this as a possible path forward and instead decides that it would be easier use the entire toolchain provided by arm. I have a feeling this would most likely impact the linker step (I have only compiled, not linked yet), but that should be resolvable since WASI also uses it's own linker. We could indeed change any of this behavior in our PlaydateToolChains as well and if we need to switch compilers / linkers / etc, it would all happen there & in the driver. Getting the right include flags in place is the next step so I can continue compiling the rest of the runtime. It is easy enough to do so in a hacky way, so I may attempt that first, then move it to the ToolChains file (there is a non-trivial amount of work to creating such a file). Another worthy bit of investigation is around the swift stdlib freestanding flag, which appears to be helpful when you don't have a clib, (we sorta do, in newlib, but it needs to be stubbed / some features don't work)
Edit: another bit of consideration to have is that we are needing to use an entirely new swift toolchain, which becomes slightly problematic when we consider how compilation works now. I am unsure if we are able to completely alter the compiler behavior based on wether or not we are creating an executable or dynamic lib. This may require investigation into how building for iOS for sim or device works. It could very well be that we simply change the SDK we are pointed at to one that supports x86/aarch64, but again, I am not sure. For now the workaround is to simply switch toolchains depending on what you are targeting. It is possible that we need to alter this behavior in spm.
Aside: @mossprescott do you think we should move the dev progress of these things to this thread: Using the swift programming language on Playdate - #11 by ericlewis, since it is technically in dev by us.