언어가 CPU 디자인에 어떤 영향을 미쳤습니까? [닫은]

우리는 하드웨어가 컴파일 된 이진 코드만을 볼 때 프로그램이 어떤 언어로 작성되었는지는 신경 쓰지 않는다고하지만 종종 이것이 사실은 아닙니다. 예를 들어 겸손한 Z80을 생각해보십시오. 8080 명령어 세트의 확장 기능에는 CPIR과 같은 명령어가 포함되어 있습니다. CPIR은 C 스타일 (NULL로 끝나는) 문자열을 스캔하는 데 유용합니다 (예 : 수행) strlen(). 설계자는 C 길이의 프로그램이 Pascal과 달리 (길이가 헤더에있는) C 프로그램이 설계에 사용될 가능성이 있음을 식별해야합니다. 또 다른 고전적인 예는 Lisp Machine 입니다.

다른 예는 무엇입니까? 예를 들어 특정 프로세서가 특정 언어의 규칙을 선호하게 만드는 명령어, 레지스터의 수 및 유형 , 주소 지정 모드? 나는 특히 같은 가족의 개정에 관심이 있습니다.

기존 답변은 ISA 변경에 중점을 둡니다 . 다른 하드웨어 변경 사항도 있습니다. 예를 들어 C ++은 일반적으로 가상 호출에 vtable을 사용합니다. 인텔은 펜티엄 M부터 가상 함수 호출을 가속화하는 "간접 분기 예측기"구성 요소를 갖추고 있습니다.

인텔 8086 명령어 세트에는 반환 주소를 팝한 후 스택 포인터에 값을 추가하는 "ret"변형이 포함되어 있습니다. 이것은 함수 호출자가 함수 호출을하기 전에 스택으로 인수를 밀어 넣고 그 후에 튀어 나오는 많은 파스칼 구현에 유용합니다. 루틴이 예를 들어 4 바이트 단위의 매개 변수를 승인하면 스택을 정리하기 위해 "RET 0004"로 끝날 수 있습니다. 이러한 명령어가 없으면 호출 규칙에 따라 리턴 주소를 레지스터로 팝하고 스택 포인터를 업데이트 한 다음 해당 레지스터로 점프해야합니다.

흥미롭게도, 원래 Macintosh의 대부분의 코드 (OS 루틴 포함)는 68000의 지침이 없어도 Pascal 호출 규칙을 사용했습니다.이 호출 규칙을 사용하면 일반적인 호출 사이트에서 2-4 바이트의 코드가 절약되었지만 추가 코드가 필요했습니다. 매개 변수를 사용하는 모든 함수의 반환 사이트에 4-6 바이트의 코드가 있습니다.

하나의 예는 모두 갖고, MIPS이다 add및 addu트래핑 각각 오버 플로우를 무시하고있다. (또 sub와 subu.) 그것은 에이다 같은 언어에 대한 명령의 첫 번째 유형을 필요로 (내 생각 - I've 실제로 에이다 불구을 사용하지 않음) 명시 적으로 오버 플로우와 오버 플로우를 무시 C와 같은 언어에 대한 두 번째 유형되는 거래.

올바르게 기억한다면 실제 CPU에는 오버플로를 추적하기 위해 ALU에 추가 회로가 있습니다. 사람들이 관심을 가진 유일한 언어가 C라면, 이것이 필요하지 않을 것입니다.

Burroughs 5000 시리즈는 ALGOL을 효율적으로 지원하도록 설계되었으며 Intel의 iAPX-432는 Ada를 효율적으로 실행하도록 설계되었습니다. Inmos Transputer의 언어는 Occam입니다. Parallax "Propeller"프로세서는 자체 BASIC 변형을 사용하여 프로그래밍하도록 설계되었다고 생각합니다.

언어는 아니지만 VAX-11 명령 세트에는 프로세스 컨텍스트를로드하는 단일 명령이 있습니다.이 명령은 VMS 디자인 팀의 요청에 따라 설계되었습니다. 세부 사항은 기억 나지 않지만 ISTR은 구현하는 데 많은 지침이 필요하므로 예약 가능한 프로세스 수에 심각한 상한을 두었습니다.

지금까지 아무도 언급하지 않은 것 중 하나는 (기본 언어와 거의 관련이없는) 컴파일러 최적화의 발전이 CISC 명령어 세트 (사람이 코딩하도록 설계되어 있음)에서 RISC 명령어 세트 (대부분은 컴파일러에 의해 코딩되도록 설계되었습니다.)

Motorola 68000 제품군 은 CPU를 통한 데이터 복사를 매우 효율적이고 컴팩트하게 만드는 자동 증분 어드레스 모드 를 도입했습니다 .

[업데이트 된 예]

이것은 68000 어셈블러에 영향을 미치는 일부 C ++ 코드입니다.

while(someCondition)
    destination[destinationOffset++] = source[sourceOffset++]

기존 어셈블러에서 구현 (의사 코드, 68000 어셈블러 명령을 잊어 버렸습니다)

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1)
    move (adressRegister2), akku
    increment(adressRegister1, 1)
    increment(adressRegister2, 1)
}

새로운 adressmode를 사용하면

adressRegister1 = source
adressRegister2 = destination
while(someCondition) {
    move akku,(adressRegister1++)
    move (adressRegister2++), akku
}

루프 당 4 개 대신 2 개의 명령어 만.

IBM Z 시리즈 메인 프레임은 1960 년대 IBM 360의 후손입니다.

COBOL 및 Fortran 프로그램의 속도를 높이기 위해 특별히 작성된 몇 가지 지침이있었습니다. 전형적인 예는 BXLE– Fortran for루프 또는 PERFORM VARYING x from 1 by 1 until x > n단일 명령어로 캡슐화 된 COBOL 의 대부분인 "지수가 낮거나 같음"입니다 .

COBOL 프로그램에서 공통으로 사용되는 고정 소수점 10 진 산술을 지원하기 위해 팩형 10 진 명령어 제품군이 있습니다.

초기 인텔 CPU에는 다음과 같은 기능이 있으며 현재 64 비트 모드에서 더 이상 사용되지 않습니다.

• ENTER, LEAVE 및 RET nn 명령어 [초기 매뉴얼에는 블록 구조 언어 (예 : 중첩 프로 시저를 지원하는 파스칼)에 대해 소개 된 내용이 명시되어 있음)
• BCD 산술 속도를 높이기위한 지침 (AAA, AAM 등); x87의 BCD 지원
• 카운트 루프 구현을위한 JCXZ 및 LOOP 명령어
• INTO, 산술 오버플로에 트랩 생성 (예 : Ada)
• 테이블 조회를위한 XLAT
• 배열 경계를 확인하기위한 BOUND

많은 CPU의 상태 레지스터에있는 부호 플래그는 부호있는 및 부호없는 산술을 쉽게 수행하기 위해 존재합니다.

SSE 4.1 명령어 세트는 카운트 및 제로 종료 (PCMPESTR 등) 문자열 처리 명령어를 소개합니다.

또한 여러 시스템 수준 기능이 컴파일 된 코드 (세그먼트 제한 검사, 매개 변수 복사를 통한 호출 게이트 등)의 안전을 지원하도록 설계되었다고 생각할 수 있습니다.

일부 ARM 프로세서 (주로 모바일 장치의 프로세서)에는 하드웨어 JVM 인터프리터 인 Jazelle 확장이 포함됩니다. Java 바이트 코드를 직접 해석합니다. Jazelle을 인식하는 JVM은 하드웨어를 사용하여 실행 속도를 높이고 많은 JIT를 제거 할 수 있지만, 바이트 코드를 칩에서 해석 할 수없는 경우 소프트웨어 VM으로의 대체는 여전히 보장됩니다.

이러한 장치가있는 프로세서에는 BXJ 명령어가 포함되어 프로세서를 특수 "Jazelle 모드"로 설정하거나 장치 활성화에 실패한 경우 일반 분기 명령어로 해석됩니다. 장치는 ARM 레지스터를 재사용하여 JVM 상태를 유지합니다.

Jazelle 기술의 후속 제품은 ThumbEE입니다

내가 아는 한 이것은 과거에 더 흔했습니다.

이 질문의 세션 제임스 고슬링 (James Gosling)이 JVM 바이트 코드와 더 나은 거래 수있는 하드웨어를 만들려고 노력하는 사람이었다, 그러나이 사람들이 아마 컴파일 (공통 "일반적인"인텔의 x86와 함께 할 수있는 방법을 찾을 것이라고 말했다되는이 영리한 방식으로 바이트 코드).

그는 일반 대중 칩 (인텔 등)을 사용하면 제품에 막대한 금액의 돈을 버는 대기업이 있기 때문에 이점이 있다고 언급했다.

비디오 확인 가치가 있습니다. 그는 19 분 또는 20 분에 이에 대해 이야기합니다.

빠른 페이지 검색을했는데 아무도 Forth 를 실행하기 위해 CPU가 개발되었다고 언급하지 않은 것 같습니다 . 넷째 프로그래밍 언어는 스택 컴팩트 기반의 제어 시스템에 사용된다.

인텔 iAPX CPU는 특히 객체 지향 언어에 대한 설계되었습니다. 그래도 해결되지 않았습니다.

iAPX 432 ( 인텔 고급 프로세서 아키텍처는 ) 세 집적 회로의 집합으로 1981 년에 도입 된 인텔 최초의 32 비트 마이크로 프로세서 설계했다. 1980 년대 인텔의 주요 디자인으로 많은 고급 멀티 태스킹 및 메모리 관리 기능을 구현했습니다. 따라서이 디자인을 마이크로 메인 프레임 이라고합니다 .

iAPX 432는 "고급 언어로 완전히 프로그래밍되도록 설계되었습니다" 는 Ada 를 기본 으로하며 하드웨어 및 마이크로 코드 에서 직접 객체 지향 프로그래밍 및 가비지 수집을 지원 했습니다 . 다양한 데이터 구조 에 대한 직접적인 지원 은 iAPX 432의 최신 운영 체제가 일반 프로세서보다 훨씬 적은 프로그램 코드를 사용하여 구현 될 수 있도록하기위한 것입니다. 이러한 특성과 특징으로 인해 하드웨어 및 마이크로 코드 설계는 그 당시 대부분의 프로세서, 특히 마이크로 프로세서보다 훨씬 더 복잡했습니다.

인텔의 엔지니어들은 당시의 반도체 기술을 사용하여 디자인을 매우 효율적인 첫 번째 구현으로 변환 할 수 없었습니다. 조기 Ada 컴파일러의 최적화 부족과 함께, 이는 느리지 만 고가의 컴퓨터 시스템에 기여했으며, 동일한 클록 주파수 (1982 년 초)에서 새로운 80286 칩 속도의 약 1/4 속도로 일반적인 벤치 마크를 수행했습니다.

다소 낮은 프로파일과 저렴한 가격의 8086 라인에 대한 초기 성능 차이는 아마도 인텔이 후자 (나중에 x86)를 iAPX 432로 교체하려는 주된 이유 일 것입니다. 엔지니어들은 차세대 설계를 개선 할 수있는 방법을 찾았지만 iAPX 432 기능 아키텍처 는 이제 단순화 된 지원이 아니라 구현 오버 헤드로 간주되기 시작했습니다.

iAPX 432 프로젝트는 인텔의 상업적 실패였습니다 ...

68000에는 많은 언어가 예상하는 단일 명령으로 여러 레지스터를 스택에 푸시하는 데 가장 적합한 MOVEM이있었습니다.

코드 전체에서 JSR (Jump SubRoutine) 앞에 MOVEM (MOVE Multiple)이 있으면 C 준수 코드를 처리하고 있다는 것을 알 수 있습니다.

MOVEM을 사용하면 대상 레지스터의 자동 증분을 허용하여 각 사용이 대상에 계속 스태킹되거나 자동 감소의 경우 스택에서 제거 할 수 있습니다.

http://68k.hax.com/MOVEM

Atmel의 AVR 아키텍처는 완전히 C부터 프로그래밍하기에 적합하도록 처음부터 설계되었습니다. 예를 들어이 애플리케이션 노트는 더 자세히 설명합니다.

IMO 이것은 로켓과 밀접한 관련이 있습니다 .4kids의 탁월한 답변 . 직접 PIC 어셈블러는 직접 어셈블러 프로그래밍 (총 40 명령)을 위해 개발되었으며, 이후 가족은 C를 타겟팅합니다.

8087 숫자 형 코 프로세서가 설계되었을 때 언어에서 모든 부동 소수점 연산을 최고 정밀도 유형을 사용하여 정밀도가 낮은 변수에 할당 할 때 결과를 낮은 정밀도로 반올림하는 것이 일반적이었습니다. 예를 들어 원래 C 표준에서 시퀀스는 다음과 같습니다.

float a = 16777216, b = 0.125, c = -16777216;
float d = a+b+c;

촉진 것입니다 a및 b에 double홍보를 추가 c로 double결과가 반올림 저장 한 다음 추가하고 float. 컴파일러가 타입에 대해 직접 연산을 수행하는 코드를 생성하는 것이 더 빠를지라도 float, 타입 에 대해서만 작동하는 부동 소수점 루틴 세트 double를 변환하는 루틴과 함께 사용 하는 것이 더 간단했습니다. 에서 float의 작업을 처리하는 루틴의 별도의 세트를 가지고하는 것보다, float하고 double. 8087은 80 비트 부동 소수점 유형 [80 비트가 다음과 같은 이유로 선택되었을 수 있음]을 사용하여 모든 산술 연산을 수행하는 산술 접근 방식을 중심으로 설계되었습니다.

1. 많은 16 비트 및 32 비트 프로세서에서 가수와 지수 사이에서 바이트를 나누는 값으로 작업하는 것보다 64 비트 가수와 별도의 지수로 작업하는 것이 더 빠릅니다.

2. 사용하는 숫자 유형의 전체 정밀도에 정확한 계산을 수행하는 것은 매우 어렵습니다. 예를 들어 log10 (x)와 같은 것을 계산하려는 경우 64 비트의 1ulp 내에서 정확한 결과를 계산하는 것보다 80-bit 유형의 100ulp 내에서 정확한 결과를 계산하는 것이 더 쉽고 빠릅니다. 이전 결과를 64 비트 정밀도로 반올림하면 후자보다 정확한 64 비트 값이 생성됩니다.

불행히도, 이후 버전의 언어는 부동 소수점 유형이 작동하는 방식의 의미를 변경했습니다. 만약 언어가 일관되게 언어를 지원했다면 8087 의미론은 매우 좋았을 것인데, 함수 f1 (), f2 () 등이 type을 반환 float한다면, 많은 컴파일러 제작자들이 long double64 비트 double 형의 별칭 을 만들기 위해 그것을 취할 것입니다. 컴파일러의 80 비트 유형이 아니라 (80 비트 변수를 만드는 다른 방법을 제공하지 않음) 다음과 같이 임의로 평가하십시오.

double f = f1()*f2() - f3()*f4();

다음과 같은 방법으로 :

double f = (float)(f1()*f2()) - (extended_double)f3()*f4();
double f = (extended_double)f1()*f2() - (float)(f3()*f4());
double f = (float)(f1()*f2()) - (float)(f3()*f4());
double f = (extended_double)f1()*f2() - (extended_double)f3()*f4();

f3 및 f4가 각각 f1 및 f2와 동일한 값을 반환하면 원래 식은 분명히 0을 반환해야하지만 후자 식 중 많은 식은 그렇지 않을 수 있습니다. 마지막 공식이 일반적으로 세 번째보다 우수하지만 확장 된 이중 유형을 적절하게 사용하는 코드를 사용하면 거의 열등하지 않더라도 8087의 "초정밀"을 비난하는 사람들로 이어졌습니다.

그 사이에 인텔은 그 이후의 프로세서를 설계하여 더 높은 성능을 사용함으로써 이익을 얻을 수있는 코드를 손상 시키도록 후반 프로세서를 설계함으로써 중간 결과를 피연산자의 정밀도로 반올림하도록하는 언어 (IMHO 불행한 경향) 추세에 응답했습니다. 중간 계산의 정밀도.