Which programming language is used to write a BIOS program?

Question

As I understand, the BIOS code/bitstream that is held in the ROM should be generic (work alongside with multiple CPU types or ISAs). In addition, I saw mentioned on the web that it is possible to dump its code (and to "disassemble" it).

So, in which language, instruction set or machine code is it written? Doesn't it need any kind of processor to perform its operations? If so, I guess that it will use the external CPU, then how does it know the specific instruction set of the employed one?

Maybe it has an internal processor?

Answer 1

BIOSes used to be written exclusively in assembly language, but the transition was made a long time ago to write the majority of the code in some higher level language, and leave written in assembly as few portions of it as possible, preferably only the bootstrapper, (the very first few hundreds of instructions that the CPU jumps to after a start / reset,) and whatever routines deal with specific quirks of the underlying architecture.

BIOSes were already being written primarily in C as early as the early nineties. (I wrote a BIOS in 90% C, 10% assembly in the early nineties.)

What has also helped greatly in this direction is:

• C libraries that target a specific architecture and include functions for dealing with peculiarities of that architecture, for example, functions for reading/writing bytes to/from I/O ports of the x86 architecture. Microsoft C has always offered library functions for that kind of stuff.

• C compilers that not only target a specific CPU architecture but even offer extensions to the C language that you can use in order to write code which makes use of special CPU features. For example, the x86 architecture supports things known as interrupts, which invoke routines known as interrupt handlers, and it requires them to have special entry/exit instruction sequences. From the very early days, Microsoft C supported special keywords that you could use to mark a function as an interrupt handler, so it could be invoked directly by a CPU interrupt, so you did not have to write any assembly for it.

Nowadays I would assume that most of the BIOS is written in C++, if not in any higher level language.

The vast majority of the code that makes up a BIOS is specific to the underlying hardware, so it does not really need to be portable: it is guaranteed that it will always run on the same type of CPU. The CPU may evolve, but as long as it maintains backwards compatibility with previous versions, it can still run the BIOS unmodified. Plus, you can always recompile the parts of the BIOS written in C to run natively on any new CPU that comes up, if the need arises.

The reason why we write BIOSes in languages of a higher level than assembly is because it is easier to write them this way, not because they really need to be portable.

Answer 2

While in theory one can write BIOS in any language, the modern reality is most BIOS is written using Assembly, C, or a combination of the two.

BIOS must be written in a language that can compile to machine code, that is understood by the physical hardware-machine. This eliminates the directly or intermediate-ly interpreted languages (Perl, Python, PHP, Ruby, Java, C#, JavaScript, etc) as being appropriate for writing BIOS. (Though, in theory, one could implement one of these languages to either compile directly to static machine code or one could somehow embed the interpreter in BIOS. There is, for-example, the abandonware GCJ project for Java.)

Most OEMs implement a BIOS by extending proprietary, generic BIOS implementations by companies like American Megatrends and Phoenix Techologies. (You've probably seen one of those companies displayed on the first boot screen of a computer before.) The source code for these implementations is not publicly available, but some of it has been leaked. I do not want to link to this directly to the C and assembly source code, but there are places on the Internet where this source code is discussed for those who care to peek.

Some hardware manufacturers, like those targeting the high-performance and gaming markets, saturate their BIOS implementations with customization features, statistics, and attractive user interfaces designed for their exact implementations. Many of these features go beyond what is offered in the generic products produced by American Megatrends and others. Unfortunately, these companies often see the release of their source code as a security risk, so little is known about these high-end implementations because little is shared about them. One could of course find ways to access and de-compile such BIOS implementations but doing so may be difficult and possibly illegal.

Going back to the original question, because of the need to produce native machine code, a BIOS would have to be implemented in a programming language supported by a native machine code compiler. While there are many such languages and while I'm sure over the last few decades, several languages have been used in experimentation, every open BIOS implementation I have been able to find specifically relies on a combination of C and/or assembly. The open-sourced BIOS implementations I looked at to form this conclusion include OpenBIOS, tinyBIOS, coreboot, Intel BIOS, and Libreboot. I also looked at some very old BIOS implementations that are not relevant today but also followed the C and/or assembly rule.

I think it's also relevant to look at other software built to interact directly with hardware. We know, for example, that the Linux Kernel, the OS X kernel, and the Windows kernel are largely C with some assembly and some higher level languages for specific tasks. We also know that hardware drivers on Linux and hardware drivers on Windows are written largely in C.

Getting back to BIOS, I think it's also important to consider the economics of the programming language chosen. BIOS is generally written as a necessity to complement hardware sales. Modern BIOS systems are known to be largely written in C and/or assembly. A move to some other tool would add significant costs to what are generally considered to be commodity products which could very adversely affect sales. Without getting into Economics 101, I can assure you that it's probably not worth it to an OEM to deviate from tried-and-true tools that have been proven over decades.

Of course there are and will be hobbyist projects to write BIOS as well. These too, thus far, seem to be choosing C and/or assembly. Perhaps one day other technologies will be used. But today, the choice of is well-defined.

Answer 3

The actual BIOS for a computer would be written in some language (probably C or assembly) that is compiled to architecture dependent binary code; this code can't run on any other architecture (and arguably doesn't really need to, as it is already very specific to the machine with which it is shipped).

But are you possibly thinking about Option ROMs (which are sometimes called BIOSes, as in "Video BIOS" for a GPU option ROM)?

For actual, legacy BIOS compatible option ROMs, they would probably be ISA dependent executable code (again generated by any language that can be compiled to target the desired architecture); PCI also allows including code for multiple ISAs and allows the host to select the appropriate binary image during the boot process.

For UEFI compatible option ROMs, there is also an architecture-independent byte code format that can be run on different architectures, but ISA-dependent code can also still be used.