> interestingly, this is the first esp32 firmware i've seen that claims to support loadable native code applications ("elf apps"),
Very skeptical that this is of any use; after bootup you have, what ... 260kb of RAM? Just doing runtime linking/relocations would eat up some of that. Just how small would your application have to be to be loaded at runtime?
Maybe they don't load the whole think into RAM, but thunk it somehow (I assume that elf supports that)?
Some variants of the ESP32 support executing code from external memory (PSRAM) too. That gives you 8MB more to play with.
Some ESP32's have 8MB of PSRAM and 16MB of flash "storage". You can theoretically also add external SRAM modules but I've never seen that IRL for the ESP32 family. I've occasionally seen the flash used as slower, persistent RAM.
You don't link bunch of stuffs in RAM at execution time on embedded devices... all static and anything static stays in ROM. "eXecute In Place". ROM's just slow RAM that forget writes. Only variables goes on to RAM, and 260kB is enough for a lot of non-multimedia data.
Pretty sure with xtensa and gcc you can compile to PIC. Google says a linker only would need to modify the Global Offset Table and Procedure Linkage Table. That doesn't sound too terrible.
Also 260kB of RAM on a 32bit processor could be a fair bit of code. Plus you could write it to external or internal flash. Though I don't know if esp-idf supports XIP (Zephyr does).
> esp-idf supports XIP
XIP depends on hardware support, not software.
The Apollo Guidance Computer only had 4kb of RAM and got to the moon and back.
There must be some a.out format there or .com like in Dos. Also original Unix run at 48kb of ram