Patent Application
20050027940
The present disclosure is directed generally to computer systems and, more particularly, to methods and apparatus to migrate a temporary memory location to a main memory location.
Modern computing systems include a processor and one or more external memories that must be initialized in the early stages of processor startup before a processor has loaded an operating system (OS). One problem is that external memory such as random access memory (RAM), which may be implemented using synchronous dynamic RAM (SDRAM), rambus dynamic RAM (RDRAM), double data rate SDRAM (DDR SDRAM), etc., has a long initialization process during which the RAM cannot be used. Accordingly, any processes that are executed by the computing system during startup cannot use external RAM to store variables, data, or any other constructs.
Due to the fact that external memory (e.g., RAM) is unavailable during pre-boot, most pre-boot code is written in assembly language that utilizes processor registers, rather than external memory. In contrast to pre-boot code, much of the available OS runtime software is written in a high level language, such as the C programming language. Unlike assembly code, code written in a high level language requires external memory to operate. For example, the C programming language uses external memory to maintain a stack and a heap. As will be readily appreciated by those having ordinary skill with the art, a stack is an information repository that stores program execution history and local data structures, and the heap is an information repository that stores dynamically allocated data structures (i.e. storage that is not known until the program is running).
As is known to those having ordinary skill in the art, code written in assembly language has many weaknesses. First, assembly code is complex to program because it is written at the machine level. Second, assembly code is not portable (e.g., assembly code written to run on an Intel® processor would have to be re-written to operate on another vendor's processor). Third, assembly language restricts a developer to using only hardware registers, and, therefore, has very little data storage capacity. Fourth, assembly languages are difficult to learn, because the syntax for the language is different for every platform on which a developer creates code. As will be readily appreciated, these weaknesses result in poor development productivity and brittleness (i.e., even a small and seemingly benign change to the assembly code can break the whole system) of programs written in assembly language.
Realizing the foregoing advantages of high level languages and the unavailability of external memory, some pre-boot code is written in high level languages in which the code is tricked into thinking an on-board processor cache, which is quickly initialized on processor reset, is an external memory in which program elements such as a stack and a heap may be stored. However, the processor cache may be flushed when the external (or main) memory becomes available, resulting in the loss of crucial state information and data stored in, for example, a stack and a heap. As will be readily appreciated by those having ordinary skill in the art, it is difficult to write high level language that can operate in spite of state and data loss that occur upon cache flush. Taking such care when using high level language drastically affects the benefits of using the same. Accordingly, some developers continue to write pre-boot code in assembly, as opposed to writing the code in a carefully-constructed high level language arrangement.
The following describes example methods, apparatus, and articles of manufacture that provide a code execution system having the ability to migrate stored information. While the following disclosure describes systems implemented using software or firmware executed by hardware, those having ordinary skill in the art will readily recognize that the disclosed systems could be implemented exclusively in hardware through the use of one or more custom circuits, such as, for example, application-specific integrated circuits (ASICs) or any other suitable combination of hardware and/or software.
In
The handler 102 may be implemented by code executing on a processor. The handler 102 controls access to temp memory 104 and main memory 106. As described in detail below, handler 102 also controls migration of stored information from the temp memory 104 to the main memory 106 after initialization of the main memory 106 is complete.
The temp memory 104 may be, for example, an L1 cache, which is on the same chip as the processor. In the alternative, temp memory 104 may be implemented as an L2 cache, on a separate chip, such as, for example, on static RAM (SRAM).
The main memory 106 may be a memory device external to the processor. For example, the main memory 106 may be implemented using RAM, such as SDRAM, RDRAM, DDR SDRAM, or the like, in which data and instructions are stored and retrieved. In the alternative, the main memory 106 may be implemented using any other memory device. The data stored in the main memory 106 may be arbitrarily complex and may, for example, take the form of a stack and/or a heap.
The modules 108, 110, 112 may be binary images resulting from a compiled high level language like the C programming language. The modules 108, 110, 112 may be, for example, binary images of drivers or other software firmware that may be executed in the pre-boot environment. The execution of the modules 108, 110, 112 is coordinated by the handler 102. Of course, as will be readily appreciated by those having ordinary skill in the art, more modules than those shown in
As described below, during operation the handler 102 coordinates the execution of the modules 108, 110, 112 such that prior to main memory 106 initialization, data constructs (such as a stack and/or a heap, etc.) are stored in the temp memory 104. When the main memory 106 initialization is complete, the handler 102 transfers the data constructs on other information (e.g., a stack and/or a heap) to the main memory 106. After the data constructs are moved to the main memory 106, the processor will continue to use the main memory 106 to hold the constructs during execution.
Turning now to
The example processor system 200 may be, for example, a conventional desktop personal computer, a notebook computer, a workstation or any other computing device. The processor 202 may be any type of processing unit, such as a microprocessor from the Intel® Pentium® family of microprocessors, the Intel® Itanium® family of microprocessors, and/or the Intel XScale® family of processors. The processor 202 may include a cache 234 that implements the temp memory 104 of
The input/output device 224 may be implemented using a keyboard, a mouse, a touch screen, a track pad, or any other device that enables a user to provide information to the processor 202. Alternatively or additionally, the input output device 224 may be a network connection that couples data to and from the processor 202.
The display device 226 may be, for example, a liquid crystal display (LCD) monitor, a cathode ray tube (CRT) monitor or any other suitable device that acts as an interface between the processor 202 and a user. The display device 226 as pictured in
The mass storage device 228 may be, for example, a conventional hard drive or any other magnetic or optical media that is readable by the processor 202.
The removable storage device drive 230 may be, for example, an optical drive, such as a compact disk-recordable (CD-R) drive, a compact disk-rewritable (CD-RW) drive, a (DVD) drive or any other optical drive. It may alternatively be, for example, a magnetic media drive. The removable storage media 232 is complimentary to the removable storage device drive 230, inasmuch as the media 232 is selected to operate with the drive 230. For example, if the removable storage device drive 230 is an optical drive, the removable storage media 232 may be a CD-R disk, a CD-RW disk, a DVD disk or any other suitable optical disk. On the other hand, if the removable storage device drive 230 is a magnetic media device, the removable storage media 232 may be, for example, a diskette or any other suitable magnetic storage media.
The RAM 206 and the cache 234 may be memory mapped to the processor 202 so that the processor 202 knows how to access the same. One example of a memory map is shown in
The area of the temp memory 104 is defined by a top of temp memory location 304 and a bottom of temp memory location 306. As shown in phantom relief in
Although the temp memory 104 and the main memory 106 are shown at the top and bottom of the of the memory map 300, those having ordinary skill in the art will readily recognize that the temp memory 104 and the main memory 106 may be located anywhere within the memory map 300. Furthermore, although the temp memory 104 is shown as being above the main memory 106 in
The area of main memory 106 is defined by a top of main memory location 314 and a bottom of main memory location 316. As shown in phantom relief in FIG. 3, a main memory heap storage area 318 is demarcated by a top of heap main memory location 320 and a bottom of heap main memory location 322. The main memory heap storage area 318 may be used as a storage repository for components associated with high level language code, such as a heap for dynamic data storage after the main memory 106 has been initialized.
A pre-boot process 400, as shown in
As will be readily appreciated by those having ordinary skill in the art, the boot block is a firmware portion that is executed when a processor (e.g., the processor 202) undergoes a reset. The pre-boot process 400 begins execution by starting initialization of the external memory (e.g., the RAM 206) (block 402). Some processors, for example, have a bit called MEMGO that can be modified to start the initialization of external memory. The memory initialization is a process that, once commenced, operates independently of the processor. Accordingly, the processor may continue with execution of the pre-boot process 400 as the memory is initializing.
After starting the external memory initialization (block 402), the pre-boot process 400 configures temporary memory (e.g., the cache 234) for stack and heap data storage (block 404). As will be readily appreciated by those having ordinary skill in the art, the processor 202 will autonomously evict (i.e., overwrite) portions of the cache 234 used as temporary memory unless configured in a no-eviction mode. Furthermore, upon storing stack and heap data in the cache for use by a high level language, evictions will result in the loss of key operational data. Due to the transitory nature of the cache as a data repository, care must be taken to set up the cache in a no-eviction mode.
After the temporary memory has been configured (block 404), a list of high level language modules to be executed is generated (block 406). Example modules that might be stored in the list are: a central processing unit (CPU) initialization module, a chipset initialization module, a board initialization module, etc. The list may be formed based on the unique pre-boot initialization requirements of the example processor system 200 of
After the list of high level language modules for execution has been created (block 406), the pre-boot process 400 determines if there are additional high level language modules to be invoked (block 408). If no additional high level language modules are to be invoked (block 408), the pre-boot process 400 ends and/or returns control to any calling routines (block 410).
Conversely, if additional high level language modules are to be invoked (block 408), a high level language module from the list is invoked and consumed using the temp memory 104 of
After the high level language module from the list is invoked and consumed (block 412), the pre-boot process 400 determines if main memory has completed its initialization (block 414). One way that the pre-boot process 400 may determine if main memory 106 of
Conversely, if main memory has completed its initialization (block 414), a migrate storage process is started (block 416), which as described in conjunction with
As shown in
As with the pre-boot process 400, the migrate storage process 416 may be implemented using one or more software programs or sets of instructions that are stored in one or more memories (e.g., the memories 206, 208, 210) and executed by one or more processors (e.g., the processor 202). However, some or all of the blocks of the migrate storage process 416 may be performed manually and/or by some other device. Additionally, although the migrate storage process 416 is described with reference to the flowchart illustrated in
After copying the temporary memory to main memory (block 502), a migration factor is calculated (block 504). An example algorithm for calculating the migration factor may be formulated by subtracting the value of the top of heap temp memory location 310 of
After the calculation of the migration factor (block 504), the migrate storage process 416 determines if any/more pointer entries need to be migrated (block 506). If no more pointer entries to be migrated exist (block 506), then the migrate storage process 416 ends and/or returns control to any calling process 400 (block 512).
Conversely, if more pointer entries to be migrated exist (block 506), then the migrate storage process 416 determines if the pointer entry is pointing at a location within the temporary memory heap 308 of
Conversely, if the pointer entry is pointing to a location within the temporary memory heap 318 of
After the pointer entry is migrated (block 510), then the migrate storage process 416 determines if more pointer entries need to be migrated (block 506).
Although certain apparatus constructed in accordance with the teachings of the invention have been described herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers every apparatus, method and article of manufacture fairly falling within the scope of the appended claims either literally or under the doctrine of equivalents.
