The memory model has some limitations.I wonder what is the memory model, some requirements to the linking - I have not found any in your examples, how the binary is linked, how would you like to provide command line parameters to the binary files (environment variables access, etc).
I believe we expect simple single tasking system. And we are hoping for better performance / speed than running python...
- Section .code is executed directly from Flash memory.
- User binaries must have no .data or .bss segment.
- All programs (tasks) use the same stack. There is no stack switching. With respect to the stack, starting an *.exe binary is much like calling a subroutine.
- Each program can allocate memory from a memory heap, much like standard malloc/free/realloc.
- When a program (exe binary) is started it gets it's own heap, nested inside the parent's heap. When a program finishes, it's heap is destroyed.
Code:
target_link_options(${arg} PRIVATE -shared -fPIC -nostartfiles -e main -B$ENV{HOME}/.local/lib/fpm/arm)Standard parameters argc+argv are passed as for ordinary subroutine call. Note: There is no barrier between parent and child tasks.
Code:
// Invoke ELF binary. exit_code = (*entry)(argc, argv);There is no tasking system. No SVC exceptions: a direct branch-and-link instruction is used in user code for kernel calls. Dynamic loader creates appropriate bindings (on stack) when *.exe binary is loaded.
The performance is expected to be much better than Python.
Statistics: Posted by Serge_V — Fri Jan 24, 2025 1:57 am