Typically, in an embedded system or a large-scale integration (LSI), a system in which multiple central processing units (CPU) or digital signal processors (DSP) are embedded on a single chip is designed. Such a system is called a multiprocessing system, and is classified into two types, symmetric multiprocessing (SMP) systems and asymmetric multiprocessing (AMP) systems.
FIG. 9 is a block diagram of an SMP system. In an SMP system 900, basically, multiple CPUs (CPU 0 to CPU 3) 930 can act equally. Accordingly, when the CPUs 930 process a task 910, similar program code may be used. Processing performed by the CPUs 930 of the SMP system 900 may be performed without discrimination between kernel process and user process, and may be performed simultaneously by the CPUs 930.
Moreover, the SMP system 900 requires an operating system (OS) 920 that supports the SMP system. Further, the program code shared in the SMP system 900 is to be usable by a multiprocessor. Such a program that executes exclusive control or execution sequence control dependent on interrupt inhibition and task priority in a system of a single processor cannot work normally in the SMP system 900.
FIGS. 10 to 12 are block diagrams of configuration examples 1 to 3 of an AMP system. An AMP system is a multiprocessing system that is not an SMP system. In an AMP system, roles of respective CPUs are determined such as a CPU executing kernel process and a CPU executing a function of a user application. Furthermore, an AMP system may have various configurations as depicted in FIGS. 10 to 12.
An AMP system 1000 depicted in FIG. 10 includes multiple CPUs (CPU 0 to CPU 3) 1030. CPU 0 to CPU 3 may be of a similar kind or of different kinds, and an OS (OS 1 to OS 3) 1020 is designated for each CPU. In the example of the AMP system 1000, the role of each CPU 1030 is determined as described above, and therefore, a task 1010 of a process subject is also assigned to each CPU 1030, such as a task A (tasks 1 to 3) to be processed by CPU 0, and a task B (tasks 4 to 6) to be processed by CPU 1. In such a case, each CPU 1030 accesses tasks assigned thereto.
An AMP system 1100 depicted in FIG. 11 includes multiple CPUs (CPU 0 to CPU 3) 1130. The respective CPUs 1130 are of a similar kind. As this in example, if the CPUs 1130 are of a similar kind, an OS to be used may be a single type of OS 1120. Therefore, the respective CPUs 1130 process tasks 1110 assigned thereto using an identical OS 1120.
An AMP system 1200 depicted in FIG. 12 includes multiple CPUs (CPU 0 to CPU 3) 1230, where CPU 0 to CPU 1 are of a similar kind. In such a case, CPU 0 and CPU 1 process a task A among tasks 1210 using a common OS 1220 (OS 0). The other CPUs (CPU 2, CPU 3) 1230 process the tasks (tasks B, C) 1210 assigned thereto, using the OS 1220 corresponding thereto.
The configuration of a multiprocessing system includes, for example, a tightly coupled multiprocessor (TCMP) system in which a main memory is shared by multiple CPUs, and the main memory and the CPUs are tightly coupled by a crossbar switch or the like, and a loosely coupled multiprocessor (LCMP) in which a main memory can be shared or not shared by multiple CPUs, and the main memory and the CPUs are loosely coupled.
Generally, if software assets/program assets developed by one existing OS are present in an embedded system, the software assets/program assets are desired to be usable even when the system is changed to a new system. Therefore, a program is loaded by the existing OS. Particularly, when the new system is the AMP system, with respect to programs executed by the slave CPU, it is desirable for the existing programs to be operated on the existing OS as before. In such a case, when the software assets/program assets are to be used, the existing OS is loaded to execute the programs.
When the existing OS is loaded to execute a program, a statically linked scheme and a dynamic linked scheme may be applied. In the static link, a program is divided into modules at the time of creation of the program. After compiling the modules, an object file is linked together with a general purpose library to create a load module (binary) in an executable format. In the dynamic loading, a program is linked to another module or a library when execution of the program is started, or when a routine is called during the operation (for example, see Japanese Laid-Open Patent No. 2002-99439).
When the program is statically loaded, a slave CPU loads all programs that have a potential of being executed. On the other hand, in the case of an OS (Windows (registered trademark), UNIX (registered trademark), Linux, or the like) that supports a virtual memory and that may dynamically load a program and execute by linking thereto, a code shared by multiple tasks in the program is described by a position independent code (PIC), and is dynamically linked at the time of execution, as a shared library (dynamic link library).
However, in the AMP system or the LCMP system described above, there are many programs that use an existing OS that are incapable of dynamic loading. When a program cannot be dynamically loaded, a slave CPU loads all programs (tasks) that may be executed using OS 1, into a main memory in advance when OS 1 is loaded. For this, a memory area to be used for other processing in the main memory decreases. Such program loading may cause a problem in that the processing speed of each CPU becomes slow.
When the above problem occurs, generally, a technique such as a shared library and a dynamic link loader (DLL) is used. A system that realizes this technique implements a virtual memory because an OS uses a paged memory management part (MMU) that manages correspondence between a virtual address space and a real address space in page part.
However, many OSs for an embedded processor represented by an OS of μITRON and the like do not implement a virtual memory. In the OS of μITRON, an OS executed on a CPU and “functions constituting multiple tasks” are normally statically linked. Therefore, a load module often uses absolute addressing.
As described, when a virtual memory is not implemented, an application program statically links all libraries that are used (function is called) by a task itself. When an application program is to be dynamically loaded, all libraries that are used by a task itself are to be statically linked for each application program. That is, C library or the like is to be present for each application program. Therefore, if multiple application programs are executed, a similar library is required to be present as many times as the number of the application programs in an address space of the main memory. This causes a problem in that a large area of the main memory is required.
In addition, to make an application program that has already been developed support the DLL on a new OS, the application program and the OS have to be changed, and a program has to be developed separately, resulting in increased development costs.
USPTO Backgrounds
USPTO Backgrounds