IPC@CHIP® RTOS-PPC – API Documentation
The operation of the @CHIP-RTOS-PPC loader's Virtual Address Space Manager is discussed here.
Application programs are assigned virtual address space for their loaded image within the CPU's 256 Mbyte segment 1. This segment ranges from address 0x1000,0000 up to 0x1FFF,FFFF, inclusive. The system's Virtual Address Space Manager tracks the allocation of this space using 8 Mbyte sectors. Therefore 8 Mbyte (=0x0080,0000) is the granularity of the allocations.
(The term "virtual address" is being used here to refer to what the PowerPC architecture manuals call "effective address". For this discussion, we overlook the differences between these two concepts. In any case, we are referring to the addresses as programmers will see them, and not to the actual physical addresses of memory which appear on the hardware address lines following the address translation by the MMU.)
By default, each application program will be reserved 32 MByte of address space when this is possible. Reserved address space allows for a program to extend its heap space at runtime by allocating additional memory from the system heap on demand. However for this to succeed there must not only be physical memory still available in the system heap, but also more virtual address space available immediately above this program's current allocation of address space. By having the system reserve some address space, the successful extension of the program's image is made more likely.
When designating the amount of reserved address space, a programs image space will be included in this count.
Although the system's virtual address space manager does try to respect a program's address space reservation, this reservation is not strictly regarded when the system has no other option. If another program launch is under way and there is not otherwise address space available for this application, then reserve space belonging to the application programs which are already running may be eaten into.
The system prefers to use free blocks of address space for new programs, but it will resort to using reserved blocks if the new program launch would otherwise not be possible. New programs may be placed in either free or reserved space, stealing reserve address space from programs that were already loaded where necessary.
The situation after eight programs have been launched would typically look as shown in the diagram below.
The regions designated in the diagram's legend as "Used Address Space" are those backed by physical memory containing the program's image. This area is followed by a padding up to the nearest 8 MByte address space allocation boundary, as indicated by the green shaded regions. No physical memory is allocated in these green regions.
At this point if yet another program is launched, one of the existing programs will need to sacrifice some of their reserved space in order to give a 9th program space to run. This is illustrated in the following diagram.
The first program has now donated 8 Mbytes of its reserved address space to make space for the new program #9. And the system was unable to offer this new program any reserve address space after its allocated 8 Mbytes of space.
Note that if this 9th program was a very large program with an image size over 24 MByte, the launch would have failed under these conditions with an error message "Address space assignment failed".
Application programs can override the default allocation of 32 MByte reserved address space. This is done with the setSpaceReserve macro. By reducing the reserved space, an application can be more neighbor friendly. Consider how 8 such programs, each with image size under 8 MByte would look in the address space when each of these program uses a
setSpaceReserve(1) macro to eliminate its reserve address space. In this case the 8 programs would sit in the address space as shown below.
Now there is plenty of address space remaining. The system would be able to launch very large additional programs.
In order to further illustrate address space reservation, let us change program #7 so that it has an image size of 15 Mbyte and it contains a
setSpaceReserve(23) macro statement. Note that the reservation of 23 MByte includes the program's 15 Mbyte image space. And also note that reserved space is always rounded up to the nearest allocation unit size, which is 8 MByte. So the resulting address space picture would be as shown below, with a total of 24 MBytes of address space set aside for Program #7.