IPC@CHIP® RTOS-PPC – API Documentation
The IPC@CHIP® Memory/Time Manager provides a protected environment for program execution.
The system offers two different modes of execution within application programs. These modes are designated "User mode" and "Supervisor mode".
This mode is the default mode of operation for tasks within an application program. The system and other programs are protected from damage from unintended memory writes from a program that executes in "User Mode". For this reason, this is the recommended mode of operation for most applications.
Supervisor mode execution is privileged. The full set of processor instructions are available including those which are normally required only by the operating system. No read/write restrictions are placed on the memory and device accesses within the system's address space. Consequently, a program executing in Supervisor mode can easily crash the entire system when any programming errors are present. Likewise, a program executing in Supervisor mode can interfere with memory belonging to another program and thereby cause that other program to malfunction.
A supervisor mode task is created by setting the RTX_TA_SUPV_MODE flag in the tkdAttr member of the RtxTaskDefS data structure used with the RTX_NewTask() API. The appropriate flag bit must be set in a program's __prog_attributes flags to run the main() task in supervisor mode.
The system uses the computer's Memory Management Unit (MMU) to control application program's write access. Each application can only write to its own memory area when operating in user mode, which is the default mode of execution. The application has read access to the entire system memory space plus the memory space of any other application programs. The system's hardware space is not addressable by the application program in user mode by default.
Note that unlike with some operating systems, all programs currently executing are all contained in the same address space. Only the access rights differ between programs, and not the addresses at which objects reside. So by default, each program can read freely from neighbor programs or from the system memory. Only write accesses are restricted to those within a specific program's own space.
For a more in depth discussion of how the virtual address space is managed by the system, go here.
The RTX_MemWindow() API can be used to gain write access into a another application's memory or to hardware resources.
Illegal memory accesses will result in MMU exceptions. The system's fault exception handler will scan the current task's stack for a Try/Catch exception handler registration mark and will kill the current task if no such user exception handler is found. (The RTX_Trigger_Task() API could be used to restart the task for another go.) If an exception handler is recognized, the user application is re-entered at the respective TryDejavu() call.
Other faults (e.g. invalid opcode) are handled by the system in an identical fashion.
The protected nature of this system is not 100%. The system is sensitive to any of the following actions by an application program, for which the programmer must take extra care. These actions can kill the entire system: