고급 언어 컴퓨터 아키텍처

High-level language computer architecture

High Level Language Computer Architecture(HLLCA; 고급 언어 컴퓨터 아키텍처)는 하드웨어 고려사항에 따라 아키텍처가 지시되는 것이 아니라 특정 High Level Programming Language(HLL; 고급 프로그래밍 언어)에 의해 타깃이 되도록 설계된 컴퓨터 아키텍처입니다.따라서 McKeeman(1967)에서 만들어졌으며 주로 1960년대와 1970년대에 사용된 언어 지향 컴퓨터 디자인이라고도 불립니다.HLLCA는 1960년대와 1970년대에 유행했지만 1980년대에 대부분 사라졌다.이것은 인텔 432(1981)의 극적인 장애와 컴파일러최적화와 명령어 세트 컴퓨터(RISC) 아키텍처와 RISC와 같은 복합 명령어 세트 컴퓨터(CISC) 아키텍처의 등장과 HLLS용 JIT(Just-In-Time Compilation)의 개발로 이어졌습니다.상세한 조사와 비평은 Ditzel & Patterson(1980)에서 확인할 수 있다.

HLLCA는 최초의 HLL 중 하나인 ALGOL 60(1960)을 위해 설계된 Burroughs 대형 시스템(1961년)에서 HLLs의 시작까지 거슬러 올라간다.가장 잘 알려진 HLLCA는 리스프(1959년)라는 언어의 1970년대와 1980년대의 리스프 기계일 수 있습니다.현재 가장 인기 있는 HLLCA는 Java 언어용 Java 프로세서(1995년)입니다.이것들은 특정 어플리케이션에서 사용되고 있는 검증된 성공입니다.이러한 맥락에서 최근 아키텍처는 HSA Intermediate Layer(HSAIL)가 예외나 가상 기능 등의 HLL 기능을 지원하는 이기종 시스템 아키텍처(2012)입니다.이는 JIT를 사용하여 성능을 보증합니다.

정의.

이 제목에는 매우 다양한 시스템이 있습니다.가장 극단적인 예는 Direct Executed Language입니다.여기서 컴퓨터의 명령어 집합 아키텍처(ISA)는 HLL의 명령어와 동일하며 소스 코드는 최소한의 처리로 직접 실행할 수 있습니다.극단적인 경우 소스 코드를 토큰화하고 토큰을 프로세서에 직접 공급하기만 하면 됩니다.이것은 스택머신에서 실행되는 스택 지향 프로그래밍 언어에서 볼 수 있습니다.보다 일반적인 언어의 경우 HLL 문은 명령 + 인수로 그룹화되어 infix 순서가 prefix 또는 postfix 순서로 변환됩니다.DEL은 1970년대에 [1]주창되었지만 일반적으로 가설에 불과하다.

덜 극단적인 예에서는 소스 코드가 먼저 바이트 코드로 구문 분석되고 바이트 코드는 프로세서에 전달되는 기계 코드입니다.이러한 경우, 컴파일러가 충분한 것으로 간주되기 때문에 시스템에는 일반적으로 어셈블러가 없습니다.단, 어떤 경우(Java 등), 어셈블러는 컴파일러에 의해 출력되지 않는 합법적인 바이트 코드를 생성하기 위해 사용됩니다.이 접근법은 Pascal MicroEngine(1979)에서 발견되었으며 현재 Java 프로세서에서 사용되고 있습니다.

좀 더 대략적으로 말하면, HLLCA는 특정 HLL 또는 여러 HLL을 지원하는 기능을 가진 범용 컴퓨터 아키텍처일 수 있습니다.이는 1970년대 이후 Lisp 머신에서 발견되었으며, Lisp를 지원하기 위해 특별히 설계된 오퍼레이션으로 범용 프로세서를 확장했습니다.

Burroughs Large Systems(1961)는 최초의 HLLCA로 최초의 HLL 중 하나인 ALGOL(1959)을 지원하기 위해 설계되었습니다.이것은 그 당시에 "언어 지향 디자인"이라고 불렸다.Burroughs Medium Systems(1966)는 비즈니스 애플리케이션용 COBOL을 지원하도록 설계되었습니다.Burroughs Small Systems(1970년대 중반, 1960년대 후반부터 설계)는 쓰기 가능한 제어 저장소에서 여러 HLL을 지원하도록 설계되었습니다.이것들은 모두 메인프레임이었습니다.

Wang 2200(1973) 시리즈는 마이크로 코드의 BASIC 인터프리터를 사용하여 설계되었습니다.

Pascal MicroEngine(1979)은 Pascal의 UCSD Pascal 형식을 위해 설계되었으며 기계 코드로 p-code(Pascal 컴파일러 바이트 코드)를 사용했습니다.이는 Java 및 Java 머신의 향후 개발에 영향을 미쳤다.

리스프 머신(1970년대와 1980년대)은 HLLCA의 유명하고 영향력 있는 그룹이었다.

인텔 iAPX 432(1981)는 Ada를 지원하도록 설계되었습니다.이것은 인텔 최초의 32비트 프로세서 설계로, 1980년대 인텔의 메인 프로세서 패밀리를 목표로 하고 있었지만, 상업적으로는 실패했습니다.

Rekursiv(1980년대 중반)는 하드웨어에서 객체 지향 프로그래밍과 링고 프로그래밍 언어를 지원하도록 설계된 마이너 시스템이며 명령 집합 수준에서 재귀(recursion)를 지원하므로 이름이 붙여졌다.

1980년대 후반과 1990년대 초에 Prolog를 보다 직접적으로 구현하기 위한 다수의 프로세서와 코프로세서가 설계되었으며, 여기에는 버클리 VLSI-PLM, 그 후계기(PLUM), 관련 마이크로코드 구현 등이 포함됩니다.또한 초전도체용 Prolog 프로세서Prolog 코프로세서설계하기 위한 하드웨어 A VHDL 기반 방법론으로는 생산되지 않은 시뮬레이션 설계도 다수 있었습니다.Lisp와 마찬가지로 Prolog의 기본적인 계산 모델은 표준적인 명령형 설계와는 근본적으로 다르며, 컴퓨터 과학자와 전기 엔지니어는 기본 모델을 에뮬레이트함으로써 야기되는 병목 현상을 극복하고자 했습니다.

Niklaus Worth의 Lilith 프로젝트에는 Modula-2 언어에 [2]맞춘 커스텀 CPU가 포함되어 있습니다.

INMOS 트랜스푸터ocam을 사용한 동시 프로그래밍을 지원하도록 설계되었습니다.

AT&T Hobbit 프로세서는 C-language Reduced Instruction Set Processor (C-language Reduced Instruction Set Processor)라고 불리는 설계에서 비롯되었으며, C 코드를 실행하도록 최적화되었다.

1990년대 후반에는 Sun Microsystems와 다른 기업들이 스택 기반 Java 가상 머신을 직접(또는 밀접하게) 구현하는 CPU를 구축하려는 계획이 있었습니다.그 결과, 몇의 Java 프로세서가 구축되어 사용되고 있습니다.

에릭슨Erlang[3]실행하도록 설계된 프로세서인ECOMP를 개발했습니다.그것은 상업적으로 생산된 적이 없다.

이기종 시스템 아키텍처(2012)의 HSA Intermediate Layer(HSAIL)는 기반이 되는 ISA에서 추상화하기 위한 가상 명령 세트를 제공하며 예외 및 가상 기능 등의 HLL 기능을 지원하고 디버깅 지원을 포함합니다.

실행

HLLCA는 스택 머신(Burroughs Large Systems 및 Intel 432 등)을 통해 구현되는 경우가 많고 프로세서(Burroughs Small Systems 및 Pascal MicroEngine 등)의 마이크로 코드를 통해 구현됩니다.태그 부착 아키텍처는 (Burroughs Large Systems 및 Lisp 머신과 같이) 유형을 지원하기 위해 자주 사용됩니다.보다 급진적인 예는 비-본 노이만 아키텍처를 사용하지만, 이는 일반적으로 가상적인 제안일 뿐 실제 구현은 아닙니다.

어플

일부 HLLC는 고속 컴파일과 높은 수준의 언어로 시스템을 제어하기 위해 개발자 머신(워크스테이션)으로 특히 인기가 있습니다.Pascal MicroEngine과 Lisp 머신이 그 좋은 예입니다.

HLLCA는 HLL이 명령형 프로그래밍(일반 프로세서에 비교적 적합한)과 근본적으로 다른 계산 모델을 가지고 있을 때 주로 기능 프로그래밍(Lisp)과 논리 프로그래밍(Prolog)에 대해 권장되어 왔습니다.

동기

Ditzel & Patterson(1980)에 추정상의 장점에 대한 자세한 목록이 나와 있다.

HLLCA는 직관적으로 매력적입니다.컴퓨터는 원칙적으로 언어에 맞게 커스터마이즈할 수 있기 때문에 언어를 최적으로 지원할 수 있고 컴파일러 기입을 단순화할 수 있습니다.마이크로코드 변경만으로 여러 언어를 네이티브하게 지원할 수 있습니다.개발자에게 중요한 장점은 빠른 컴파일과 머신의 상세한 심볼 디버깅입니다.

또 다른 장점은 마이크로코드(펌웨어)를 갱신함으로써 언어 구현을 갱신할 수 있다는 것입니다.시스템 전체의 재컴파일을 필요로 하지 않습니다.이는 통역된 언어의 인터프리터를 업데이트하는 것과 유사합니다.

2000년 이후 다시 나타나는 이점은 안전 또는 보안입니다.메인스트림 IT는 대부분의 애플리케이션에서 유형 및/또는 메모리 안전성을 갖춘 언어로 이행하고 있습니다.OS에서 가상 머신에 이르기까지 사용되는 소프트웨어는 보호 없이 네이티브 코드를 활용합니다.이러한 코드에서는 많은 취약성이 발견되었습니다.하나의 솔루션은 안전한 고급 언어를 실행하거나 최소한 유형을 이해할 수 있도록 맞춤형 프로세서를 사용하는 것입니다.프로세서 워드 수준의 보호는 스칼라 데이터, 배열, 포인터 또는 코드를 구분하지 않는 낮은 수준의 시스템에 비해 공격자의 작업을 어렵게 합니다.학계에서는 향후 고급 프로세서와 통합될 수 있는 유사한 특성을 가진 언어도 개발하고 있습니다.이러한 경향의 예로는 SAFE 프로젝트가[4] 있습니다.소프트웨어(특히 운영체제)가 안전한 고급 언어를 기반으로 하는 언어 기반 시스템을 비교합니다.다만 하드웨어가 반드시 필요한 것은 아닙니다.「신뢰할 수 있는 기반」은 아직 하위 레벨의 언어일 수 있습니다.

단점들

상세한 비평은 Ditzel & Patterson(1980)에 실려 있다.

HLLCA가 성공하지 못한 가장 간단한 이유는 1980년부터 컴파일러 최적화를 통해 마이크로코드로 언어를 구현하는 것보다 훨씬 빠른 코드가 생성되고 개발하기가 쉬워졌기 때문입니다.많은 컴파일러 최적화에서는 코드의 복잡한 분석과 재배치가 필요하기 때문에 머신 코드는 원래의 소스 코드와는 매우 다릅니다.이러한 최적화는 복잡성과 오버헤드로 인해 마이크로 코드로 구현하기가 불가능하거나 실용적이지 않습니다.유사한 성능 문제는 인터프리터 언어(Lisp(1958년)로 오랜 역사를 가지고 있으며, Just-in-Time 컴파일을 통해 실용적으로 해결되었으며, Self에서 개척되어 HotSpot Java 가상 머신(1999)에서 상용화되었습니다.

근본적인 문제는 HLLCA가 컴파일러의 코드 생성 단계를 단순화할 뿐이라는 것입니다.이것은 컴파일러의 일반적인 컴파일러는 컴파일러의 비교적 작은 부분이며, 컴퓨팅 파워(트랜지스터 및 마이크로코드)의 사용이 의심스럽다는 것입니다.최소한 토큰화가 필요하며 통사 분석과 기본적인 의미 확인(무제한 변수)은 계속 수행되므로 프런트 엔드에 이점이 없고 최적화를 위해서는 사전 분석이 필요하므로 미들 엔드에 이점이 없습니다.

2014[업데이트],[5]의 같은 깊은 문제, 개발의 여전히 활발한 지역 때문에 편집(특히 최적화)은 기계어 명령기의 원본을 결정하게 만드는 것은 기계 코드에서 HLL을 디버깅 하는 정보를 제공하는 꽤, 디버깅 정보에 드는 비용 기본적으로 때문에, 그리고 더 미묘하게 어렵게 되었다는 것이다.기 관련된따라서 HLLCA의 필수적인 부분으로 제공되는 디버깅 정보는 구현을 심각하게 제한하거나 통상적인 사용에서 상당한 오버헤드를 증가시킵니다.

또한 HLLCA는 일반적으로 한 가지 언어에 최적화되어 있어 다른 언어를 더 잘 지원하지 않습니다.다국어 가상 머신에서도 유사한 문제가 발생합니다.특히 Java 가상 머신(Java 용으로 설계)과 。NET Common Language Runtime(C#으로 설계).다른 언어는 2등급 시민이며 의미론에서 메인 언어에 밀접하게 준거해야 하는 경우가 많습니다.이 때문에 컴파일러가 지원되면 하위 레벨의 ISA에서는 여러 언어를 충분히 지원할 수 있습니다.다만, 언어 중립적인 프로세서의 많은 경우에도 같은 문제가 발생합니다.이 프로세서는 언어 C에 의해 충분히 지원되며 (하드웨어를 직접 대상으로 하는 것이 아니라) C로 변환하면 효율적인 프로그램 및 단순한 컴파일러가 생성됩니다.

HLLCA의 장점은 주로 컴파일러 또는 인터프리터를 통해 HLL Computer Systems(언어 기반 시스템)에서 대체적인 방법으로 달성할 수 있습니다.시스템은 아직 HLL로 기술되어 있지만 하위 아키텍처에서 실행되는 소프트웨어는 신뢰할 수 있는 기반이 있습니다.예를 들어 런타임 환경 자체는 C로 작성되지만 운영 체제와 애플리케이션은 Java로 작성되는 Java 시스템입니다.

대체 수단

1980년대 이후 범용 컴퓨터 아키텍처에 대한 연구 및 구현의 초점은 주로 RISC와 같은 아키텍처에 있었습니다.일반적으로 내부적으로는 레지스터가 풍부한 스토어 아키텍처입니다.다중 언어 고유의 ISA는 여러 레지스터, 파이프라인 및 보다 최근의 멀티코어 시스템을 갖추고 있습니다.사용자 고유의 ISA언어 지원은 컴파일러와 그 런타임, 인터프리터와 그 가상 머신(특히 JIT)에 초점을 맞추고 있으며 하드웨어의 직접적인 지원은 거의 없습니다.예를 들어 현재 iOS용 Objective-C 런타임은 하드웨어가 태그 부착 아키텍처가 아님에도 불구하고 유형 검사 및 가비지 수집에 사용하는 태그 부착 포인터를 구현합니다.

컴퓨터 아키텍처에서 RISC 접근법은 매우 인기 있고 성공적이라는 것이 증명되었습니다.또한 HLLCA와는 반대로 매우 심플한 명령어 세트아키텍처를 강조하고 있습니다.그러나 1980년대 RISC 컴퓨터의 속도 이점은 주로 RISC의 [citation needed]본질적인 이점보다는 온칩 캐시의 조기 도입과 대규모 레지스터를 위한 공간 확보에 기인했습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ Yaohan Chu 참조.
  2. ^ "Pascal for Small Machines – History of Lilith". Pascal.hansotten.com. 28 September 2010. Retrieved 12 November 2011.
  3. ^ http://www.erlang.se/euc/00/processor.ppt
  4. ^ http://www.crash-safe.org[데드링크]
  5. ^ LLVM 및 Clang 컴파일러를 참조하십시오.

추가 정보