Bare machine

For a given application, in most of the cases, a bare-metal implementation will run faster, using less memory and so being more power efficient. This is because operating systems, as any program, need some execution time and memory space to run, and these are no longer needed on bare-metal. For instance, any hardware feature that includes inputs and outputs are directly accessible on bare-metal, whereas the same feature using an OS must route the call to a subroutine, consuming running time and memory.[1]

For a given application, bare-metal programming requires more effort to work properly and is more complex because the services provided by the operating system and used by the application have to be re-implemented regarding the needs. These services can be:

• System boot (mandatory)
• Memory management: Storing location of the code and the data regarding the hardware resources and peripherals (mandatory)
• Interruptions handling (if any)
• Task scheduling, if the application can perform more than one task
• Peripherals management (if any)
• Error management, if wanted or needed

Debugging a bare-metal program is difficult since:

• There are no software error notifications nor faults management, unless they have been implemented and validated.
• There is no standard output, unless it has been implemented and validated.
• The machine where the program is written cannot be the same where the program is executed, so the target hardware is either an emulator / simulator or an external device. This forces to setup a way to load the bare-metal program onto the target (flashing), start the program execution and access the target resources.

Bare-metal programming is generally done using a close-to-hardware language, such as Rust, C++, C, assembly language, or even for small amounts of code or very new processors machine code directly.[2] All the previous issues inevitably mean that bare-metal programs are very rarely portable.

The approach of using bare machines paved the way for new ideas which accelerated the evolution of operating system development.

This approach highlighted a need for the following:

• Input/output (I/O) devices to enter both code and data conveniently:
  • Input devices, such as keyboards, were created. These were necessary, as earlier computers often had unique, obtuse, and convoluted input devices.

For example, programs were loaded into the PDP-11 by hand, using a series of toggle switches on the front panel of the device. Keyboards are far superior to these vintage input devices, as it would be much faster to type code or data than to use toggle switches to input this into the machine. Keyboards would later become standard across almost every computer, regardless of brand or price.

• Output devices such as computer monitors would later be widely used, and still are to this day. They proved themselves to be a huge convenience over earlier output devices, such as an array of lights on the Altair 8800, which would indicate the status of the computer.

Computer monitors can also easily display the output of a program in a user friendly manner. For example, one would have to be intimately knowledgeable about a specific early computer and its display system, consisting of an array of lights, to even begin to make sense of the status of the computer's hardware. In contrast, anybody who can read should be able to understand a well-designed user interface on a modern system, without having to know anything about the hardware of the computer on which the program is being run.

• Faster, cheaper, more widely available secondary storage devices to store programs to non-volatile memory. This was needed, as it was cumbersome to have to type code in by hand in order to use the computer in a useful way, which would be lost upon every reboot due to the system saving it to volatile memory.
• The requirement for a convenient high-level language and a translator for such a high-level language to the corresponding machine code.
• Linkers to link library modules, which may be written by the user or already available on the system.
• Loaders to load executables into RAM from the secondary storage.
• Suitable I/O devices, such as printers for producing a hard copy of the output generated by programs.

• Bare machine computing
• Barebone computer
• Standalone program

• Silberschatz, A.; Galvin, Peter; Gagne, Greg (2003). Operating System Concepts. ISBN 9780471250609.