Standard Swift app in a concise hardware environment
So far, the Swift community has made several attempts, including server, AI, UI DSL, etc. and is still exploring the boundaries. Now Machine targeted field (such as IoT) is becoming a new era for the next decades. If we do want the Swift language to become a real system-level language, then this field cannot be neglected. And what I am trying to do is based on a natural idea: If Swift is targeting different platforms, then why not RTOS?
For some fields, Linux is too complicated, plus it requires complex hardware architecture. Fortunately, the Linux foundation introduced Zephyr for the fields where Linux is notably absent. I have confidence in this new combination: concise Swift-based software architecture + simple and reliable hardware architecture. It would open up a whole new field.
Swift is really suitable for building complicated app models. As for the hardware, you can see, in the image below, TI just published an 800MHz MCU with 4 cores, NXP introduced a 1GHz MCU. I cannot imagine how I develop applications for such powerful processors using only the C language.
What I have done to run Swift code with Zephyr
I’ve introduced my work in detail in my previous post, I’ll give a brief list here:
-
Modify Swift compiler to support ARM-Cortex M arch -
Cross-ompile Swift std for ARM-Cortex M arch
-
Bind Swift runtime with Zephyr just as porting the runtime to other general OSes -
Bind Swift concurrency implementation with Zephyr
What I’ve got: Standard Swift app can absolutely run on non-MMU CPU
- Now, almost all pure Swift code (without Foundation and Concurrency) can run normally on the MCU board.
- After all stuff (Zephyr, Swift std/runtime, app) is statically linked together, the binary size (raw binary, not ELF format) is around 2.5MB which can run perfectly on an 8MB ROM, and 1MB (Internal) RAM MCU board.
I’m full of expectations towards its future development.
What support I need to make this better
-
Swift runtime has been bound so tightly to the general OSes. And it mainly uses macros in multiple runtime C++ files to realize it. However, as I am not specialized in programming language/compiler, it’s not easy to clarify each part in runtime and its role. So I am wondering if it is possible to divide the part related to the OS interfaces into more organized layers to make the runtime more like a standard C++ library, thus it can be more convenient to get compatible with different OS interfaces. If this solution needs to involve a huge change, a brief guide about runtime framwork would be of great help.
-
Better ways for I/O bound operations and multicore task management are desperately needed in MCU world at present. The Swift concurrency feature opens up new possibilities. However, this now depends on a lot of external libraries. Does the Swift team have a plan to implement concurrency feature in the runtime-level library and exclude other external dependencies? Just as what you have done with libICU?
-
In the RTOS field, the mostly used compilers are still commercial ones, such as IAR, KEIL, and GCC is almost the only open source tool widely used. The current RTOS involves many toolchain-specific designs, which make it hard to be treated as a normal library. Our current development procedure is similar to that of the Embedded Linux app, but in a much more simplified way: the BSP (Board support package) and kernel (Zephyr) normally serve as a batch of binary libraries in ELF format, then you will still need some stuff provided by gcc toolchain during the linking time, such as
libstdc++,libgcc, etc. In short term, I have to choose gcc ld as the final linker. Again, if Swift team could provide better tooling integration, that would be of great help!