¿Qué lenguaje de programación se usa para escribir un programa de BIOS?

Según tengo entendido, el código de BIOS / flujo de bits que se encuentra en la ROM debe ser genérico (funciona junto con múltiples tipos de CPU o ISA). Además, vi mencionado en la web que es posible volcar su código (y "desarmarlo").

Entonces, ¿en qué idioma, conjunto de instrucciones o código de máquina está escrito? ¿No necesita ningún tipo de procesador para realizar sus operaciones? Si es así, supongo que usará la CPU externa, entonces, ¿cómo sabe el conjunto de instrucciones específicas de la empleada?

Tal vez tiene un procesador interno?

Los BIOS solían escribirse exclusivamente en lenguaje ensamblador, pero la transición se realizó hace mucho tiempo para escribir la mayoría del código en un lenguaje de nivel superior y dejarlo escrito en ensamblado con la menor cantidad de partes posible, preferiblemente solo el programa de arranque, (los primeros cientos de instrucciones a las que salta la CPU después de un inicio / reinicio) y cualquier rutina que trate con peculiaridades específicas de la arquitectura subyacente.

Las BIOS ya se escribían principalmente en C a principios de los noventa. (Escribí un BIOS en 90% C, 10% de ensamblaje a principios de los noventa).

Lo que también ha ayudado mucho en esta dirección es:

• Las bibliotecas C que se dirigen a una arquitectura específica e incluyen funciones para tratar las peculiaridades de esa arquitectura, por ejemplo, funciones para leer / escribir bytes a / desde puertos de E / S de la arquitectura x86. Microsoft C siempre ha ofrecido funciones de biblioteca para ese tipo de cosas.

• Los compiladores de C que no solo se dirigen a una arquitectura de CPU específica, sino que incluso ofrecen extensiones al lenguaje C que puede usar para escribir código que hace uso de características especiales de la CPU. Por ejemplo, la arquitectura x86 admite cosas conocidas como interrupciones, que invocan rutinas conocidas como manejadores de interrupciones, y requiere que tengan secuencias especiales de instrucciones de entrada / salida. Desde los primeros días, Microsoft C admitía palabras clave especiales que podía usar para marcar una función como controlador de interrupciones, por lo que podía ser invocada directamente por una interrupción de la CPU, por lo que no tenía que escribir ningún ensamblado para ella.

Hoy en día supongo que la mayor parte del BIOS está escrito en C ++, si no en un lenguaje de nivel superior.

La gran mayoría del código que forma un BIOS es específico del hardware subyacente, por lo que no necesita ser portátil: se garantiza que siempre se ejecutará en el mismo tipo de CPU. La CPU puede evolucionar, pero mientras mantenga la compatibilidad con versiones anteriores, aún puede ejecutar el BIOS sin modificaciones. Además, siempre puede recompilar las partes del BIOS escritas en C para que se ejecuten de forma nativa en cualquier CPU nueva que surja, si surge la necesidad.

La razón por la que escribimos BIOS en idiomas de un nivel superior al ensamblado es porque es más fácil escribirlos de esta manera, no porque realmente necesiten ser portátiles.

Si bien, en teoría, se puede escribir BIOS en cualquier lenguaje, la realidad moderna es que la mayoría de los BIOS se escriben usando ensamblado, C o una combinación de ambos .

El BIOS debe estar escrito en un lenguaje que pueda compilar el código de la máquina , que es entendido por la máquina física del hardware. Esto elimina los lenguajes interpretados directa o intermediamente (Perl, Python, PHP, Ruby, Java, C #, JavaScript, etc.) como apropiados para escribir BIOS. (Aunque, en teoría, uno podría implementar uno de estos lenguajes para compilar directamente en código de máquina estático o podría incrustar de alguna manera el intérprete en BIOS. Existe, por ejemplo, el proyecto abandonware GCJ para Java).

La mayoría de los OEM implementan un BIOS extendiendo implementaciones de BIOS genéricas y patentadas por compañías como American Megatrends y Phoenix Techologies . (Probablemente ya haya visto una de esas compañías en la primera pantalla de arranque de una computadora). El código fuente de estas implementaciones no está disponible públicamente, pero parte de él se ha filtrado. No quiero vincular esto directamente con el código fuente de C y ensamblado, pero hay lugares en Internet donde se discute este código fuente para aquellos que desean echar un vistazo.

Algunos fabricantes de hardware, como los que se dirigen a los mercados de alto rendimiento y juegos, saturan sus implementaciones de BIOS con características de personalización, estadísticas e interfaces de usuario atractivas diseñadas para sus implementaciones exactas. Muchas de estas características van más allá de lo que se ofrece en los productos genéricos producidos por American Megatrends y otros. Desafortunadamente, estas compañías a menudo ven el lanzamiento de su código fuente como un riesgo de seguridad , por lo que se sabe muy poco acerca de estas implementaciones de gama alta porque se comparte poco sobre ellas. Por supuesto, uno podría encontrar formas de acceder y descompilar dichas implementaciones de BIOS, pero hacerlo puede ser difícil y posiblemente ilegal.

Volviendo a la pregunta original, debido a la necesidad de producir código máquina nativo, un BIOS tendría que implementarse en un lenguaje de programación compatible con un compilador de código máquina nativo . Si bien existen muchos lenguajes de este tipo y, aunque estoy seguro de que en las últimas décadas, se han utilizado varios lenguajes en la experimentación, cada implementación de BIOS abierta que he podido encontrar se basa específicamente en una combinación de C y / o ensamblaje. Las implementaciones de BIOS de código abierto que miré para llegar a esta conclusión incluyen OpenBIOS , tinyBIOS , coreboot , Intel BIOS y Libreboot. También miré algunas implementaciones de BIOS muy antiguas que no son relevantes hoy en día, pero también seguí la regla C y / o de ensamblaje.

Creo que también es relevante mirar otro software creado para interactuar directamente con el hardware. Sabemos, por ejemplo, que el kernel de Linux , el kernel de OS X y el kernel de Windows son principalmente C con algunos ensamblados y algunos lenguajes de nivel superior para tareas específicas. También sabemos que los controladores de hardware en Linux y los controladores de hardware en Windows están escritos principalmente en C.

Volviendo al BIOS, creo que también es importante tener en cuenta la economía del lenguaje de programación elegido. El BIOS generalmente se escribe como una necesidad para complementar las ventas de hardware. Se sabe que los sistemas BIOS modernos se escriben principalmente en C y / o ensamblado. Un cambio a otra herramienta agregaría costos significativos a lo que generalmente se consideran productos básicos que podrían afectar negativamente las ventas. Sin entrar en Economía 101, puedo asegurarle que probablemente no valga la pena que un OEM se desvíe de las herramientas probadas y verdaderas que se han demostrado durante décadas.

Por supuesto, hay y habrá proyectos de aficionados para escribir BIOS también. Estos también, hasta ahora, parecen estar eligiendo C y / o ensamblaje. Quizás algún día se utilizarán otras tecnologías. Pero hoy, la elección de está bien definida.

El BIOS real para una computadora se escribiría en algún lenguaje (probablemente C o ensamblado) que se compila en código binario dependiente de la arquitectura; este código no puede ejecutarse en ninguna otra arquitectura (y posiblemente no sea necesario, ya que es muy específico para la máquina con la que se envía).

¿Pero posiblemente está pensando en las ROM de opción (que a veces se llaman BIOS, como en "Video BIOS" para una ROM de opción de GPU)?

Para las ROM opcionales compatibles con BIOS heredadas, probablemente serían código ejecutable dependiente de ISA (nuevamente generado por cualquier lenguaje que pueda compilarse para apuntar a la arquitectura deseada); PCI también permite incluir código para múltiples ISA y permite que el host seleccione la imagen binaria apropiada durante el proceso de arranque.

Para las ROM opcionales compatibles con UEFI, también hay un formato de código de bytes independiente de la arquitectura que se puede ejecutar en diferentes arquitecturas, pero también se puede usar el código dependiente de ISA.