Hi @ericlewis, happy to hear that someone is working on the same target : )
Very good question : ）
Firstly, as I said, RTOS is normally provided at source code level. It is just a batch of C code. It's a very ordinary library whose name is “RTOS”. Your app code and the RTOS code form the final application which runs on bare-metal. So using a toolchain targeting bare-metal is the normal case no matter if you use an RTOS.
Secondly, the OS in the target triple is used by the compiler to invoke some standard OS APIs. The main general OSes provide similar APIs for the fundamental operations, there’s only tiny difference between them. Unfortunately, this standard doesn’t exist in RTOS world. There are hundreds of different RTOSes. Just chaos.
Since Zephyr has the ambition to rule the place that Linux cannot cover, I believe the situation would be different in the near future. They do have the plan to add the zephyr target into GCC compiler. Once they don't change their API day to day , that’s the time we can start considering adding it into Swift/LLVM toolchain.
I just went to findchips for the pricing info. And yes, it is mostly a supply constraint at the moment.
What I was trying to say was (at least in my experience) that the most embedded chips are not 600MHz Cortex M7 chips but more lower end MCU like the Cortex M0/M3 types.
If the idea is to support lower end chips eventually but to get it working on a higher end first (more room / faster etc) I fully understand, since there is little to no room on an M0. But I would like to make the point that lower end MCUs are in much larger volume and not taking these into account for swift embedded would be missing a large target audience.
I'm happy to read that CMSIS support is already in Zephyr, although in a limited fashion. I will take a further look into Zephyr. A quick read of the original link didn't mention CMSIS (my assumption that it was missing was incorrect) but I am more familiar with RTX / FreeRTOS / SafeRTOS, which are CMSIS compliant.
Please do not misunderstand me that I am criticizing what you are tying to do, I fully support your idea and the time you are spending on this. I am just trying to give some input from someone who spend the last 20 years working on embedded devices.
I really appreciate your advice. And you are right, our plan is to use this high-end chip to find out the limitation of Swift in this area. If everything goes well, we can do some cost-down work then. Due to the chip shortage, seems there is still a long way to go
Something I have found really interesting is the way SwiftWASM has approach their project. If you look closely at their additions to the codebases you can see how similar it is to bare-metal-esque targets. I have been reading into it even more and am slowly working towards creating something similar for thumbv7em targets, with the hope that it can be kept in sync with upstream until it can be upstreamed.
edit: assuming we use the thumbv7em target that is already in LLVM.