Quale linguaggio di programmazione viene utilizzato per scrivere un programma BIOS?

A quanto ho capito, il codice BIOS / bitstream che si trova nella ROM dovrebbe essere generico (lavorare insieme a più tipi di CPU o ISA). Inoltre, ho visto menzionato sul web che è possibile scaricare il suo codice (e "smontarlo").

Quindi, in quale lingua, set di istruzioni o codice macchina è scritto? Non ha bisogno di alcun tipo di processore per eseguire le sue operazioni? In tal caso, suppongo che utilizzerà la CPU esterna, quindi come fa a conoscere il set di istruzioni specifico di quella utilizzata?

Forse ha un processore interno?

I BIOS erano scritti esclusivamente in linguaggio assembly, ma la transizione è stata fatta molto tempo fa per scrivere la maggior parte del codice in un linguaggio di livello superiore e lasciare scritti nell'assemblaggio il minor numero possibile di parti, preferibilmente solo il bootstrapper, (le prime centinaia di istruzioni a cui la CPU passa dopo un avvio / ripristino) e qualsiasi routine si occupi di stranezze specifiche dell'architettura sottostante.

I BIOS erano già stati scritti principalmente in C già nei primi anni novanta. (Ho scritto un BIOS in 90% C, 10% assembly nei primi anni novanta.)

Ciò che ha anche aiutato molto in questa direzione è:

• Librerie C che hanno come target un'architettura specifica e includono funzioni per gestire le peculiarità di quell'architettura, ad esempio funzioni per leggere / scrivere byte su / da porte I / O dell'architettura x86. Microsoft C ha sempre offerto funzioni di libreria per quel tipo di cose.

• Compilatori C che non solo mirano a una specifica architettura della CPU ma offrono anche estensioni al linguaggio C che è possibile utilizzare per scrivere codice che utilizza funzioni CPU speciali. Ad esempio, l'architettura x86 supporta cose note come interrupt, che invocano routine note come gestori di interrupt e richiede loro di avere sequenze di istruzioni di entrata / uscita speciali. Sin dai primissimi tempi, Microsoft C supportava parole chiave speciali che potevi usare per contrassegnare una funzione come gestore di interrupt, in modo che potesse essere invocato direttamente da un interrupt della CPU, quindi non dovevi scrivere alcun assembly per esso.

Oggi suppongo che la maggior parte del BIOS sia scritta in C ++, se non in un linguaggio di livello superiore.

La stragrande maggioranza del codice che costituisce un BIOS è specifica dell'hardware sottostante, quindi non ha davvero bisogno di essere portatile: è garantito che funzionerà sempre sullo stesso tipo di CPU. La CPU può evolversi, ma purché mantenga la compatibilità con le versioni precedenti, può comunque eseguire il BIOS senza modifiche. Inoltre, puoi sempre ricompilare le parti del BIOS scritte in C per eseguire in modo nativo su qualsiasi nuova CPU che si presenta, se necessario.

Il motivo per cui scriviamo BIOS in lingue di livello superiore rispetto all'assembly è perché è più facile scriverli in questo modo, non perché hanno davvero bisogno di essere portatili.

Mentre in teoria si può scrivere BIOS in qualsiasi lingua, la realtà moderna è che la maggior parte del BIOS è scritta usando Assembly, C o una combinazione dei due .

Il BIOS deve essere scritto in un linguaggio che può essere compilato in base al codice macchina , compreso dall'hardware fisico della macchina. Ciò elimina i linguaggi interpretati direttamente o intermedi (Perl, Python, PHP, Ruby, Java, C #, JavaScript, ecc.) Come appropriato per la scrittura del BIOS. (Sebbene, in teoria, si potrebbe implementare uno di questi linguaggi per compilare direttamente in codice macchina statico o si potrebbe in qualche modo incorporare l'interprete nel BIOS. Esiste, ad esempio, il progetto GCJ diandonware per Java.)

La maggior parte degli OEM implementa un BIOS estendendo implementazioni di BIOS generiche proprietarie da aziende come American Megatrends e Phoenix Techologies . (Probabilmente hai già visto una di quelle aziende mostrate nella prima schermata di avvio di un computer in precedenza.) Il codice sorgente di queste implementazioni non è pubblicamente disponibile, ma alcune di esse sono trapelate. Non voglio collegarmi direttamente a questo al codice sorgente C e assembly, ma ci sono posti su Internet in cui questo codice sorgente viene discusso per coloro che vogliono dare un'occhiata.

Alcuni produttori di hardware, come quelli destinati ai mercati ad alte prestazioni e di gioco, saturano le loro implementazioni BIOS con funzionalità di personalizzazione, statistiche e interfacce utente accattivanti progettate per le loro esatte implementazioni. Molte di queste caratteristiche vanno oltre ciò che viene offerto nei prodotti generici prodotti da American Megatrends e altri. Sfortunatamente, queste aziende vedono spesso il rilascio del loro codice sorgente come un rischio per la sicurezza , quindi si sa poco su queste implementazioni di fascia alta perché poco è condiviso su di loro. Naturalmente si potrebbero trovare modi per accedere e decompilare tali implementazioni del BIOS, ma ciò potrebbe essere difficile e forse illegale.

Tornando alla domanda originale, a causa della necessità di produrre codice macchina nativo, un BIOS dovrebbe essere implementato in un linguaggio di programmazione supportato da un compilatore di codice macchina nativo . Mentre ci sono molti linguaggi di questo tipo e mentre sono sicuro negli ultimi decenni, sono state usate diverse lingue nella sperimentazione, ogni implementazione di BIOS aperta che sono stato in grado di trovare si basa specificamente su una combinazione di C e / o assembly. Le implementazioni del BIOS open source che ho esaminato per formare questa conclusione includono OpenBIOS , tinyBIOS , coreboot , Intel BIOS e Libreboot. Ho anche esaminato alcune implementazioni BIOS molto vecchie che non sono rilevanti oggi, ma hanno anche seguito la regola C e / o assembly.

Penso che sia anche importante guardare altri software creati per interagire direttamente con l'hardware. Sappiamo, ad esempio, che il kernel Linux , il kernel OS X e il kernel Windows sono in gran parte C con alcuni assembly e alcuni linguaggi di livello superiore per compiti specifici. Sappiamo anche che i driver hardware su Linux e i driver hardware su Windows sono scritti in gran parte in C.

Tornando al BIOS, penso che sia anche importante considerare l'economia del linguaggio di programmazione scelto. Il BIOS è generalmente scritto come una necessità per integrare le vendite di hardware. I moderni sistemi BIOS sono noti per essere in gran parte scritti in C e / o assembly. Il passaggio ad altri strumenti aggiungerebbe costi significativi a quelli che sono generalmente considerati prodotti di base che potrebbero influire negativamente sulle vendite. Senza entrare in Economics 101, posso assicurarvi che probabilmente non vale la pena per un OEM discostarsi da strumenti collaudati che sono stati dimostrati nel corso di decenni.

Ovviamente ci sono e ci saranno progetti per hobby anche per scrivere BIOS. Anche questi, finora, sembrano scegliere C e / o assembly. Forse un giorno verranno utilizzate altre tecnologie. Ma oggi, la scelta di è ben definita.

Il BIOS effettivo per un computer verrebbe scritto in un linguaggio (probabilmente C o assembly) compilato in codice binario dipendente dall'architettura; questo codice non può essere eseguito su nessun'altra architettura (e probabilmente non è proprio necessario, in quanto è già molto specifico per la macchina con cui viene spedito).

Ma stai forse pensando alle ROM opzionali (che a volte vengono chiamate BIOS, come in "BIOS video" per una ROM opzionale GPU)?

Per le ROM opzionali effettivamente compatibili con BIOS legacy, sarebbero probabilmente codice eseguibile dipendente da ISA (nuovamente generato da qualsiasi linguaggio che può essere compilato per indirizzare l'architettura desiderata); PCI consente inoltre di includere codice per più ISA e consente all'host di selezionare l'immagine binaria appropriata durante il processo di avvio.

Per le ROM opzionali compatibili UEFI, esiste anche un formato di codice byte indipendente dall'architettura che può essere eseguito su architetture diverse, ma è comunque possibile utilizzare anche codice dipendente da ISA.