The UEFI Drivers in the two examples above do not contain any instruction set architecture-specific files. This absence means that this driver is designed to be portable between all CPU architecture supported by the UEFI Specification. If a UEFI Driver requires instruction set architecture-specific source files, then those source files are typically placed in subdirectories below the UEFI driver's main directory in an EDK II package. A separate subdirectory is required for each instruction set architecture that the UEFI Driver supports. The table below lists the directory names that are reserved for the instruction set architecture-specific files.
Note: Code written in EBC is still C language code, and the sources look the same as for any other driver. It is when the compiler converts it from a high-level language (C) to object code (EBC versus native code) that the difference becomes evident.
For EBC, the object code generated is not native to the processor but rather is pseudo-object-code that looks like RISC processor object code. That code is fed into an interpreter, which interprets each instruction and acts upon it. The EBC output is not 32-bit or 64-bit-based, but rather conforms to its own standard. Thus a system with a valid interpreter for its architecture can translate EBC compiled code into operational instructions on any given architecture.