Qual linguagem de programação é usada para escrever um programa BIOS?

Pelo que entendi, o código BIOS / fluxo de bits que é mantido na ROM deve ser genérico (trabalhar junto com vários tipos de CPU ou ISAs). Além disso, vi na web ser mencionado que é possível despejar seu código (e “desmontá-lo”).

Então, em qual linguagem, conjunto de instruções ou código de máquina ele está escrito? Não necessita de nenhum tipo de processador para realizar suas operações? Se sim, suponho que utilizará a CPU externa, então como conhece o conjunto de instruções específico da CPU empregada?

Talvez tem um processador interno?

Comentários

  • possível duplicata de Como funcionam os computadores?
  • Postagem cruzada já é ruim o suficiente, mas quando acaba no Hot Network Questions em ambas as versões , que ‘ está além do limite …
  • ” Código BIOS / fluxo de bits que continha o A ROM deve ser genérica (trabalhar junto com vários tipos de CPU ou ISAs). ” – Eu nunca ouvi falar de um BIOS que funcione com vários ISAs. Você tem um exemplo?
  • As I understand, the BIOS code/bitstream that is held in the ROM should be generic (work alongside with multiple CPU types or ISAs). I ‘ d digo ” Não, pelo contrário ”
  • Este não é nem mesmo um anúncio remotamente uplicado de uma pergunta tão geral quanto ” Como funcionam os computadores? “. Por favor, não feche como enganado.

Resposta

Os BIOSes costumavam ser escritos exclusivamente em linguagem assembly, mas o transição foi feita há muito tempo para escrever a maior parte do código em alguma linguagem de nível superior, e deixar escrito em assembly o mínimo de partes possível, de preferência apenas o bootstrapper (as primeiras centenas de instruções que a CPU salta para depois de um start / reset,) e quaisquer rotinas que lidem com peculiaridades específicas da arquitetura subjacente.

BIOSes já estavam sendo escritos principalmente em C no início dos anos noventa. (Eu escrevi um BIOS em 90% C, 10% assembly no início dos anos 90.)

O que também ajudou muito nessa direção é:

  • C bibliotecas que visam uma arquitetura específica e incluem funções para lidar com peculiaridades dessa arquitetura, por exemplo, funções para ler / gravar bytes de / para portas de E / S da arquitetura x86. O Microsoft C sempre ofereceu funções de biblioteca para esse tipo de coisa.

  • Compiladores C que não só visam uma arquitetura de CPU específica, mas também oferecem extensões para a linguagem C que você pode usar em a fim de escrever código que faz uso de recursos especiais da CPU. Por exemplo, a arquitetura x86 oferece suporte a coisas conhecidas como interrupções, que invocam rotinas conhecidas como manipuladores de interrupções e exige que tenham sequências especiais de instrução de entrada / saída. Desde os primeiros dias, o Microsoft C oferece suporte a palavras-chave especiais que você pode usar para marcar uma função como um manipulador de interrupção, para que ela possa ser chamada diretamente por uma interrupção de CPU, de modo que você não precise escrever nenhum assembly para ela.

Hoje em dia, eu presumiria que a maior parte do BIOS é escrita em C ++, se não em qualquer linguagem de nível superior.

A grande maioria do código que o compõe. um BIOS é específico para o hardware subjacente, portanto, não precisa realmente ser portátil: é garantido que sempre será executado no mesmo tipo de CPU. A CPU pode evoluir, mas contanto que mantenha compatibilidade com versões anteriores, ela ainda pode executar o BIOS sem modificações. Além disso, você sempre pode recompilar as partes da BIOS escritas em C para funcionar nativamente em qualquer nova CPU que surgir, se houver necessidade.

A razão pela qual escrevemos BIOSes em linguagens de nível superior assembly é porque é mais fácil escrevê-los dessa maneira, não porque eles realmente precisam ser portáteis.

Comentários

  • Sim. Às vezes, você pode até ter uma placa-mãe vinculada não apenas a uma arquitetura de CPU específica, mas até mesmo a um fornecedor de CPU específico. Hoje em dia você pode comprar uma placa-mãe x86 que é compatível apenas com processadores Intel x86, ou uma placa-mãe x86 que é compatível apenas com processadores AMD x86. O BIOS nessas placas-mãe será idêntico em grande parte, porque em ambos os casos a CPU entende o conjunto de instruções x86, e a maioria dos periféricos são idênticos, mas alguns periféricos têm diferenças, que o BIOS deve levar em consideração.
  • @Reflection dê uma olhada de perto na aparência física de uma placa-mãe. O soquete da CPU terá uma certa disposição de pinos, que é específica para a família de CPUs que aceita.Você não pode conectar fisicamente, digamos, um Intel P4 a uma placa-mãe AMD Opteron
  • O termo ” BIOS ” refere-se ao ” Sistema básico de entrada / saída ” de um PC, portanto, ter um BIOS implica em uma CPU x86. Os sistemas IA64 têm um EFI em vez de um BIOS, os sistemas PowerPC podem ter um sistema Open Firmware ou proprietário, os sistemas Sparc também têm OFW (ou melhor, OpenBoot), o OLPC X0 é um sistema baseado em x86 que usa OFW. Mesmo os PCs não ‘ não usam mais o BIOS, eles mudaram para (U) EFI. OB / OFW é interessante, porque é projetado não apenas para ser portátil, mas também para plataformas cruzadas. Os drivers OFW funcionarão em qualquer sistema OFW, eles são ” Gravar uma vez, executar em qualquer lugar “, independentemente da CPU ISA.
  • ” Hoje em dia, eu presumiria que a maior parte da BIOS está escrita em C ++ ” Eu não ‘ t necessariamente suponha que, pode ser verdade, mas eu trabalho nessa indústria e certamente muitos gerenciadores de inicialização são escritos em C. As pessoas que escrevem esse tipo de coisa são geralmente os ” Old Guard ” e tende a não confiar totalmente em C ++ ainda.
  • @TomDworzanski: Embora tecnicamente não seja BIOS (que se refere exclusivamente ao antigo PC-stuff de 1981), muitas implementações de IEEE-1275 Open Firmware (que é usado para uma função semelhante ao BIOS no Sparc, a PowerPC Common Hardware Reference Platform (por exemplo, PowerMac, PowerBook), o laptop OLPC X0 de 100 $ -1) são escritos parcialmente em linguagens diferentes de assembly / C. OpenBoot , Firmware aberto , OpenBIOS todos contêm…

Resposta

Embora, em teoria, seja possível escrever BIOS em qualquer idioma, o a realidade moderna é a maioria do BIOS é escrita usando Assembly, C ou uma combinação dos dois .

O BIOS deve ser escrito em uma linguagem que possa compilar em código de máquina , que seja compreendido pelo hardware-máquina físico. Isso elimina as linguagens interpretadas de forma direta ou intermediária (Perl, Python, PHP, Ruby, Java, C #, JavaScript, etc) como sendo apropriadas para escrever BIOS. (Embora, em teoria, seja possível implementar uma dessas linguagens para compilar diretamente para código de máquina estático ou pode-se de alguma forma incorporar o interpretador no BIOS. Há, por exemplo, o abandonware GCJ project para Java.)

A maioria dos OEMs implementa um BIOS estendendo implementações de BIOS proprietárias e genéricas por empresas como a American Megatrends e Phoenix Techologies . (Você provavelmente já viu uma dessas empresas exibida na primeira tela de inicialização de um computador antes.) O código-fonte para essas implementações não está disponível publicamente, mas parte dele foi divulgado. Não quero vincular diretamente a isso ao código-fonte C e assembly, mas existem locais na Internet onde esse código-fonte é discutido para aqueles que se importam em espiar.

Alguns fabricantes de hardware, como aqueles que visam os mercados de jogos e alto desempenho, saturam suas implementações de BIOS com recursos de personalização, estatísticas e interfaces de usuário atraentes projetadas para suas implementações exatas. Muitos desses recursos vão além do que é oferecido nos produtos genéricos produzidos por American Megatrends e outros. Infelizmente, essas empresas muitas vezes veem o lançamento de seu código-fonte como um risco de segurança , tão pouco se sabe sobre essas implementações de ponta porque pouco é compartilhado sobre eles. É claro que encontrar maneiras de acessar e descompilar tais implementações de BIOS, mas fazer isso pode ser difícil e possivelmente ilegal.

Voltando à questão original, devido à necessidade de produzir código de máquina nativo, um BIOS teria que ser implementado em uma linguagem de programação suportada por um compilador de código de máquina nativo . Embora existam muitas dessas linguagens e, embora eu tenha certeza que nas últimas décadas, várias linguagens foram usadas na experimentação, cada implementação de BIOS aberta que consegui encontrar depende especificamente de uma combinação de C e / ou assembly. As implementações de BIOS com fonte que analisei para formar esta conclusão incluem OpenBIOS , tinyBIOS , coreboot , Intel BIOS e Libreboot . Também observei algumas implementações de BIOS muito antigas que não são relevantes hoje, mas também seguiram a regra C e / ou assembly.

Acho que também é relevante olhar para outro software desenvolvido para interagir diretamente com o hardware.Sabemos, por exemplo, que o Kernel do Linux , o kernel do OS X e o Kernel do Windows é basicamente C com algum assembly e algumas linguagens de nível superior para tarefas específicas. Também sabemos que drivers de hardware no Linux e drivers de hardware no Windows são escritos principalmente em C .

Voltando ao BIOS, acho que também é importante considerar a economia da linguagem de programação escolhida. O BIOS é geralmente escrito como uma necessidade para complementar as vendas de hardware. Os sistemas BIOS modernos são amplamente conhecidos por serem escrito em C e / ou montagem. A mudança para alguma outra ferramenta adicionaria custos significativos ao que geralmente são considerados produtos de commodity, o que poderia afetar as vendas de forma muito adversa. Sem entrar na Economia 101, posso garantir que provavelmente não é vale a pena para um OEM se desviar de ferramentas testadas e comprovadas ao longo de décadas.

É claro que há e haverá projetos amadores para escrever BIOS também. Eles também, até agora, parecem estar escolhendo C e / ou montagem. Talvez um dia outras tecnologias sejam utilizadas. Mas hoje, a escolha de está bem definida.

Comentários

  • É um pouco crítico, mas C # e Java não são interpretados . Eles compilam em código de bytes. É o código de bytes que é então tratado por um intérprete. Não ‘ t muda a lógica do primeiro parágrafo.
  • @Tonny Isso ‘ está correto. Eu adicionei ” diretamente ou intermediário interpretado ” para ser um pouco mais claro.
  • @Tonny normalmente um jitter em vez de um intérprete, o que é uma distinção importante porque ‘ é possível pré-jitar tudo para o nativo, desde que certas técnicas dinâmicas sejam ‘ t usado. Como tal, seria praticamente possível escrever um BIOS em linguagens .NET ou Java, se alguém fizesse isso e garantisse que todo o suporte de tempo de execução necessário estivesse disponível. Imagino que os esforços para fazer isso superariam qualquer conveniência encontrada.
  • @Tonny Na verdade, C # compila para código nativo msdn.microsoft.com/en -us / vstudio / dotnetnative.aspx então ‘ é estranho vê-lo na lista de linguagens fracas / dinâmicas.
  • @Den C # é normalmente compilado para código nativo. Este produto .Net Native ao qual você vincula ainda não foi lançado oficialmente. Pelo que eu ‘ li, ele irá compilar o código do aplicativo e o código da estrutura necessária em um executável. De acordo com o FAQ, ele será direcionado inicialmente aos aplicativos da Windows Store, portanto, pode levar algum tempo para que tenha um suporte mais amplo. Dito isso, parece que a Microsoft pode se afastar do modelo de máquina virtual em algum momento no futuro, se tudo correr bem.

Resposta

O BIOS real para um computador seria escrito em alguma linguagem (provavelmente C ou assembly) que é compilada para código binário dependente de arquitetura; este código não pode ser executado em qualquer outra arquitetura (e sem dúvida nem precisa, pois já é muito específico para a máquina com a qual é enviado).

Mas você possivelmente está pensando em ROMs opcionais (às vezes chamados de BIOSes, como em “BIOS de vídeo” para uma ROM opcional de GPU)?

Para BIOS legado e real compatível ROMs de opção, eles provavelmente seriam código executável dependente do ISA (novamente gerado por qualquer linguagem que possa ser compilada para atingir a arquitetura desejada); O PCI também permite incluir código para vários ISAs e permite que o host selecione a imagem binária apropriada durante o processo de inicialização.

Para opção compatível com UEFI ROMs, há também um formato de código de byte independente de arquitetura que pode ser executado em arquiteturas diferentes, mas o código dependente de ISA também pode ser usado.

Deixe uma resposta

O seu endereço de email não será publicado. Campos obrigatórios marcados com *