Wiley.Developing.Software.for.Symbian.OS.2nd.Edition.Dec.2007 (779887), страница 16
Текст из файла (страница 16)
For example, the Sony Ericsson P990 and theNokia N95 have 128 MB of internal flash space. On many phones,MEMORY IN SYMBIAN OS71however, available internal user space is significantly less. The Nokia6600, for example, has 6 MB of flash space available to the user.•Removable Memory CardsMemory cards act as removable disk drives and allow you to expandthe storage provided internally.
You can also read from and write to amemory card just as to the internal disk – including operations such assaving user data, and even installing applications. This card is treatedas another disk volume by the file system and is represented by adrive letter such as D or E (this varies between phones). The memorycard formats (MMC and SD are examples) and available sizes varyby phone. Memory card sizes can vary from 16 MB (or even less) to1 GB (or even more).•Hard DriveHard drives have started appearing in smartphones. For example, theNokia N91 has an 8 GB hard drive.In this section, I’ll describe how Symbian OS organizes its memorymap and how processes use it.
This information is not strictly needed todevelop typical Symbian OS applications, since this functionality occursbehind the scenes. However, it can help when dealing with some difficultissues (or, perhaps, for tweaking performance), or even for providing adeeper understanding of some of the system APIs.3.5.1 How Memory is AddressedAt the time of writing, Symbian OS smartphones exclusively use ARMbased microprocessors. ARMs use 32-bit memory addresses and thus arecapable of addressing 4 GB of memory – much more memory than asmartphone will ever need (well, maybe not ‘ever’).There are two types of memory addresses: virtual and physical. Virtualaddresses are the addresses that software deals with.
When you set orexamine a C or C++ pointer, or even look at an address at the assemblylevel, you are dealing with a virtual address. Physical addresses are theunchanging hardware addresses of the memory hardware (they reflecthow the hardware address lines are hooked to the memory components).In older CPUs, there was no concept of virtual and physical addressessince the software simply always used the memory’s fixed physicaladdress.
However, most modern processors, including the ARM processor, have a Memory Management Unit (MMU) that allows the systemsoftware to flexibly map and remap virtual addresses to represent differentphysical addresses. With the MMU, the operating system can organizeand manage its own memory map by setting up a memory translationtable in the MMU. Memory blocks can be moved almost instantaneouslywithout any copying, only remapping, of addresses (e.g., when switchingprocess data in and out).72SYMBIAN OS ARCHITECTUREIn addition to providing address translation, the MMU also provides thecapability of protecting memory regions from being accessed by softwarenot running at a specified privilege level or higher.Note that to save costs, even modern smartphone designs could includeCPUs without an MMU, although this is not common. Symbian OS cansupport processors with and without MMUs.3.5.2 Chunks in Symbian OSSymbian OS uses chunks to represent contiguous regions of virtualmemory.
The size of a chunk is variable. The kernel uses the MMU tomap physical memory to the virtual address range of the chunk, and toremap it quickly to different areas of virtual memory as needed (mainlyfor context switches, as you’ll soon see).While chunks reserve a range of virtual memory addresses, the entirerange need not have actual physical memory behind it.
The kernel canadd more physical memory behind the chunk as needed. Remember:virtual addresses are plentiful (4 GB!); real physical memory is muchmore scarce.Symbian OS provides a public API so that you can use chunks directly(RChunk class, described in Chapter 9). It’s not very common for thetypical application to use them (although they can come in handy ifyou need system-wide global data).
Symbian OS itself, however, makesextensive use of chunks to manage your programs and its data behind thescenes, as described in the next section.3.5.3 A Process in MemoryWhen a process is created, Symbian OS creates the following chunks forit (at a minimum):Static Data and Stack ChunkThis chunk is where the static data and stack resides for the processand all its threads.Heap Chunk(s)Where the heap is stored. There can be a heap chunk for each thread,but a heap chunk can also be shared between all threads.Code ChunkThe code chunk contains a copy of the code. There is only one copyof a code chunk in memory, shared by all running instances of thatprocess executable.
Note that if the executable is on the phone’s ROM,then the code is run in place, without copying it to a code chunk.MEMORY IN SYMBIAN OS733.5.4 Virtual Memory Map in Symbian OSThe basic map of virtual memory usage in Symbian OS is shown inFigure 3.2.2In Figure 3.2, the two memory areas of interest are the home area andthe run area. The home area is where the data chunks for a process arekept when the process has been launched but is not the currently activeprocess. The home area is a protected region of memory – only kernellevel code can read and write it.
When a thread is scheduled to execute,the data chunks associated with its process are moved (remapped via theMMU) from the home area of virtual memory to the area known as therun area, and thread execution starts.You can think of the run area as a sort of stage for processes, and thehome area as the backstage area. When a process is ready to perform, itgoes on stage – that is, its data chunks are moved to the run area, and theprocess executes.Why aren’t the process data chunks simply left in the home area whenthe process executes? The reason is that the process code always expectsits data to reside in the same place. This is because the linker places dataHome Area0xffffffff0x80000000ROM, MMU Page Table, Hardware0x3fffffffRun AreaCPU Use0x004000000x00000000Figure 3.2 Virtual Memory Map2Note that different memory organizations are best suited to different CPU architectures.Symbian OS describes these organizations as memory models and allows the device creatorto select the most appropriate model for their chosen hardware.
Currently the most commonorganization is the moving memory model that is appropriate for ARM v5 CPU architectures,the moving memory model is considered in this book and what is described in this section.The multiple memory model is likely to be used on an ARMv6 CPU architecture, and is notcovered in this book.74SYMBIAN OS ARCHITECTUREaddress references (when code references a static variable, for example)in the code image at build time.
Thus, the process code expects its datain the single place specified by the linker (i.e., the run area) – no matterwhat instance of the program is running. There are also other reasons forhaving movable chunks like this, including moving in the memory mapin order to give it space to grow.Note, however, that code chunks are never moved to the run area.This is because, unlike data chunks, you do not have separate copies ofcode for each process instance and the code can be run from its locationin the home area.Remapping the data of a running process to a common virtual addressarea is not unique to Symbian OS. Many other multitasking operatingsystems do this as well – although the memory map and switching detailsare different.3.5.5 Switching Processes – Detailed ExampleFigure 3.3 illustrates process switching, as described in the last section,in more detail.Program A and Program B represent executables contained in EXEfiles.
As we are running two instances of Program A, the ‘ nn’ representsa process instance of that executable.As mentioned, every code image assumes its data is in the run area,and the kernel handles moving the data into the run area when the codeis run.Below is a sample scenario:1.Program A is invoked for the first time and the kernel loads thecode from flash disk to RAM and creates a process (ProgramA 01).The kernel then allocates data chunks for that process in the homearea.2.Another instance of Program A is invoked and the kernel createsa new process (ProgramA 02). It associates it with the same codearea from Step 1 and creates new data chunks for that process inthe home area.3.The kernel schedules ProgramA 01 for execution.4.The MMU page table is changed to remap all physical memorypages associated with ProgramA 01’s data from its home arealocation to the common run area.5.The code image associated with Program A executes.6.The kernel switches context from ProgramA 01 to ProgramA 02.MEMORY IN SYMBIAN OS757.The MMU page table is changed to remap the data chunks ofProgramA 01 from the run area to its original home area location(may be relocated if chunks have grown in size).8.The data chunks of ProgramA 02 are then mapped to the run areaand control is passed back to the Program A code region, but at theappropriate instruction, with respect to the thread context.9.The kernel switches context from ProgramA 01 and calls ProgramB for the first time.10.The kernel loads the code for Program B from flash to the home areaand creates chunks for the ProgramB 01 data in the home area.11.To execute Program B, the kernel remaps the ProgramB 01 datafrom the home area to the run area and the code image of ProgramB executes.Home AreaProgram A codeProgram B codeProgramA_01 process dataProgramA_02 process dataProgramB_01 process dataROM, Hardware, Page tables, etc.Re-mapcurrent todata areaRun AreaRunning process dataCPU Data AreaFigure 3.3Structure of the Virtual Machine76SYMBIAN OS ARCHITECTURE3.5.6 Protecting Processes from Each OtherAnother feature of memory handling in Symbian OS is protection.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
