Según tengo entendido, el código / flujo de bits del BIOS que se encuentra en la ROM debe ser genérico (trabajar junto con varios tipos de CPU o ISA). Además, vi mencionado en la web que es posible volcar su código (y «desensamblarlo»).
Entonces, ¿en qué idioma, conjunto de instrucciones o código de máquina está escrito? ¿No necesita algún tipo de procesador para realizar sus operaciones? Si es así, supongo que usará la CPU externa, entonces, ¿cómo conoce el conjunto de instrucciones específico de la empleada?
Tal vez tiene un procesador interno?
Comentarios
Respuesta
Las BIOS solían estar escritas exclusivamente en lenguaje ensamblador, pero el La transición se hizo hace mucho tiempo para escribir la mayor parte del código en algún lenguaje de nivel superior y dejar escrito en ensamblador la menor cantidad posible de partes, preferiblemente solo el bootstrapper (los primeros cientos de instrucciones que la CPU salta después de un inicio / reinicio) y cualquier rutina que se ocupe de las 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% en ensamblado a principios de los noventa).
Lo que también ha ayudado mucho en esta dirección es:
-
C bibliotecas 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 hacia / 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 apuntan a una arquitectura de CPU específica, sino que incluso ofrecen extensiones al lenguaje C que puede usar en para escribir código que hace uso de características especiales de la CPU. Por ejemplo, la arquitectura x86 admite elementos conocidos como interrupciones, que invocan rutinas conocidas como controladores 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 un 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 asumiría 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 compone un BIOS es específico para el hardware subyacente, por lo que realmente no necesita ser portátil: se garantiza que siempre se ejecutará en el mismo tipo de CPU. La CPU puede evolucionar, pero siempre que mantenga la compatibilidad con versiones anteriores, aún puede ejecutar el BIOS sin modificaciones. Además, siempre puede volver a compilar 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 lenguajes de un nivel superior a ensamblado se debe a que es más fácil escribirlos de esta manera, no porque realmente necesiten ser portátiles.
Comentarios
- Sí. A veces, incluso puede tener una placa base vinculada no solo a una arquitectura de CPU específica, sino incluso a un proveedor de CPU específico. Hoy en día puede comprar una placa base x86 que solo es compatible con las CPU Intel x86, o una placa base x86 que solo es compatible con las CPU AMD x86. El BIOS en estas placas base será idéntico en gran medida, porque en ambos casos la CPU comprende el conjunto de instrucciones x86, y la mayoría de los periféricos son idénticos, pero algunos periféricos tienen diferencias, que el BIOS debe tener en cuenta.
- @Reflection observe de cerca cómo se ve físicamente una placa base. El zócalo de la CPU tendrá una determinada disposición de pines, que es específica de la familia de CPU que acepta.No se puede conectar físicamente, por ejemplo, un Intel P4 a una placa base AMD Opteron
- El término » BIOS » se refiere al » Sistema básico de entrada / salida » de una PC, por lo tanto, tener un BIOS implica una CPU x86. Los sistemas IA64 tienen un EFI en lugar de un BIOS, los sistemas PowerPC pueden tener un sistema Open Firmware o uno propietario, los sistemas Sparc también tienen OFW (o más bien OpenBoot), el OLPC X0 es un sistema basado en x86 que usa OFW. Incluso las PC ya no ‘ usan BIOS, han cambiado a (U) EFI. OB / OFW es interesante, porque está diseñado no solo para ser portátil sino multiplataforma. Los controladores OFW funcionarán en cualquier sistema OFW, son » Write Once Run Anywhere «, independientemente de la CPU ISA.
- » Hoy en día supongo que la mayor parte del BIOS está escrito en C ++ » Yo no ‘ No necesariamente asumo eso, Puede ser cierto, pero trabajo en esa industria y ciertamente muchos cargadores de arranque están escritos en C simple. Las personas que escriben ese tipo de cosas son a menudo » Old Guard » y tienden a no confiar plenamente en C ++ todavía.
- @TomDworzanski: aunque técnicamente no es BIOS (que se refiere exclusivamente a la antigua PC de 1981), muchas implementaciones de IEEE-1275 Open Firmware (que se usa para un papel similar al BIOS en Sparc, la plataforma de referencia de hardware común PowerPC (por ejemplo, PowerMac, PowerBook), la computadora portátil OLPC X0 de 100 $ -1) están escritos en parte en lenguajes distintos de ensamblador / C. OpenBoot , Open Firmware , OpenBIOS todos contienen…
Respuesta
Mientras que en teoría uno puede escribir BIOS en cualquier idioma, el La realidad moderna es que la mayoría de BIOS se escribe usando Ensamblador, C o una combinación de los dos .
El BIOS debe estar escrito en un lenguaje que pueda compilarse en código de máquina , que sea entendido por la máquina física de hardware. Esto elimina los lenguajes interpretados de forma directa o intermedia (Perl, Python, PHP, Ruby, Java, C #, JavaScript, etc.) como apropiados para escribir BIOS. (Aunque, en teoría, se podría implementar uno de estos lenguajes para compilar directamente en código de máquina estático o se podría incrustar de alguna manera el intérprete en BIOS. Por ejemplo, existe el abandonware GCJ project para Java.)
La mayoría de los OEM implementan un BIOS al extender las implementaciones de BIOS genéricas y patentadas de compañías como American Megatrends y Phoenix Techologies . (Probablemente haya visto antes una de esas empresas en la primera pantalla de inicio de una computadora). El código fuente de estas implementaciones no está disponible públicamente, pero parte de él se ha filtrado. No quiero vincularlo directamente al código fuente C y ensamblador, pero hay lugares en Internet donde se discute este código fuente para aquellos que quieran echar un vistazo.
Algunos fabricantes de hardware, como los que se dirigen a los mercados de juegos y de alto rendimiento, saturan sus implementaciones de BIOS con funciones de personalización, estadísticas e interfaces de usuario atractivas diseñadas para sus implementaciones exactas. Muchas de estas funciones van más allá de lo que se ofrece en los productos genéricos producidos. por American Megatrends y otros. Lamentablemente, estas empresas a menudo ven la publicación de su código fuente como un riesgo de seguridad , por lo que se sabe poco sobre estas implementaciones de alta gama porque poco se comparte sobre ellos. Uno puede Por supuesto, encontrar formas de acceder y descompilar tales 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 de máquina nativo, un BIOS tendría que implementarse en un lenguaje de programación compatible con un compilador de código de máquina nativo . Si bien existen muchos lenguajes de este tipo y aunque estoy seguro de que durante 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 ensamblado. -Las implementaciones de BIOS con fuente que miré para formar esta conclusión incluyen OpenBIOS , tinyBIOS , coreboot , BIOS Intel y Libreboot . También miré algunas implementaciones de BIOS muy antiguas que no son relevantes hoy en día, pero que también seguían 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 Linux Kernel , el OS X Kernel y el kernel de Windows son en gran parte C con algunos ensamblajes 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 a BIOS, creo que también es importante considerar la economía del lenguaje de programación elegido. BIOS generalmente se escribe como una necesidad para complementar las ventas de hardware. Se sabe que los sistemas BIOS modernos son en gran parte escrito en C y / o ensamblado. Un cambio a otra herramienta agregaría costos significativos a lo que generalmente se considera productos básicos que podrían afectar negativamente las ventas. Sin entrar en Economía 101, puedo asegurarle que probablemente no Vale la pena para un OEM desviarse de las herramientas probadas y verdaderas que han sido probadas durante décadas.
Por supuesto que 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 utilicen otras tecnologías. Pero hoy, la elección de está bien definida.
Comentarios
- Es un poco quisquilloso, pero C # y Java no se interpretan . Se compilan en código de bytes. Es el código de bytes que luego es manejado por un intérprete. No ‘ no cambia la lógica del primer párrafo.
- @Tonny Eso ‘ es correcto. Agregué » directa o intermediamente interpretado » para ser un poco más claro.
- @Tonny normalmente un jitter en lugar de un intérprete, que es una distinción importante porque ‘ s posible pre-jit todo a nativo siempre que ciertas técnicas dinámicas no sean ‘ t utilizado. Como tal, sería casi teóricamente posible escribir un BIOS en lenguajes .NET o Java, si uno hiciera ambas cosas y se asegurara de que todo el soporte de tiempo de ejecución necesario estuviera disponible. Sin embargo, imagino que los esfuerzos de hacer eso empequeñecerían con creces cualquier conveniencia encontrada.
- @Tonny En realidad, C # compila en código nativo msdn.microsoft.com/en -us / vstudio / dotnetnative.aspx por lo que es ‘ raro verlo en la lista de lenguajes débiles / dinámicos.
- @Den C # normalmente no se compila en código nativo. Este producto nativo de .Net al que se vincula aún no se ha lanzado oficialmente. De lo que ‘ he leído, compilará el código de la aplicación y el código de marco requerido en un ejecutable. De acuerdo con las preguntas frecuentes, esto estará dirigido inicialmente a las aplicaciones de la Tienda Windows, por lo que puede llevar algún tiempo para que sea compatible de manera más amplia. Dicho todo esto, parece que Microsoft podría alejarse del modelo de máquina virtual en algún momento en el futuro si todo va bien.
Responder
El BIOS real de una computadora estaría escrito en algún lenguaje (probablemente C o ensamblador) que se compila en código binario dependiente de la arquitectura; este código no puede ejecutarse en ninguna otra arquitectura (y posiblemente no es necesario, ya que es muy específico de la máquina con la que se envía).
Pero, ¿posiblemente está pensando en Option ROMs (que a veces se denominan BIOS, como en «Video BIOS» para una opción ROM de GPU)?
Para compatibilidad con BIOS heredada real ROM de opción, probablemente serían código ejecutable dependiente de ISA (nuevamente generado por cualquier lenguaje que pueda ser compilado para apuntar a la arquitectura deseada); PCI también permite incluir código para múltiples ISA y permite al host seleccionar la imagen binaria adecuada durante el proceso de arranque.
Para la opción compatible con UEFI ROM, 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 código dependiente de ISA.
As I understand, the BIOS code/bitstream that is held in the ROM should be generic (work alongside with multiple CPU types or ISAs).
Yo ‘ diría » No, todo lo contrario »