If it's running on MMU-less systems, I'd be interested in how it loads multiple programs into memory: does it need to relocate each program binary? If so, doesn't that preclude using execute-in-place (XIP)?
If it's running on MMU-less systems, I'd be interested in how it loads multiple programs into memory: does it need to relocate each program binary? If so, doesn't that preclude using execute-in-place (XIP)?
"COM" programs as seen in MS DOS and earlier CP/M systems contain only relative addresses, and can run from any "segment" of RAM, as the addresses are relative to the value of a segment register. This was used to load "background" services, typically servicing hardware devices.
MCUs with MMUs are starting to appear, such as the ESP32-S31.
Generally, running in a MMU without static task config would require relocatable binaries. I'm not sure why it'd preclude execute-in-place. As a relocatable binary should be executable from generally any address space. However I suspect that hardware without an MMU is not super likely to be able to support XIP.
It is based on FreeRTOS, so it should be fairly well documented.
> I suspect that hardware without an MMU is not super likely to be able to support XIP.
This seems strange to me. Don't most microcontrollers support executing directly from flash? Some even can't execute from RAM.
Though I agree with the main point, you can compile code as "PIC" - position independent code, and not bother with (ELF) relocations except for linking.
> Don't most microcontrollers support executing directly from flash?
Yes... I presume they meant XIP for multiple programs at once, since you'd need an MMU for that.
> since you'd need an MMU for that.
Or PIC code... PalmOS 5 & 6 allowed multiple programs in same memory and they were simply compiled pic. MMU was not used
Some architectures (ARM, RISCV, aarch64) are well suited for this kind of code. Others are extremely poorly suited (x86, MIPS), but all CAN do it
Or the program use relative addressing.