Browse Prior Art Database

Design for the use of a priori resource consumption to formulate a fixed dispatch order from a class of heterogeneous executable components via static dispatch resolution and run-time examination deferral

IP.com Disclosure Number: IPCOM000012989D
Publication Date: 2003-Jun-11
Document File: 5 page(s) / 57K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a design for the use of a priori resource consumption to formulate a fixed dispatch order from a class of heterogeneous executable components via Static Dispatch Resolution and Runtime Examination Deferral. Benefits include improved boot processing time by minimizing the performance penalty associated with dynamic module dispatch without complicating.

This text was extracted from a Microsoft Word document.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 26% of the total text.

Design for the use of a priori resource consumption to formulate a fixed dispatch order from a class of heterogeneous executable components via static dispatch resolution and run-time examination deferral                � � � � � � � � � � � � � � � � � � � � � � � � �

Disclosed is a design for the use of a priori resource consumption to formulate a fixed dispatch order from a class of heterogeneous executable components via Static Dispatch Resolution and Runtime Examination Deferral. Benefits include improved boot processing time by minimizing the performance penalty associated with dynamic module dispatch without complicating.

        � � � � � In conventional component firmware architecture, an early stage of execution is referred to as the Pre EFI Initialization (PEI). This phase is characterized by a series of firmware modules called PEIMs. They execute in place in the memory-mapped flash component during early system initialization prior to main system memory initialization. These components provide initialization services for the hardware platform. Their most notable service is the configuration of the memory controller. PEIM execution, or dispatch order, is mediated by a 2-tuple of data structures, the Consumed GUID List (CGL) and the Produced GUID List (PGL). The CGL and PGL are lists of the interfaces that a given PEIM requires and produces, respectively. A module is not allowed to execute until all of the GUIDs in its CGL have been satisfied, or in other words, the modules whose PGLs satisfy the CGL under investigation have already been executed. What this ready-to-execute approach means is that the list of module PGLs, also called exports, is processed exhaustively after each module dispatch to see if any additional PEIMs meet the execution requirements (see Figure 1).

        � � � � � The flash component from which these conventional components execute is characterized by poor-bandwidth emulating the 8 MB/S throughput of the venerable ISA bus. This bandwidth is in contrast to the main memory bandwidth in the 100’s of MB/S. Because of this disparity, system firmware shadows (copies) its code and key data structures to memory for execution at the earliest possible time. PEI, however, precedes main memory and cannot shadow.� A performance penalty results from the exhaustive flash accesses for code fetches and CGL/PGL examination.

        � � � � � The time complexity of this situation can be addressed somewhat by pruning the class of PEIMs that need PGL/CGL inspection. The disclosed method is a build- or system firmware-update time analysis of the modules. This method is called Static Dispatch Resolution, and it works as follows. Sort the PEIM modules topologically based on resource consumption. In other words, sort the modules such that they are in a scan order guaranteed to satisfy the CGL/PGL relationship. Then, mark each module’s flag field to declare that it is in Satisfied, Sorted Order (SSO) so that it does not have its CGL examined against peer modules.

� �...