9월 13, 2020
Articles
댓글이 없습니다

BIOS 프로그램을 작성하는 데 사용되는 프로그래밍 언어는 무엇입니까?

내가 이해했듯이 ROM에 보관 된 BIOS 코드 / 비트 스트림은 일반적이어야합니다 (여러 CPU 유형 또는 ISA와 함께 작동). 또한 웹에서 코드를 덤프 (및 “분해”) 할 수 있다고 언급 한 것을 보았습니다.

그렇다면 어떤 언어, 명령어 세트 또는 기계 코드로 작성됩니까? 작업을 수행하기 위해 어떤 종류의 프로세서도 필요하지 않습니까? 그렇다면 외부 CPU를 사용할 것 같으면 사용 된 CPU의 특정 명령 집합을 어떻게 알 수 있습니까?

아마도 내부 프로세서가 있습니까?

설명

의 중복 가능성이 있습니까? a>

  • 교차 게시 는 충분히 나쁘지만 두 버전 모두 i에서 핫 네트워크 질문 , 그 ‘는 창백한 것 이상입니다 …
  • ” BIOS 코드 / 비트 스트림은 ROM은 일반적이어야합니다 (여러 CPU 유형 또는 ISA와 함께 작동). “-여러 ISA에서 작동하는 BIOS에 대해 본 적이 없습니다 . 예가 있습니까?
  • As I understand, the BIOS code/bitstream that is held in the ROM should be generic (work alongside with multiple CPU types or ISAs). 저는 ‘ “라고 말합니다. 아니요, 반대로 ”
  • 이것은 원격 광고가 아닙니다. ” 컴퓨터는 어떻게 작동합니까? “와 같은 일반적인 질문과 중복됩니다. 속여서 닫지 마십시오.

    • 답변

    BIOS는 어셈블리 언어로만 작성되었지만 코드의 대부분을 더 높은 수준의 언어로 작성하고 가능한 한 적은 부분, 가급적이면 부트 스트 래퍼 (CPU가 점프하는 명령의 처음 몇 백 개)를 어셈블리에 작성하도록 오래 전에 전환이 이루어졌습니다. 시작 / 초기화 후) 및 기본 아키텍처의 특정 문제를 처리하는 루틴이 무엇이든.

    BIOS는 이미 90 년대 초반에 주로 C로 작성되었습니다. (나는 90 % C로 BIOS를 작성했고 90 년대 초반에 10 % 어셈블리를 작성했습니다.)

    이 방향으로도 크게 도움이 된 것은 다음과 같습니다.

    • C 특정 아키텍처를 대상으로하고 해당 아키텍처의 특성을 처리하기위한 기능 (예 : x86 아키텍처의 I / O 포트에서 /에서 바이트 읽기 / 쓰기 기능)을 포함하는 라이브러리. Microsoft C는 항상 이러한 종류의 라이브러리 기능을 제공했습니다.

    • 특정 CPU 아키텍처를 대상으로 할뿐만 아니라 사용할 수있는 C 언어에 대한 확장도 제공하는 C 컴파일러 특별한 CPU 기능을 사용하는 코드를 작성합니다. 예를 들어, x86 아키텍처는 인터럽트 처리기로 알려진 루틴을 호출하는 인터럽트라고하는 것을 지원하며 특수한 시작 / 종료 명령 시퀀스를 가져야합니다. 초창기부터 Microsoft C는 함수를 인터럽트 핸들러로 표시하는 데 사용할 수있는 특수 키워드를 지원했기 때문에 CPU 인터럽트에 의해 직접 호출 될 수 있으므로 어셈블리를 작성할 필요가 없었습니다.

    요즘에는 대부분의 BIOS가 더 높은 수준의 언어가 아니라면 C ++로 작성되었다고 가정합니다.

    구성하는 대부분의 코드 BIOS는 기본 하드웨어에 고유하므로 실제로 이식 할 필요가 없습니다. 항상 동일한 유형의 CPU에서 실행된다는 것이 보장됩니다. CPU는 발전 할 수 있지만 이전 버전과의 하위 호환성을 유지하는 한 수정하지 않은 상태로 BIOS를 실행할 수 있습니다. 또한 필요에 따라 새로운 CPU에서 기본적으로 실행되도록 C로 작성된 BIOS 부분을 언제든지 다시 컴파일 할 수 있습니다.

    우리가 BIOS를보다 높은 수준의 언어로 작성하는 이유 어셈블리는 이러한 방식으로 작성하는 것이 더 쉽기 때문입니다. 실제로 이식 할 필요가 없기 때문이 아닙니다.

    댓글

    • 예. 때로는 특정 CPU 아키텍처뿐만 아니라 특정 CPU 공급 업체에도 연결된 마더 보드를 가질 수도 있습니다. 요즘에는 Intel x86 CPU 와만 호환되는 x86 마더 보드 또는 AMD x86 CPU 와만 호환되는 x86 마더 보드를 구입할 수 있습니다. 두 경우 모두 CPU가 x86 명령 세트를 이해하고 대부분의 주변 장치가 동일하지만 일부 주변 장치에는 BIOS가 고려해야하는 차이점이 있기 때문에 이러한 마더 보드의 BIOS는 거의 동일합니다.
    • @Reflection은 마더 보드가 물리적으로 어떻게 보이는지 자세히 살펴 봅니다. CPU 소켓은 수용하는 CPU 제품군에 특정한 특정 핀 배열을 갖습니다.Intel P4를 AMD Opteron 마더 보드에 물리적으로 연결할 수 없습니다.
    • ” BIOS “라는 용어는 PC의 ” 기본 입 / 출력 시스템 “이므로 BIOS가 있다는 것은 x86 CPU를 의미합니다. IA64 시스템에는 BIOS 대신 EFI가 있고 PowerPC 시스템에는 오픈 펌웨어 시스템 또는 독점 시스템이있을 수 있으며 Sparc 시스템에는 OFW (또는 오히려 OpenBoot)도 있으며 OLPC X0은 OFW를 사용하는 x86 기반 시스템입니다. PC에서도 ‘ 더 이상 BIOS를 사용하지 않고 (U) EFI로 전환했습니다. OB / OFW는 이식성뿐만 아니라 크로스 플랫폼으로 설계 되었기 때문에 흥미 롭습니다. OFW 드라이버는 모든 OFW 시스템에서 작동하며 CPU에 관계없이 ” Write Once Run Anywhere “입니다. ISA.
    • ” 요즘에는 대부분의 BIOS가 C ++로 작성되었다고 가정합니다. ” ‘ 그것이 사실일지도 모르지만 저는 그 업계에서 일하고 있으며 확실히 많은 부트 로더가 일반 C로 작성되었습니다. 그런 종류의 것을 작성하는 사람들은 종종 ” Old Guard ” 아직 C ++를 완전히 신뢰하지 않는 경향이 있습니다.
    • @TomDworzanski : 기술적으로 BIOS는 아니지만 (독점적으로 이전 1981 년 PC 제품에 추가) IEEE-1275 오픈 펌웨어의 많은 구현 (Sprc, PowerPC 공통 하드웨어 참조 플랫폼 (예 : PowerMac, PowerBook), 100 달러 노트북 OLPC X0의 BIOS와 유사한 역할에 사용됨) -1) 어셈블리 / C 이외의 언어로 부분적으로 작성되었습니다. OpenBoot , 오픈 펌웨어 , OpenBIOS 모두…

    답변

    이론상 어떤 언어로든 BIOS를 작성할 수 있지만 현대 현실은 대부분의 BIOS는 어셈블리, C 또는 둘의 조합을 사용하여 작성됩니다 .

    BIOS는 물리적 하드웨어-머신에서 인식하는 머신 코드 로 컴파일 할 수있는 언어로 작성되어야합니다. 이렇게하면 BIOS 작성에 적합한 직접 또는 중간 해석 언어 (Perl, Python, PHP, Ruby, Java, C #, JavaScript 등)가 제거됩니다. (이론적으로는 이러한 언어 중 하나를 구현하여 정적 기계 코드로 직접 컴파일하거나 어떻게 든 BIOS에 인터프리터를 내장 할 수 있습니다. 예를 들어, abandonware GCJ project for Java.)

    대부분의 OEM은 American Megatrends

    와 같은 회사에서 독점적 인 일반 BIOS 구현을 확장하여 BIOS를 구현합니다. a> 및 Phoenix Techologies . (이전에 컴퓨터의 첫 번째 부팅 화면에 이러한 회사 중 하나가 표시되는 것을 본 적이있을 것입니다.) 이러한 구현의 소스 코드는 공개적으로 사용 가능하지 않지만 일부는 유출되었습니다. 직접 연결하고 싶지 않습니다. C 및 어셈블리 소스 코드에 대한 것이지만,이 소스 코드가 논의되는 인터넷 위치 가 있습니다.

    고성능 및 게임 시장을 목표로하는 일부 하드웨어 제조업체는 정확한 구현을 위해 설계된 사용자 정의 기능, 통계 및 매력적인 사용자 인터페이스로 BIOS 구현을 포화시킵니다. 이러한 기능 중 상당수는 생산 된 일반 제품에서 제공되는 것 이상입니다. 안타깝게도 이러한 회사는 종종 소스 코드 공개를 보안 위험으로 간주 하므로 이러한 고급 구현에 대해 알려진 바가 거의 없습니다. 그들에 대해 거의 공유되지 않습니다. 물론 그러한 BIOS 구현에 액세스하고 디 컴파일하는 방법을 찾아야하지만 그렇게하는 것은 어렵고 불법 일 수 있습니다.

    원래의 질문으로 돌아가서, 네이티브 머신 코드 인 BIOS를 생성해야하기 때문입니다. 기본 기계어 코드 컴파일러가 지원하는 프로그래밍 언어 로 구현되어야합니다. 그러한 언어가 많이 있고 지난 수십 년 동안 여러 언어가 실험에 사용되었지만 내가 찾은 모든 개방형 BIOS 구현은 특히 C 및 / 또는 어셈블리의 조합에 의존합니다. 이 결론을 구성하기 위해 살펴본 소스 BIOS 구현에는 OpenBIOS , tinyBIOS , coreboot , Intel BIOS 및 Libreboot . 또한 오늘날에는 관련이 없지만 C 및 / 또는 어셈블리 규칙을 따르는 매우 오래된 BIOS 구현을 살펴 보았습니다.

    그것이 다른 소프트웨어를 살펴 보는 것과도 관련이 있다고 생각합니다. 하드웨어와 직접 상호 작용합니다.예를 들어, Linux 커널 , OS X 커널 및 Windows 커널 은 주로 C이며 일부 어셈블리와 특정 작업을위한 상위 수준 언어가 있습니다. 또한 Linux의 하드웨어 드라이버 와 Windows의 하드웨어 드라이버 는 대부분 C로 작성된다는 것을 알고 있습니다. .

    BIOS로 돌아가서 선택한 프로그래밍 언어의 경제성을 고려하는 것도 중요하다고 생각합니다. BIOS는 일반적으로 하드웨어 판매를 보완하기위한 필수 요소로 작성됩니다. 최신 BIOS 시스템은 대체로 C 및 / 또는 어셈블리로 작성되었습니다. 다른 도구로 이동하면 일반적으로 판매에 매우 부정적인 영향을 미칠 수있는 상품으로 간주되는 상품에 상당한 비용이 추가 될 수 있습니다. 경제학 101에 들어 가지 않고는 그렇지 않을 수도 있습니다. OEM에게는 수십 년 동안 입증 된 검증 된 도구에서 벗어나는 것이 가치가 있습니다.

    물론 BIOS를 작성하는 취미 프로젝트도 있으며 앞으로도있을 것입니다. 이것들도 지금까지 C 및 / 또는 어셈블리를 선택하는 것 같습니다. 아마도 언젠가 다른 기술이 사용될 것입니다. 그러나 오늘날의 선택은 잘 정의되어 있습니다.

    댓글

    • 조금 간단하지만 C #과 Java는 해석되지 않습니다. . 그들은 바이트 코드로 컴파일됩니다. 인터프리터가 처리하는 것은 바이트 코드입니다. ‘ 첫 번째 단락의 논리를 변경하지 않습니다.
    • @Tonny That ‘이 맞습니다. 좀 더 명확하게하기 위해 ” 직접 또는 중간 해석 “을 추가했습니다.
    • @Tonny 일반적으로 인터프리터가 아닌 지터. 특정 동적 기술이 적용되지 않는 한 모든 것을 네이티브로 사전 지정하는 것이 ‘ 가능하기 때문에 중요한 차이점입니다. ‘ 사용되지 않았습니다. 따라서 .NET 언어 또는 Java로 BIOS를 작성하고 필요한 모든 런타임 지원을 사용할 수 있는지 확인하면 이론적으로 거의 가능할 것입니다. 그렇게하려는 노력이 그 어떤 편리함도 잃어 버릴 것이라고 생각합니다.
    • @Tonny 실제로 C #은 네이티브 코드로 컴파일됩니다. msdn.microsoft.com/en -us / vstudio / dotnetnative.aspx 그래서 ‘ 약한 / 동적 언어 목록에서보기가 이상합니다.
    • @Den C # 네이티브 코드로 컴파일되지 않습니다 . 귀하가 링크하는이 .Net Native 제품은 아직 공식적으로 출시되지 않았습니다. 내가 읽은 ‘에서 애플리케이션 코드와 필요한 프레임 워크 코드를 실행 파일로 컴파일합니다. FAQ에 따르면 처음에는 Windows Store 앱을 대상으로하기 때문에 더 광범위하게 지원되는 데 시간이 걸릴 수 있습니다. 하지만 모든 것이 순조롭게 진행된다면 마이크로 소프트는 언젠가 가상 머신 모델에서 멀어 질 것 같다.

    답변

    컴퓨터의 실제 BIOS는 아키텍처 종속 바이너리 코드로 컴파일되는 일부 언어 (아마도 C 또는 어셈블리)로 작성됩니다. 이 코드는 다른 어떤 아키텍처에서도 실행할 수 없습니다 (그리고 실제로는 그럴 필요가 없습니다. 이미 제공되는 시스템에 매우 구체적이기 때문입니다).

    하지만 옵션 ROM (GPU 옵션 ROM의 “비디오 BIOS”에서와 같이 BIOS라고도 함)?

    실제 레거시 BIOS 호환 옵션 ROM은 아마도 ISA 종속 실행 코드 일 것입니다 (원하는 아키텍처를 대상으로 컴파일 할 수있는 모든 언어에 의해 다시 생성됨). PCI는 또한 여러 ISA에 대한 코드를 포함하도록 허용 하고 호스트가 부팅 프로세스 중에 적절한 바이너리 이미지를 선택할 수 있도록합니다.

    UEFI 호환 옵션의 경우 ROM에는 다른 아키텍처에서 실행할 수있는 아키텍처 독립 바이트 코드 형식 도 있지만 ISA 종속 코드도 계속 사용할 수 있습니다.

    답글 남기기

    이메일 주소를 발행하지 않을 것입니다. 필수 항목은 *(으)로 표시합니다