Abstract
Unified Extensible Firmware Interface (UEFI) is a specification which describes an interface between the operating system (OS) and the platform firmware. UEFI is a replacement for BIOS. The UEFI Specification describes how to write drivers for a device. One of the design goals in the UEFI Specification is keeping the driver images as small as possible. But the primary disadvantage of this specification is, these device drivers will be platform- and processor-dependent.
In addition to the standard architecture-specific (native) device drivers, the EFI specification also provides for a processor-independent device driver environment, known as the EFI Byte Code (EBC) Virtual Machine, which enables execution of device drivers written in EFI Byte Code, independent of the platform and architecture.
It follows that the target machine architecture is unknown during the compilation of an EBC image, since the compiled EBC image can potentially be run on any architecture and platform that supports the EBC Virtual Machine. In order to support writing such (EBC) code that can be executed unchanged on both 32- and 64-bit architectures, the UEFI specification describes a natural indexing mechanism, along with the introduction of a new integral type INTN, the size of which is dependent on the runtime target architecture. This implies that the size of the pointer (void*) and the newly introduced natural types (INTN/UINTN) is unknown at compile time, being dependent on the runtime architecture of the platform on which the EBC driver is executed.
The above specification creates several challenges in implementation of the EBC compiler. One of the basic assumptions in any compiler implementation is that the size and alignment of all types are known at compile time, enabling the compiler to be able to generate correct object layouts, structure field offsets, array indexes, load/store alignments, and to be able to correctly compute the function call stack frame allocations, etc. Accordingly, all static language compilers such as C/C++ compilers expect the type system of the language to be well-known at compile-time, with no concept of types dependent on the runtime platform. Unfortunately, the UEFI specification defines the source language for EBC device drivers to be the C language with certain restrictions, implying that the compiler implementation for the static C language be able to handle such runtime platform dependent types.
It would follow that a well-defined technique to handle pointer (void*) and natural (INTN/UINTN) types with runtime target dependent size is critical in being able to implement a C compiler with the ability to compile to (target) platform and processor independent EBC.
Unfortunately, there are no documented and well-defined techniques to implement a compiler with the ability to support such types with unknown compile-time size and alignment.
Creative Commons License
This work is licensed under a Creative Commons Attribution-Noncommercial-No Derivative Works 4.0 License.
Recommended Citation
T P, Kiran Kumar and Chatterjee, Soumitra, "A least-disruptive mechanism to compile integral and pointer types of unknown compile-time size to EFI Byte Code", Technical Disclosure Commons, (July 30, 2018)
https://www.tdcommons.org/dpubs_series/1381