모든 컴퓨터에 대한 범용 어셈블리 언어가 가능합니까?

어셈블리 언어에 대해 몇 가지 질문을하고 싶습니다. 내 이해는 기계 언어에 매우 가깝기 때문에 더 빠르고 효율적입니다.

컴퓨터 아키텍처가 다르기 때문에 어셈블리에서 다른 아키텍처에 대해 다른 코드를 작성해야합니까? 그렇다면 왜 어셈블리가 아닌가? 한 번만 작성하십시오-모든 유형의 언어를 실행 하시겠습니까? 한 번만 쓰고 다른 구성을 가진 거의 모든 컴퓨터에서 실행할 수 있도록 단순히 보편적으로 만드는 것이 쉽지 않을까요? (불가능하다고 생각하지만 구체적이고 심층적 인 답변을 원합니다)

어떤 사람들은 C가 내가 찾고있는 언어라고 말할 수 있습니다. 나는 C를 사용하지 않았지만 예를 들어 Java보다 빠르지 만 여전히 고급 언어라고 생각합니다. 나는 여기에 잘못되었을 수 있습니다.

어셈블리 언어 는 컴퓨터 프로그래머가 이해하기 쉬운 방식으로 컴퓨터의 명령어 세트에 대한 명령어를 작성 하는 방법입니다.

아키텍처마다 다른 명령어 세트가 있습니다. 허용되는 명령어 세트는 아키텍처마다 다릅니다. 따라서 한 번에 한 번 쓰기 실행 어셈블리 프로그램을 가질 수는 없습니다. 예를 들어 x86 프로세서가 지원하는 명령어 세트는 ARM 프로세서가 지원하는 명령어 세트와 매우 다릅니다. x86 프로세서 용 어셈블리 프로그램을 작성한 경우 ARM 프로세서에서 지원되지 않는 많은 명령어가 있으며 그 반대도 마찬가지입니다.

어셈블리 언어를 사용하는 주된 이유는 프로그램을 매우 낮은 수준으로 제어하고 프로세서의 모든 명령을 활용할 수 있기 때문입니다. 특정 프로세서에 고유 한 기능을 사용하도록 프로그램을 사용자 지정하면됩니다. 때로 프로그램 속도를 높일 수 있습니다. 어디서나 쓸 수있는 철학은 근본적으로 그와 상충됩니다.

어셈블리 언어의 정의는 해당 언어가 기계 코드로 직접 변환 될 수있는 언어라는 것입니다. 어셈블리 언어의 각 작업 코드는 대상 컴퓨터에서 정확히 하나의 작업으로 변환됩니다. (어떻게하면 좀 더 복잡하다. 일부 어셈블러는 op 코드에 대한 인수를 기반으로 "어드레싱 모드"를 자동으로 결정하지만 여전히 한 줄의 어셈블리는 하나의 기계 언어 명령어로 변환된다는 원칙이 있습니다.)

의심 할 여지없이 어셈블리 언어처럼 보이지만 다른 컴퓨터에서 다른 기계 코드로 변환되는 언어를 발명 할 수 있습니다. 그러나 정의상 이것은 어셈블리 언어가 아닙니다. 어셈블리 언어와 유사한 고급 언어입니다.

당신의 질문은 "물에 뜨지 않거나 물을 가로 질러 여행 할 수있는 다른 방법이 있지만 바퀴와 모터가 있고 육지로 여행 할 수있는 보트를 만들 수 있습니까?" 그 정의에 따르면 그러한 차량은 보트가 아닐 것입니다. 차처럼 들립니다.

더 없다 개념 (I, 아니 컴퓨터 아마 ... 일 것없는 과학을 세계의 모든 컴퓨터에 대해 하나 개의 어셈블리 언어를 가지고에 대한) 이유는. 사실, 많은 것들이 훨씬 쉬워 질 것입니다. 이론에 관한 한, 그것들은 어쨌든 약간 펑키 한 형용사까지 동일합니다.

그러나 실제로는 서로 다른 목표를 제공하는 운영 및 설계 원칙 (예 : RISC vs CISC)이 서로 다른 목적에 따라 서로 다른 칩이 있으며이를 운영하는 명령어 세트와 어셈블리 언어가 다릅니다. 결국, 대답은 다른 목표, 다른 디자인 결정 과 같이 다른 프로그래밍 언어가 왜 그렇게 많은지 묻는 질문과 같습니다 .

즉, 일부 공유 인터페이스에 도달하기 위해 추상화 레벨을 도입 할 수 있습니다. 예를 들어, x86은 온 칩 레벨로 꽤 오랫동안 사라졌습니다. x86 명령어를 프로세서가 실제로 사용하는 모든 것으로 변환하는 작은 하드웨어가 있습니다. C와 같은 언어는 하스켈, 자바 또는 루비와 같은 언어에 이르기까지 하드웨어에서 (아마도 작은 경우라면) 또 다른 단계입니다. 그렇습니다. 컴파일러는 컴퓨터 과학의 주요 성과 중 하나입니다. 이런 방식으로 우려를 분리 할 수 ​​있기 때문입니다.

"어디서나 한 번 쓰기"라는 문구는 그 의미를 알지 못하는 것 같습니다. 즉의 마케팅 슬로건 인 썬 마이크로 시스템즈 상업적의 개념을 발명 한 "가상 머신" 과 "바이트 코드" 아마도 생각이 학계 1에서 유래 한 수 있지만, Java 용을 ^일. 이 아이디어는 나중에 썬이 Java 라이센싱 침해를 이유로 고소한 후 .Net을 위해 .Net 용으로 복사되었습니다. Java 바이트 코드는 기계 간 어셈블리 또는 기계 언어 아이디어를 구현 한 것입니다. Java 이외의 여러 언어에 사용되며 이론적으로 모든 언어를 컴파일하는 데 사용할 수 있습니다. 수년간의 고급 최적화를 거친 후 Java는 컴파일 된 언어와 거의 유사한 성능을 제공하여 고성능 플랫폼에 관계없이 가상 머신 기술이 일반적으로 달성 될 수 있음을 보여줍니다.

요구 사항과 관련된 초기 단계 / 순환의 또 다른 새로운 아이디어를 재 계산 프로젝트 라고하며 다른 목적으로 사용될 수는 있지만 과학적 연구를위한 것입니다. 아이디어는 가상 머신 기술을 통해 계산 실험을 복제 할 수 있도록하는 것입니다. 이것은 주로 임의의 하드웨어에서 다른 머신 아키텍처를 시뮬레이션하는 아이디어입니다.

높은 수준의 이유

마이크로 프로세서는 놀라운 일을합니다. 세탁기 나 엘리베이터와 같은 기계를 가져 와서 주문 제작 된 메커니즘이나 회로 전체를 저렴하고 대량 생산되는 실리콘으로 대체 할 수 있습니다. 칩. 부품에 많은 돈을 절약하고 디자인에 많은 시간을 절약합니다.

그러나 수많은 맞춤형 디자인을 대체 하는 표준 칩이 있습니까? 모든 애플리케이션에 완벽한 단일의 완벽한 마이크로 프로세서가있을 수는 없습니다. 일부 응용 프로그램은 전력 사용량을 최소화해야하지만 빠를 필요는 없습니다. 다른 것들은 빠를 필요가 있지만 프로그래밍하기 쉬울 필요는 없으며, 다른 것들은 저비용이어야합니다.

따라서 마이크로 프로세서에는 여러 가지 "풍미"가 있으며 각각 고유 한 장단점이 있습니다. 코드 재사용이 가능하고 올바른 기술을 가진 사람들을 쉽게 찾을 수 있기 때문에 모두 호환 가능한 명령어 세트를 사용하는 것이 바람직합니다. 그러나 명령어 세트 는 프로세서의 비용, 복잡성, 속도, 사용 용이성 및 물리적 제약에 영향을 미치므로 몇 가지 "주류"명령어 세트 (및 많은 작은 명령어)가 있으며 각 명령어 세트에는 특성이 다른 프로세서가 많이 있습니다.

아, 그리고 기술이 변화함에 따라 이러한 모든 절충점이 바뀌므로 지침 세트가 발전하고 새로운 것이 등장하고 오래된 것이 죽습니다. 오늘날 "최상의"교육이 있었더라도 20 년이되지 않을 수 있습니다.

하드웨어 세부 사항

아마도 명령어 세트에서 가장 큰 디자인 결정은 워드 크기 , 즉 프로세서가 "자연스럽게"조작 할 수있는 숫자의 크기 일 것입니다. 8 비트 프로세서는 0-255의 숫자를 처리하는 반면 32 비트 프로세서는 0-4,294,967,295의 숫자를 처리합니다. 하나를 위해 설계된 코드는 다른 코드를 위해 완전히 다시 생각해야합니다.

하나의 명령어 세트에서 다른 명령어 세트로 명령어를 번역하는 것만이 아닙니다. 다른 명령 세트에서 완전히 다른 접근법이 바람직 할 수 있습니다. 예를 들어, 8 비트 프로세서에서는 찾아보기 테이블이 이상적 일 수 있지만 32 비트 프로세서에서는 동일한 목적으로 산술 연산이 더 좋습니다.

명령어 세트간에 다른 주요 차이점이 있습니다. 대부분의 지침은 네 가지 범주로 나뉩니다.

• 계산 (산술 및 논리)
• 제어 흐름
• 데이터 전송
• 프로세서 구성

프로세서는 수행 할 수있는 계산 종류와 제어 흐름, 데이터 전송 및 프로세서 구성에 접근하는 방법이 다릅니다.

예를 들어, 일부 AVR 프로세서는 곱하거나 나눌 수 없습니다. 모든 x86 프로세서는 가능합니다. 상상할 수 있듯이 곱셈과 나눗셈과 같은 작업에 필요한 회로를 제거하면 프로세서가 더 간단하고 저렴해질 수 있습니다. 이러한 작업은 필요한 경우 소프트웨어 루틴을 사용하여 계속 수행 할 수 있습니다.

x86을 사용하면 산술 명령어가 피연산자를 메모리에서로드하거나 결과를 메모리에 저장할 수 있습니다. ARM은로드 저장소 아키텍처이므로 메모리에 액세스하기위한 몇 가지 전용 명령 만 있습니다. 한편 x86에는 전용 조건부 명령어가 있으며 ARM에서는 거의 모든 명령어를 조건부로 실행할 수 있습니다. 또한 ARM을 사용하면 대부분의 산술 명령어의 일부로 비트 시프트를 수행 할 수 있습니다. 이러한 차이로 인해 성능 특성, 칩의 내부 설계 및 비용의 차이, 어셈블리 언어 수준에서의 프로그래밍 기술의 차이가 발생합니다.

결론

범용 어셈블리 언어를 사용할 수없는 이유는 어셈블리 코드를 하나의 명령어 세트에서 다른 명령어 세트로 올바르게 변환하려면 컴퓨터가 아직 할 수없는 코드를 다시 설계해야하기 때문입니다.

DW의 놀라운 답변 추가 : 하나의 어셈블러를 사용하려면 모든 아키텍처를 유지하고 그 중 완벽한 번역기를 유지하고 수행중인 작업을 완전히 이해해야합니다.
한 아키텍처 당 매우 최적화 된 코드는 최적화를 해제하고보다 추상적 인 수준에서 이해하고 다른 아키텍처에 맞게 최적화해야합니다.
그러나 이것이 가능하다면 우리는 완벽한 C 컴파일러를 갖게 될 것이며 순수한 어셈블리로 작성하는 것이 전혀 도움이되지 않을 것입니다.
어셈블러 사용의 주요 요점은 성능이며, 최신 컴파일러에서는 압축 할 수 없습니다.
이러한 프로그램을 작성하는 것은 기존 컴파일러보다 훨씬 어려울 수 있으며 생성되는 모든 새 아키텍처를 유지 관리하면 훨씬 어려워집니다.
그리고 "하나의"프로그램의 경우, 이전 버전과의 호환성도 완벽합니다.

Microsoft는 MSIL 을 중간 어셈블리 언어로 발명했습니다 . 프로그램은 C # 또는 VB.Net에서 MSIL로 컴파일됩니다. 런타임시 MSIL은 JIT 컴파일러를 사용하여 실행중인 머신의 머신 코드로 컴파일되었습니다 . MSIL을 포함하는 파일은 X86의 시작 부분에 프로그램을 시작하기위한 몇 가지 지침이있는 .EXE 파일입니다. ARM 프로세서에서는 프로그램 이름 앞에 mono라는 단어를 입력하여 실행합니다.

언급했듯이 LLVM은 지금까지 가장 가까운 것입니다. 실제로 보편적 인 언어에 대한 큰 장벽은 동시성, 메모리 사용, 처리량, 대기 시간 및 전력 소비와 같은 암묵적인 트레이드 오프와 관련된 근본적인 차이가 될 것입니다. 명시 적으로 SIMD 스타일로 쓰면 너무 많은 메모리를 사용하고있을 수 있습니다. 명시 적으로 SISD 스타일로 작성하면 차선의 병렬화가 발생합니다. 처리량을 최적화하면 지연 시간이 줄어 듭니다. 단일 스레드 처리량 (예 : 클럭 속도)을 최대화하면 배터리 수명이 단축됩니다.

최소한 코드에는 트레이드 오프로 주석을 달아야합니다. 가장 중요한 것은 언어에 우수한 대수 / 유형 속성이있어 컴파일러에 논리적 불일치를 최적화하고 감지 할 수있는 충분한 공간을 제공하는 것입니다.

그런 다음 정의되지 않은 동작에 대한 문제가 있습니다. C 및 어셈블리 언어의 속도의 대부분은 정의되지 않은 동작에서 비롯됩니다. 실제로 발생하는 정의되지 않은 동작을 인정하면이를 특수한 경우 (예 : 아키텍처 및 컨텍스트 특정 핵)로 처리하게됩니다.

아마도 당신이 찾고있는 것은 모든 사람이 명령의 기호에 동의하는 범용 터닝 머신 표기법 일 것입니다. ( https://ko.wikipedia.org/wiki/Universal_Turing_machine )

선삭 가능 언어를 기본 공급 업체별 기계 코드로 변환하고 컴퓨터라고하는 모든 것을 위해 빌드되는 '어셈블러'.

에서 프로그래밍 컴퓨터의 예술 은이가 어떻게 보이는지의 예제가있다.

그러나 "모든 컴퓨터에서 사용할 수있는 상용 언어가 아닌 이유는 무엇입니까?"라는 질문을 고려해보십시오. 가장 영향력이 큰 영향은 (1) 편의성입니다. 모든 어셈블리 언어가 가장 사용하기 쉬운 것은 아닙니다. (2) 다른 브랜드의 기계와 벤더 사이의 경제성, 제공, 비 호환성은 기계 설계에 한정된 자원 (시간 / 돈)의 결과뿐만 아니라 비즈니스 전략입니다.

가정 : 고급 언어 L1을 하위 언어 L0으로 컴파일하고 최적화하는 것이 고급 언어 L2 (L1보다 높음)를 L0으로 컴파일하고 최적화하는 것보다 쉽습니다. L2에서 L0보다 L1에서 L0을 컴파일 할 때 더 최적화 된 코드를 생성 할 수 있다는 점에서 더 쉽습니다.

나는 아마도 가정이 맞다고 생각합니다. 그래서 아마도 대부분의 컴파일러는 저수준 중급 언어 (IR / LLVM)를 사용합니다.

이것이 사실이라면, 저수준 언어 L0을 사용하고 L0을 다른 저수준 언어로 번역하기 위해 컴파일러를 작성하십시오. 예를 들어 MIPS 명령어 세트를 사용하여 x86, arm, power, ...로 컴파일하십시오.

-타우 픽