Ce limbaj de programare este folosit pentru a scrie un program BIOS?

BIOS-urile erau scrise exclusiv în limbajul asamblării, dar tranziția a fost făcută cu mult timp în urmă pentru a scrie majoritatea codului într-un limbaj de nivel superior și pentru a lăsa scris în asamblare cât mai puține porțiuni din acesta, de preferință doar bootstrapper (primele câteva sute de instrucțiuni pe care CPU le sare) până după o pornire / resetare) și orice rutine se ocupă de ciudățenii specifice arhitecturii subiacente.

BIOS-urile erau deja scrise în principal în C încă de la începutul anilor nouăzeci. (Am scris un BIOS în 90% C, 10% asamblare la începutul anilor nouăzeci.)

Ceea ce a ajutat foarte mult și în această direcție este:

• C biblioteci care vizează o arhitectură specifică și includ funcții pentru tratarea particularităților acelei arhitecturi, de exemplu, funcții pentru citirea / scrierea octeților în / din porturile I / O ale arhitecturii x86. Microsoft C a oferit întotdeauna funcții de bibliotecă pentru astfel de lucruri.

• Compilatoarele C care nu vizează doar o anumită arhitectură CPU, ci oferă chiar și extensii pentru limbajul C în care puteți utiliza pentru a scrie cod care utilizează caracteristici speciale ale procesorului. De exemplu, arhitectura x86 acceptă lucruri cunoscute sub numele de întreruperi, care invocă rutine cunoscute sub numele de manipulatoare de întreruperi și le cere să aibă secvențe speciale de instrucțiuni de intrare / ieșire. Încă din primele zile, Microsoft C a acceptat cuvinte cheie speciale pe care le-ați putea folosi pentru a marca o funcție ca un handler de întrerupere, deci ar putea fi invocată direct de o întrerupere a procesorului, deci nu a trebuit să scrieți niciun ansamblu pentru aceasta.

În zilele noastre aș presupune că majoritatea BIOS-ului este scris în C ++, dacă nu într-un limbaj de nivel superior.

Marea majoritate a codului care alcătuiește un BIOS este specific hardware-ului de bază, deci nu trebuie să fie portabil: este garantat că va rula întotdeauna pe același tip de CPU. CPU-ul poate evolua, dar atâta timp cât menține compatibilitatea cu versiunile anterioare, poate rula BIOS-ul nemodificat. În plus, puteți oricând recompila părțile BIOS-ului scrise în C pentru a rula nativ pe orice procesor nou care apare, dacă apare nevoia.

Motivul pentru care scriem BIOS-urile în limbi de un nivel superior asamblarea se datorează faptului că este mai ușor să le scrieți în acest fel, nu pentru că într-adevăr trebuie să fie portabile.

Comentarii

• Da. Uneori este posibil să aveți chiar și o placă de bază legată nu numai de o anumită arhitectură CPU, ci chiar de un anumit furnizor de CPU. În prezent, puteți cumpăra o placă de bază x86 care este compatibilă numai cu procesoarele Intel x86 sau o placă de bază x86 care este compatibilă numai cu procesoarele AMD x86. BIOS-ul din aceste plăci de bază va fi identic într-o mare măsură, deoarece în ambele cazuri procesorul înțelege setul de instrucțiuni x86, iar majoritatea perifericelor sunt identice, dar unele periferice au diferențe, pe care BIOS-ul trebuie să le ia în considerare.
• @Reflection aruncă o privire atentă asupra aspectului fizic al unei plăci de bază. Soclul CPU va avea un anumit aranjament pin, care este specific familiei de CPU pe care le acceptă.Nu vă puteți conecta fizic, spuneți un Intel P4 la o placă de bază AMD Opteron
• Termenul ” BIOS ” se referă la ” Sistem de intrare / ieșire de bază ” al unui PC, deci, a avea un BIOS implică un procesor x86. Sistemele IA64 au un EFI în loc de un BIOS, sistemele PowerPC pot avea un sistem Open Firmware sau unul proprietar, sistemele Sparc au și OFW (sau mai degrabă OpenBoot), OLPC X0 este un sistem bazat pe x86 care folosește OFW. Chiar și computerele nu mai folosesc BIOS, au trecut la (U) EFI. OB / OFW este interesant, deoarece este proiectat să nu fie doar portabil, ci și pe mai multe platforme. Driverele OFW vor funcționa pe orice sistem OFW, sunt ” Write Once Run Anywhere „, indiferent de CPU ISA.
• ” În zilele noastre aș presupune că majoritatea BIOS-ului este scris în C ++ ” Nu aș ‘ nu presupun neapărat că, s-ar putea să fie adevărat, dar lucrez în acea industrie și cu siguranță multe încărcătoare de încărcare sunt scrise în simpla C. Oamenii care scriu acel gen de lucruri sunt adesea ” Old Guard ” și tind să nu aibă încredere deplină în C ++.
• @TomDworzanski: Deși tehnic nu este BIOS (care se referă exclusiv la vechile elemente de PC din 1981), multe implementări ale IEEE-1275 Open Firmware (care este folosit pentru un rol similar cu BIOS-ul pe Sparc, platforma de referință hardware comună PowerPC (de exemplu, PowerMac, PowerBook), laptopul OLPC X0 de 100 $ -1) sunt scrise parțial în alte limbi decât assembly / C. OpenBoot , Open Firmware , OpenBIOS toate conțin …

În timp ce în teorie se poate scrie BIOS în orice limbă, realitatea modernă este majoritatea BIOS-ului este scris folosind Assembly, C sau o combinație a celor două .

BIOS-ul trebuie scris într-un limbaj care poate fi compilat în codul mașinii , care este înțeles de mașina hardware fizică. Aceasta elimină limbajele interpretate direct sau intermediar (Perl, Python, PHP, Ruby, Java, C #, JavaScript etc.) ca fiind adecvate pentru scrierea BIOS-ului. (Deși, teoretic, s-ar putea implementa unul dintre aceste limbaje pentru a compila direct în codul mașinii statice sau s-ar putea încorpora cumva interpretul în BIOS. Există, de exemplu, abandonware GCJ project for Java.)

Majoritatea OEM-urilor implementează un BIOS extinzând implementări BIOS proprietare, generice, de companii precum American Megatrends și Phoenix Techologies . (Probabil că ați mai văzut una dintre acele companii afișate pe primul ecran de boot al unui computer.) Codul sursă pentru aceste implementări nu este disponibil public, dar unele dintre ele au fost dezvăluite. Nu vreau să fac legătura direct cu acest lucru la codul sursă C și asamblare, dar există locuri pe Internet unde se discută acest cod sursă pentru cei cărora le pasă să arunce o privire.

Unii producători de hardware, precum cei care vizează piețele de performanță și jocuri, își saturează implementările BIOS cu caracteristici de personalizare, statistici și interfețe de utilizator atractive concepute pentru implementările lor exacte. Multe dintre aceste caracteristici depășesc ceea ce este oferit în produsele generice produse de către American Megatrends și alții. Din păcate, aceste companii adesea văd lansarea codului sursă ca un risc de securitate , așa că se știe puțin despre aceste implementări high-end, deoarece puțin despre ele se împărtășește Desigur, găsesc modalități de a accesa și descompila astfel de implementări de BIOS, dar acest lucru poate fi dificil și posibil ilegal.

Revenind la întrebarea inițială, din cauza necesității de a produce codul mașinii native, un BIOS ar trebui să fie implementat în un limbaj de programare acceptat de un compilator nativ de cod de mașină . Deși există multe astfel de limbaje și, deși sunt sigur în ultimele decenii, mai multe limbi au fost utilizate în experimentare, fiecare implementare BIOS deschisă pe care am putut să o găsesc se bazează în mod specific pe o combinație de C și / sau asamblare. -implementările BIOS sursă la care m-am uitat pentru a forma această concluzie includ OpenBIOS , tinyBIOS , coreboot , BIOS Intel și Libreboot . De asemenea, m-am uitat la câteva implementări BIOS foarte vechi care nu sunt relevante astăzi, dar am respectat și regula C și / sau asamblarea.

Cred că este de asemenea relevant să analizăm alte programe create pentru interacționează direct cu hardware-ul.Știm, de exemplu, că Kernel Linux , kernel OS X și Kernel-ul Windows este în mare parte C, cu unele asamblări și unele limbaje de nivel superior pentru sarcini specifice. Știm, de asemenea, că driverele hardware pe Linux și driverele hardware pe Windows sunt scrise în mare parte în C .

Întorcându-ne la BIOS, cred că este de asemenea important să luăm în considerare economia limbajului de programare ales. BIOS este scris în general ca o necesitate pentru a completa vânzările de hardware. Sistemele moderne de BIOS sunt cunoscute ca fiind în mare parte scris în C și / sau asamblare. O mutare către un alt instrument ar adăuga costuri semnificative la ceea ce sunt considerate în general produse de marfă care ar putea afecta negativ vânzările. Fără a intra în Economics 101, vă pot asigura că probabil că nu merită pentru un OEM să se abată de la instrumentele încercate și adevărate care au fost dovedite de-a lungul deceniilor.

Desigur, există și vor exista proiecte hobbyiste pentru a scrie și BIOS. Și acestea, până acum, par să aleagă C și / sau asamblarea. Poate că într-o zi vor fi folosite alte tehnologii. Dar astăzi, alegerea este bine definită.

Comentarii

• Este un pic de nit-picking, dar C # și Java nu sunt interpretate . Se compilează în octet-cod. Este codul de octeți care este apoi tratat de un interpret. ‘ nu schimbă logica primului paragraf.
• @Tonny Este corect ‘. Am adăugat ” direct sau intermediar interpretat ” pentru a fi puțin mai clar.
• @Tonny în mod normal o jitter, mai degrabă decât un interpret, ceea ce reprezintă o distincție importantă, deoarece este ‘ posibil să pre-jit totul nativ, atâta timp cât anumite tehnici dinamice sunt ‘ t folosit. Ca atare, ar fi posibil teoretic să scriem un BIOS în limbaje .NET sau Java, dacă s-ar face ambele lucruri și s-a asigurat că este disponibil tot suportul de runtime necesar. Îmi imaginez că eforturile de a face acest lucru ar depăși orice comoditate găsită.
• @Tonny De fapt, C # se compilează în codul nativ msdn.microsoft.com/en -us / vstudio / dotnetnative.aspx , așa că este ‘ ciudat să o vedem în lista limbajelor slabe / dinamice.
• @Den C # nu este de obicei compilat în codul nativ. Acest produs nativ .Net la care conectați nu a fost încă lansat oficial. Din ceea ce am citit ‘, acesta va compila codul aplicației și codul cadru necesar într-un executabil. Conform Întrebărilor frecvente, acest lucru va fi vizat inițial pentru aplicațiile din Magazinul Windows, deci poate dura ceva timp pentru ca acest lucru să fie acceptat mai larg. Acestea fiind spuse, se pare că Microsoft ar putea să se îndepărteze de modelul mașinii virtuale în viitor dacă totul merge bine.

BIOS-ul real pentru un computer ar fi scris într-un anumit limbaj (probabil C sau asamblare) care este compilat în codul binar dependent de arhitectură; acest cod nu poate funcționa pe orice altă arhitectură (și, probabil, nu este necesar, deoarece este deja foarte specific mașinii cu care este livrat).

Dar vă gândiți la ROM-uri cu opțiuni (care sunt uneori denumite BIOS-uri, ca în „BIOS-ul video” pentru o opțiune ROM GPU)?

Pentru BIOS-ul vechi, compatibil opțional ROM-uri, acestea ar fi probabil cod executabil dependent de ISA (generat din nou de orice limbaj care poate fi compilat pentru a viza arhitectura dorită); PCI, de asemenea, permite includerea codului pentru mai multe ISA-uri și permite gazdei să selecteze imaginea binară corespunzătoare în timpul procesului de boot.

Pentru opțiunea compatibilă UEFI ROM-uri, există, de asemenea, un format de cod de octet independent de arhitectură care poate fi rulat pe diferite arhitecturi, dar codul dependent de ISA poate fi de asemenea utilizat.