인터프리터(컴퓨팅)

Interpreter (computing)
W3s 디자인 인터프리터 디자인 패턴 UML
프로그램 실행
일반개념
코드 종류
컴파일 전략
주목할 만한 런타임
주목할 만한 컴파일러 및 공구 체인

컴퓨터 과학에서 통역은 이전에 기계 언어 프로그램으로 편성된 명령어를 요구하지 않고 프로그래밍이나 스크립팅 언어로 작성된 명령어를 직접 실행하는 컴퓨터 프로그램이다.통역사는 일반적으로 프로그램 실행을 위해 다음 전략 중 하나를 사용한다.

  1. 소스 코드를 구문 분석하여 해당 동작을 직접 수행하십시오.
  2. 소스 코드를 효율적인 중간 표현 또는 개체 코드로 변환하고 즉시 실행하십시오.
  3. 컴파일러에 의해 만들어지고 인터프리터 가상 머신과 일치하는 저장된 사전 컴파일된 바이트[1] 코드를 명시적으로 실행하십시오.

초기 버전의 Lisp 프로그래밍 언어와 미니콤푸터와 마이크로컴퓨터 BASIC 사투리가 첫 번째 유형의 예일 것이다.Perl, Raku, Python, MATLAB, Ruby가 두 번째의 예이고 UCSD Pascal이 세 번째 유형의 예다.소스 프로그램은 사전에 컴파일되어 기계 독립 코드로 저장되며, 이는 런타임에 연결되고 통역자 및/또는 컴파일러(JIT 시스템용)에 의해 실행된다.Smalltalk와 BASIC과 Java의 현대 버전과 같은 일부 시스템도 2와 3을 결합할 수 있다.[2]알골, 포트란, 코볼, C, C++ 등 전통적으로 편찬과 관련된 여러 언어에 대해서도 다양한 유형의 통역사가 구성되었다.

해석과 편찬은 프로그래밍 언어가 구현되는 두 가지 주요 수단이지만, 대부분의 해석 시스템도 컴파일러와 마찬가지로 일부 번역 작업을 수행하기 때문에 상호 배타적이지 않다."해석된 언어" 또는 "컴파일된 언어"라는 용어는 해당 언어의 표준 구현이 각각 통역관 또는 컴파일러임을 의미한다.높은 수준의 언어는 이상적으로 특정 구현과 무관한 추상화다.

역사

1952년부터는 당시 컴퓨터의 한계 내에서 프로그래밍을 용이하게 하기 위해 통역사가 사용되었다(예: 프로그램 저장 공간 부족 또는 부동 소수점 번호에 대한 네이티브 지원 없음).낮은 수준의 기계어 간 번역에도 통역기가 사용되어, 아직 공사 중이고 이미 존재하는 컴퓨터에서 시험하고 있는 기계에 대한 코드가 작성될 수 있었다.[3]첫 번째로 해석된 고급 언어는 리스프였다.리스프는 스티브 러셀에 의해 1958년에 IBM 704 컴퓨터로 처음 구현되었다.러셀은 존 매카시의 논문을 읽었고, (매카시의 놀랍게도) 리스프 평가 기능이 기계 코드로 구현될 수 있다는 것을 깨달았다.[4]그 결과, Lisp 프로그램을 실행하는 데 사용될 수 있는, 또는 더 적절하게 "Lisp 표현식 평가"에 사용될 수 있는, 일하는 Lisp 통역사가 나왔다.

일반작업

통역사는 보통 실행할 수 있는 알려진 명령어 집합과 프로그래머가 실행하기를 원하는 순서대로 명령어 목록으로 구성된다.각 명령어(지침이라고도 함)에는 프로그래머가 변이하고자 하는 데이터와 데이터 변이 방법에 대한 정보가 들어 있다.예를 들어, 통역사는 읽을 수 있다.ADD Wikipedia_Users, 5그리고 5를 더하기 위한 요청으로 해석한다.Wikipedia_Users 가변의

통역사들은 다양한 업무를 수행하는데 특화된 다양한 지시사항을 가지고 있지만, 당신은 대부분의 통역사가 튜링을 완성할 수 있도록 기초 수학 연산, 분기, 기억 관리 등을 위한 통역사 지시를 흔히 발견할 것이다.많은 통역사들이 쓰레기 수거기, 디버거와도 긴밀하게 통합되어 있다.

컴파일러 대 인터프리터

연결 프로세스의 그림.개체 파일 및 정적 라이브러리가 새 라이브러리 또는 실행 파일로 결합됨

높은 수준의 언어로 작성된 프로그램은 어떤 종류의 통역기에 의해 직접 실행되거나 컴파일러(및 조립자 및 링커)에 의해 기계 코드로 변환되어 CPU가 실행된다.

컴파일러(및 조립자)는 일반적으로 컴퓨터 하드웨어에 의해 직접 실행 가능한 기계 코드를 생산하지만, 그들은 종종 (선택적으로) 객체 코드라고 불리는 중간 형태를 생산할 수 있다.이것은 기본적으로 동일한 기계별 코드지만 실행 가능한 블록(또는 모듈)을 식별 가능하고 다시 연결 가능하도록 만들기 위해 이름과 태그가 있는 기호 테이블로 증강된다.컴파일된 프로그램은 일반적으로 그러한 객체 코드 모듈의 라이브러리에 보관되는 빌딩 블록(기능)을 사용한다.링커는 단일 실행 파일을 형성하기 위해 응용프로그램의 오브젝트 파일과 라이브러리 파일을 결합(사전 작성)하는 데 사용된다.따라서 실행 파일을 생성하는 데 사용되는 개체 파일은 다른 시간에 생성되는 경우가 많으며 때로는 다른 언어(동일한 개체 형식을 생성할 수 있음)에 의해 생성되기도 한다.

낮은 수준의 언어(예: 어셈블리)로 작성된 간단한 통역기는 높은 수준의 언어의 기능을 구현하는 기능들을 구현하는 유사한 기계 코드 블록을 가지고 있을 수 있으며, 검색 표에서 함수의 입력이 해당 코드를 가리킬 때 실행될 수 있다.그러나 높은 수준의 언어로 쓰여진 통역자는 일반적으로 파스 트리를 생성한 다음 걷는 것, 또는 중간 소프트웨어 정의 지침을 생성하고 실행하는 것, 또는 둘 다와 같은 다른 접근법을 사용한다.

따라서 컴파일러와 통역사는 일반적으로 소스 코드(텍스트 파일)를 토큰으로 변환하고, 둘 다 파스 트리를 생성할 수 있으며(또는 그렇지 않을 수 있음), 둘 다 즉시 명령을 생성할 수 있다(스택 머신, 쿼드러플 코드 또는 기타 수단으로).기본적인 차이점은 (내장 또는 별도) 링커를 포함한 컴파일러 시스템이 독립 실행형 기계코드 프로그램을 생성하는 반면, 통역 시스템은 그 대신 고급 프로그램에 의해 기술된 동작을 수행한다는 것이다.

따라서 컴파일러는 명령문이나 함수가 실행될 때마다 통역자가 이 변환 작업의 일부를 수행해야 하는 동안 소스 코드 의미론에서 기계 수준으로 거의 모든 변환을 한 번, 그리고 모두를 위해(즉, 프로그램을 변경해야 할 때까지) 만들 수 있다.그러나 효율적인 통역관에서는 번역 작업(유형 등의 분석 포함)의 상당 부분이 프로그램, 모듈, 기능 또는 심지어 문장이 처음 실행될 때만 고려되고 수행되므로 컴파일러의 작동 방식과 상당히 유사하다.그러나 컴파일된 프로그램은 컴파일러가 코드를 최적화하도록 설계되어 있기 때문에 대부분의 상황에서 훨씬 더 빨리 실행되며, 이를 위한 충분한 시간이 주어질 수 있다.이는 동적 데이터 구조, 검사 또는 유형 확인 없이 보다 단순한 고급 언어의 경우에 특히 해당된다.

전통적인 컴파일에서 링크커(.exe 파일 또는 .dll 파일 또는 라이브러리, 그림 참조)의 실행 가능한 출력은 일반적으로 객체 코드 모듈과 유사하지만 이 재배치는 실행 시간에 동적으로 수행된다는 차이(즉, 프로그램을 실행하기 위해 로드하는 경우)와 함께 일반 운영 체제에서 실행될 때 다시 연결될 수 있다.반면에 소형 임베디드 시스템을 위한 컴파일 및 링크된 프로그램은 일반적으로 정적으로 할당되며, 이러한 의미에서 보조 스토리지가 없고 운영 체제가 없는 경우가 많기 때문에 NOR 플래시 메모리에 하드 코딩되기도 한다.

역사적으로 대부분의 통역 시스템에는 자급자족형 편집기가 내장되어 있다.일부 프로그래머들은 자신이 선택한 편집기를 사용하고 컴파일러, 링커 및 기타 도구를 수동으로 실행하는 것을 선호하지만 컴파일러(때로는 IDE라고 불림)에게도 이러한 현상이 더욱 일반화되고 있다.역사적으로 컴파일러는 통역사와 해석 코드 모두를 지원할 수 없었고, 당시의 일반적인 배치 환경은 해석의 장점을 제한했기 때문에 해석자가 해석자를 앞섰다.[5]

개발주기

소프트웨어 개발 주기 동안 프로그래머들은 소스코드를 자주 변경한다.컴파일러를 사용할 때, 소스 코드가 변경될 때마다, 그들은 프로그램이 실행되기 전에 컴파일러가 변경된 소스 파일을 번역하고 모든 이진 코드 파일을 함께 연결하기를 기다려야 한다.프로그램이 클수록 대기 시간이 길어진다.이와는 대조적으로, 통역을 사용하는 프로그래머는 보통 작업 중인 코드를 중간표현(또는 전혀 번역하지 않음)으로 번역하기만 하면 되기 때문에 훨씬 적은 시간을 들여야 변경사항을 시험할 수 있다.소스 코드를 저장하고 프로그램을 다시 로드할 때 효과가 명백하다.편집, 컴파일, 연결은 적절한 명령어 집합으로 적절한 순서에 따라 수행되어야 하는 순차적 과정이기 때문에 컴파일된 코드는 일반적으로 덜 쉽게 디버깅된다.이러한 이유로, 많은 컴파일러들도 Make file과 프로그램이라고 알려진 집행 보조 장치를 가지고 있다.Make file 목록에는 컴파일러 및 링커 명령줄과 프로그램 소스 코드 파일이 나열되지만 명령의 세 번째 그룹(세트)을 선택한 다음 컴파일러에 명령을 전송하고 지정된 소스 코드 파일을 공급하는 간단한 명령줄 메뉴 입력(예: "Make 3")을 사용할 수 있다.

분배

컴파일러는 소스 코드를 특정 프로세서의 아키텍처에 대한 이진 명령으로 변환하여 휴대성이 떨어지게 한다.이 변환은 개발자 환경에서 단 한 번만 이루어지며, 그 후에는 추가 변환 없이 실행될 수 있는 사용자 기계에 동일한 바이너리를 배포할 수 있다.교차 컴파일러는 코드가 컴파일되는 기계와 다른 프로세서를 가지고 있더라도 사용자 컴퓨터에 대한 이진 코드를 생성할 수 있다.

해석된 프로그램은 소스 코드로 배포될 수 있다.각 최종 기계에서 번역이 필요하며, 이는 시간이 더 걸리지만 프로그램 배포가 기계의 아키텍처와 무관하게 된다.그러나 해석된 소스 코드의 휴대성은 실제로 적합한 통역기를 가진 대상 시스템에 따라 달라진다.출처와 함께 통역을 공급해야 할 경우 통역사 자체가 설치해야 할 부분이기 때문에 전체적인 설치 과정이 단일 실행 파일의 전달보다 복잡하다.

해석된 코드를 인간이 쉽게 읽고 복사할 수 있다는 사실은 저작권의 관점에서 우려할 수 있다.그러나, 다양한 암호화 및 난독화 시스템이 존재한다.바이트 코드와 같은 중간 코드의 전달은 난독화와 유사한 효과가 있지만, 바이트 코드는 디컴파일러나 디스어셈블러로 해독될 수 있다.[citation needed]

효율성

통역사의 주요 단점은 번역된 프로그램이 편성되었을 때보다 일반적으로 느리게 실행된다는 것이다.속도의 차이는 작거나 클 수 있다; 종종 규모의 순서 그리고 때로는 그 이상이다.일반적으로 컴파일된 코드를 실행하는 것보다 통역사 밑에서 프로그램을 운영하는 데 시간이 더 걸리지만, 컴파일하고 실행하는 데 필요한 총 시간보다 해석하는 데 시간이 덜 걸릴 수 있다.이것은 편집-해석-디버그 주기가 편집-컴파일-실행-디버그 주기보다 훨씬 짧을 수 있는 경우 코드를 프로토타이핑하고 테스트할 때 특히 중요하다.[citation needed]

컴파일된 코드는 컴파일된 코드의 실행보다 느리는데, 인터프리터는 프로그램의 각 문장을 실행할 때마다 분석하고 원하는 동작을 수행해야 하는 반면 컴파일된 코드는 컴파일된 코드에 의해 결정된 고정된 컨텍스트 내에서 동작을 수행할 뿐이다.이 런타임 분석을 "해석 오버헤드"라고 한다.저장 위치에 대한 식별자 매핑은 컴파일 시간이 아니라 런타임에 반복적으로 이루어져야 하기 때문에 변수에 대한 접근도 통역기에서 더 느리다.[citation needed]

통역기를 사용할 때의 개발 속도와 컴파일러를 사용할 때의 실행 속도 사이에는 여러 가지 절충이 있다.일부 시스템(예: 일부 Lisps)은 해석 및 컴파일된 코드가 서로 호출하고 변수를 공유할 수 있도록 허용한다.즉, 일단 루틴을 테스트하고 통역사 아래에서 디버깅한 후에는 루틴을 컴파일할 수 있으며, 따라서 다른 루틴이 개발되는 동안 더 빠른 실행의 이점을 얻을 수 있다.[citation needed]많은 통역사들이 소스 코드를 그대로 실행하지 않고 좀 더 컴팩트한 내부 형태로 변환한다.많은 BASIC 인터프리터는 점프 테이블에서 명령을 찾는 데 사용할 수 있는 단일 바이트 토큰으로 키워드를 대체한다.PBASIC 인터프리터와 같은 소수의 인터프리터는 명령 토큰이 아마도 5비트를 차지하고 명목상 "16비트" 상수가 3, 6, 10 또는 18비트를 필요로 하는 가변 길이 코드에 저장되며 어드레스 피연산자를 포함하는 바이트 지향 프로그램 메모리 구조가 아닌 비트 지향적인 프로그램을 사용하여 훨씬 더 높은 수준의 프로그램 컴팩션을 달성한다.e "비트 오프셋".많은 BASIC 통역사는 그들 자신의 토큰화된 내부 표현을 저장하고 다시 읽을 수 있다.

해석자는 컴파일러와 동일한 어휘 분석기와 파서를 사용한 다음 추상 구문 트리를 해석할 수 있다.후자에 대한 데이터 유형 정의 예와 C 표현에서 얻은 구문 트리에 대한 장난감 통역기가 상자에 표시된다.

회귀

해석은 유일한 실행방법으로 사용할 수 없다. 통역자 자체가 해석될 수 있다 하더라도 해석되는 코드는 정의상 CPU가 실행할 수 있는 기계코드와 동일하지 않기 때문에 스택의 하단 어딘가에 직접 실행된 프로그램이 필요하다.[6][7]

변형

바이트코드 인터프리터

주요 기사:바이트코드

프로그램이 실행되기 전에 수행되는 분석의 양에 따라 해석과 컴파일 사이에는 다양한 가능성이 있다.예를 들어 Emacs Lisp는 바이트 코드로 컴파일되는데, 바이트 코드는 Lisp 소스의 고도로 압축되고 최적화된 표현이지만, 기계 코드는 아니다(따라서 특정 하드웨어에 연결되지 않음).이 "컴파일된" 코드는 바이트코드 통역기(그 자체가 C로 표기됨)에 의해 해석된다.이 경우 컴파일된 코드는 가상 머신에 대한 머신 코드로, 하드웨어가 아닌 바이트코드 인터프리터에 구현된다.이와 같이 편찬한 통역사를 편찬자로 부르기도 한다.[8][9]바이트코드 통역기에서 각 명령은 바이트로 시작하며, 따라서 바이트코드 통역기는 모든 명령을 사용할 수는 없지만 최대 256개의 명령을 가지고 있다.일부 바이트 코드는 여러 바이트가 소요될 수 있으며, 임의로 복잡할 수 있다.

컴파일 단계를 통과할 필요가 없는 제어 테이블은 바이트코드 인터프리터와 유사한 방식으로 사용자 정의된 인터프리터를 통해 적절한 알고리즘 제어 흐름을 지시한다.

스레드 코드 인터프리터

주요 기사:스레드 코드

스레드 코드 인터프리터는 바이트코드 인터프리터와 유사하지만, 바이트 대신 포인터를 사용한다.각 "지령"은 함수나 명령 시퀀스를 가리키는 말로, 매개 변수가 뒤따를 가능성이 있다.나사산 코드 통역기는 지시사항을 가져오는 것과 그들이 가리키는 기능을 호출하거나, 첫 번째 지시사항을 가져와서 그 지시로 건너뛰고, 모든 지시 순서는 가져오기 및 다음 지시로 건너뛰는 것으로 끝난다.바이트 코드와 달리 사용 가능한 메모리 및 주소 공간 외에 다른 명령의 수에 대한 효과적인 제한이 없다.스레드 코드의 전형적인 예는 Open Firmware 시스템에서 사용되는 Fours 코드로, 소스 언어는 "F code"(바이트 코드)로 컴파일되고, 이 코드는 가상 머신에 의해 해석된다.[citation needed]

추상 구문 트리 인터프리터

주 기사: 추상 구문 트리

해석과 컴파일 사이의 스펙트럼에서, 또 다른 접근방식은 소스 코드를 최적화된 추상 구문 트리(AST)로 변환한 다음, 이 트리 구조에 따라 프로그램을 실행하거나, 또는 네이티브 코드를 적시 생성하는데 이용하는 것이다.[10]이 접근법에서는 각 문장을 한 번만 구문 분석할 필요가 있다.바이트 코드에 대한 장점으로서 AST는 글로벌 프로그램 구조와 문 사이의 관계(바이트 코드 표현에서 손실됨)를 유지하고 압축되었을 때 보다 컴팩트한 표현을 제공한다.[11]따라서, AST를 사용하는 것은 바이트 코드보다 적시 컴파일러를 위한 더 나은 중간 포맷으로 제안되었다.또한, 그것은 시스템이 런타임 동안 더 나은 분석을 수행할 수 있게 해준다.

그러나 통역자의 경우 AST는 유용한 작업을 수행하지 않는 구문과 관련된 노드, 덜 순차적인 표현(더 많은 포인터의 통과 필요) 및 트리를 방문하는 오버헤드 때문에 바이트코드 통역기보다 더 많은 오버헤드를 발생시킨다.[12]

적시 컴파일

주요 기사:적시 컴파일

해석자, 바이트코드 해석자, 컴파일 간의 구분이 더욱 모호해지는 것은 JIT(Just-in-Time) 컴파일인데, 이것은 런타임에 중간표현을 네이티브 머신 코드에 컴파일하는 기법이다.이것은 바이트코드나 AST를 처음 컴파일할 때 시작 시간과 메모리 사용량을 증가시키는 비용으로 네이티브 코드 실행의 효율성을 방해한다.가장 먼저 발표된 JIT 컴파일러는 일반적으로 1960년 존 매카시에 의해 LISP에 관한 연구로 여겨진다.[13]적응 최적화는 통역자가 실행 중인 프로그램을 프로파일링하고 가장 자주 실행된 부분을 네이티브 코드로 컴파일하는 보완 기법이다.후자의 기술은 1980년대 스몰토크와 같은 언어로 등장하면서 몇 십 년 전의 것이다.[14]

Just-in-time 컴파일이 최근 몇 년 동안 언어 구현자들 사이에서 주목 받고 있는 것은 자바 입니다.NET Framework, 대부분의 최신 JavaScript 구현 및 J를 포함한 MatlabIT는 컴파일러를 컴파일러한다.[citation needed]

템플릿 인터프리터

컴파일러와 통역사를 구별하는 것은 템플릿 통역사라고 알려진 특별한 통역사 디자인이다.소프트웨어 스택이나 트리 워크에서 작동하면서 가능한 모든 바이트 코드를 포함하는 큰 스위치 문으로 코드의 실행을 구현하는 대신, 템플릿 해석기는 해당 네이티브 머신 지침에 직접 매핑된 많은 수의 바이트 코드(또는 모든 효율적인 중간 표현)를 유지한다.t는 "템플릿"이라고 알려진 [15][16]키 값 쌍으로 호스트 하드웨어에서 실행될 수 있다.특정 코드 세그먼트가 실행되면 통역자는 템플릿에 opcode 매핑을 로드하고 하드웨어에서 직접 실행하면 된다.[17][18]설계상 템플릿 해석기는 전통적인 해석기 보다는 Just-in-time 컴파일러와 매우 유사하지만, t에서 CPU 실행 명령의 최적화된 시퀀스를 만들어내기 보다는 언어의 코드를 한 번에 하나의 opcode로 변환할 뿐이라는 사실 때문에 기술적으로는 JIT가 아니다.전체 코드 분절이야직접 실행하기보다는 하드웨어에 직접 전화를 전달하는 단순 설계로 인해 다른 모든 유형, 심지어 바이트코드 통역기보다 훨씬 빠르고 버그 발생이 적은 정도까지 가능하지만, 다중 di로의 번역을 지원해야 하기 때문에 트레이드오프가 유지되기 어렵다.플랫폼 독립형 가상 머신/스택 대신 다른 아키텍처.현재까지 존재하는 언어의 템플릿 인터프리터 구현은 HotSpot/OpenJDK Java Virtual Machine 참조 구현 내의 인터프리터 구현뿐이다.[15]

셀프 인터프리터

주요 기사:메타 순환 평가자

자기 인터프리터는 자신을 해석할 수 있는 프로그래밍 언어로 쓰여진 프로그래밍 언어 통역이다. 예는 BASIC으로 쓰여진 BASIC이다.자기 인터프리터는 자기호스팅 컴파일러와 관련이 있다.

언어를 해석할 수 있는 컴파일러가 존재하지 않는 경우, 자체 인터프리터를 생성하려면 호스트 언어(다른 프로그래밍 언어 또는 조립자일 수 있음)로 언어를 구현해야 한다.이와 같은 첫 번째 통역을 갖게 됨으로써 시스템은 부트스트랩되고 새로운 버전의 통역을 언어 자체로 개발할 수 있게 된다.도널드 크누스가 산업용 표준 TeX형식 설정 시스템의 언어 WEB를 위한 TANGLE 통역기를 개발한 것은 이런 식이었다.

컴퓨터 언어를 정의하는 것은 보통 추상적인 기계(일명 운용 의미론)나 수학적인 함수(부정적 의미론)로서 이루어진다.언어는 또한 숙주 언어의 의미론이 주어지는 통역자에 의해 정의될 수 있다.자기간섭자에 의한 언어의 정의는 근거가 충분치 않다(언어를 정의할 수 없다). 그러나 자기간섭자는 독자에게 언어의 표현력과 우아함을 알려준다.또한 그것은 통역자가 자신의 소스 코드를 해석할 수 있게 하는데, 이것은 반사적 해석을 향한 첫 번째 단계다.

자가 인터프리터의 구현에서 중요한 설계 차원은 해석 언어의 특징이 통역자의 호스트 언어에서 동일한 기능으로 구현되는지 여부다.리스피어 같은 언어로 폐쇄가 통역사 언어로 폐쇄를 이용해 구현되는지, 아니면 환경을 명시적으로 저장하는 데이터 구조로 '수동적으로' 구현되는지 등이 그 예다.호스트 언어의 동일한 형상에 의해 구현되는 형상이 많을수록, 통역자의 프로그래머는 더 적은 제어력을 가지며, 산술 연산을 호스트 언어의 해당 연산에 위임하면 숫자 오버플로를 처리하기 위한 다른 행동을 실현할 수 없다.

Lisp와 Prolog와 같은 몇몇 언어들은 우아한 자기 상호작용을 한다.[19]자기간섭자(특히 반사적 해석자)에 대한 많은 연구가 Lisp의 방언인 Scheme 프로그래밍 언어로 수행되었다.그러나 일반적으로 튜링완성언어라면 어떤 언어라도 자신의 통역사를 쓸 수 있다.Lisp 프로그램은 기호 목록과 다른 목록이기 때문에 Lisp는 언어다.XSLT는 그러한 언어인데, XSLT 프로그램은 XML로 작성되기 때문이다. 메타프로그래밍의 하위 도메인은 도메인별 언어(DSL)의 작성이다.

클라이브 기포드는 N자간격기 스택을 실행하는 데 소요되는 컴퓨터 시간과 N자간격기 스택을 실행하는 데 소요되는 시간의 제한인 자기간격기의 측정 품질(유겐라티오)을[20] 도입했다.이 값은 실행 중인 프로그램에 따라 달라지지 않는다.

컴퓨터 프로그램의 구조와 해석이라는 책은 체계와 그 방언에 대한 메타원형 해석의 예를 제시한다.자가 인터프리터가 있는 언어의 다른 예로는 포스와 파스칼이 있다.

마이크로코드

주요 기사:마이크로코드

마이크로코드는 "컴퓨터의 하드웨어와 아키텍처 수준 사이에 통역을 부과하는" 매우 흔하게 사용되는 기술이다.[21]이와 같이 마이크로코드는 많은 디지털 처리 요소에서 더 높은 수준의 기계 코드 명령이나 내부 상태 기계 시퀀싱을 구현하는 하드웨어 수준 명령의 레이어다.마이크로코드는 범용 중앙처리장치뿐만 아니라 마이크로컨트롤러, 디지털신호프로세서, 채널컨트롤러, 디스크컨트롤러, 네트워크인터페이스컨트롤러, 네트워크프로세서, 그래픽처리장치, 기타 하드웨어 등 보다 전문화된 프로세서에 사용된다.

마이크로코드는 일반적으로 특수 고속 메모리에 저장되며 기계 명령, 주 기계 데이터 또는 기타 입력을 세부 회로 레벨 작동 시퀀스로 변환한다.기계 설명서를 기본 전자 장치와 분리하여 지시사항을 보다 자유롭게 설계하고 변경할 수 있도록 한다.또한 컴퓨터 회로의 복잡성을 줄이면서 복잡한 다단계 명령의 구축을 용이하게 한다.마이크로코드를 작성하는 것을 마이크로그램화라고 하며 특정 프로세서 구현에서 마이크로코드를 마이크로그램이라고 부르기도 한다.

보다 광범위한 마이크로코딩을 통해 소규모의 간단한 마이크로아키텍처들이 보다 넓은 워드 길이, 더 많은 실행 단위 등으로 보다 강력한 아키텍처를 에뮬레이트할 수 있으며, 이것은 프로세서 제품군의 다른 제품들 간에 소프트웨어 호환성을 얻을 수 있는 비교적 간단한 방법이다.

컴퓨터 프로세서

마이크로코딩이 아닌 컴퓨터 프로세서 자체도 기계코드 명령을 구문 분석하여 즉시 실행하는 시스템을 만들기 위해 VHDL과 같은 범용 하드웨어 기술 언어로 작성된 즉시 실행 통역기로 볼 수 있다.

적용들

  • 통역사는 명령어를 실행하는 데 자주 사용되며, 명령어로 실행되는 각 연산자는 대개 편집기나 컴파일러와 같은 복잡한 루틴을 호출하기 때문에 풀 언어가 사용된다.[citation needed]
  • 자체 수정 코드는 해석된 언어로 쉽게 구현될 수 있다.이는 리스프(Lisp)와 인공지능(AI) 연구의 해석 기원과 관련이 있다.[citation needed]
  • 가상화.하드웨어 아키텍처를 위한 시스템 코드는 가상 시스템을 사용하여 실행할 수 있다.이것은 의도된 아키텍처를 사용할 수 없을 때 또는 여러 개의 복사본을 실행할 때 종종 사용된다.
  • 샌드박스:일부 유형의 샌드박스는 운영 체제 보호에 의존하지만, 통역사나 가상 머신이 자주 사용된다.실제 하드웨어 아키텍처와 원래 의도된 하드웨어 아키텍처는 동일할 수도 있고 아닐 수도 있다.샌드박스가 처리 중인 소스 코드를 모두 실제로 실행하도록 강요되지 않는다는 점을 제외하면 이는 무의미해 보일 수 있다.특히 운영 중인 보안 제약사항을 위반하는 코드의 실행을 거부할 수 있다.[citation needed]
  • 더 현대적인 장비에서 쓸모없고 사용할 수 없는 하드웨어용으로 작성된 컴퓨터 소프트웨어를 실행하기 위한 에뮬레이터.

참고 항목

참조

  1. ^ 이런 의미에서 CPU는 기계지시의 통역사라고도 할 수 있다.
  2. ^ 비록 이 계획(결합 전략 2와 3)이 ABC 80의 효율적인 BASIC 통역기와 같은, 이미 1970년대에 시행된 특정 BASIC 통역사를 구현하기 위해 사용되었지만, 예를 들어, ABC 80의 효율적인 BASIC 통역사와 같은 것이다.
  3. ^ Bennett, J. M.; Prinz, D. G.; Woods, M. L. (1952). "Interpretative sub-routines". Proceedings of the ACM National Conference, Toronto.
  4. ^ 185페이지 해커스 앤 페인터스의 폴 그레이엄이 보도한 바에 따르면, 매카시는 "스티브 러셀이 말하길, "이 평가를 프로그램화하지 않을래?" 그리고 내가 그에게, 호, 호, 당신은 이론과 실습을 혼동하고, 이 평가는 컴퓨터용이 아니라 읽기를 위한 것이다.그러나 그는 앞서서 해냈다.즉, 그는 내 논문의 평가서를 IBM 704 기계코드로 편집하여 버그를 고친 다음, 이것을 리스프 통역사로 광고했는데, 확실히 그랬다.그래서 그 시점에서 리스프는 본질적으로 오늘날의 형태를 가지고 있었다.."
  5. ^ "Why was the first compiler written before the first interpreter?". Ars Technica. 8 November 2014. Retrieved 9 November 2014.
  6. ^ 테오도르 로머, 데니스 리, 제프리 M.Voelker, Alec Wolman, Wayne A.Wong, Jean-Loup Baer, Brian N. Bershad, Henry M.통역사의 레비, 구조와 부담금
  7. ^ 테렌스 파르, 요하네스 루버, 컴파일러와 인터프리터의 차이 2014-01-06년 웨이백 머신에 보관
  8. ^ Kühnel, Claus (1987) [1986]. "4. Kleincomputer - Eigenschaften und Möglichkeiten" [4. Microcomputer - Properties and possibilities]. In Erlekampf, Rainer; Mönk, Hans-Joachim (eds.). Mikroelektronik in der Amateurpraxis [Micro-electronics for the practical amateur] (in German) (3 ed.). Berlin: Militärverlag der Deutschen Demokratischen Republik [de], Leipzig. p. 222. ISBN 3-327-00357-2. 7469332.
  9. ^ Heyne, R. (1984). "Basic-Compreter für U880" [BASIC compreter for U880 (Z80)]. radio-fernsehn-elektronik [de] (in German). 1984 (3): 150–152.
  10. ^ AST 중간 표현, Ultimate 포럼 람다
  11. ^ Kistler, Thomas; Franz, Michael (February 1999). "A Tree-Based Alternative to Java Byte-Codes" (PDF). International Journal of Parallel Programming. 27 (1): 21–33. CiteSeerX 10.1.1.87.2257. doi:10.1023/A:1018740018601. ISSN 0885-7458. S2CID 14330985. Retrieved 2020-12-20.
  12. ^ Surfin's Safari - 블로그 아카이브 » 다람쥐피시 발표Webkit.org (2008-06-02)2013-08-10년에 검색됨.
  13. ^ Aycock 2003, 2. JIT 컴파일 기법, 2.1 Genesis, 페이지 98. CITREFAycock
  14. ^ L. Deutsch, A.쉬프만, 스몰토크-80 시스템의 효율적인 구현, 1984년 제11차 POPL 심포지엄의 진행.
  15. ^ a b "openjdk/jdk". GitHub. 18 November 2021.
  16. ^ https://openjdk.java.net/groups/hotspot/docs/RuntimeOverview.html#Interpreter
  17. ^ "Demystifying the JVM: JVM Variants, Cppinterpreter and TemplateInterpreter". metebalci.com.
  18. ^ "JVM template interpreter". ProgrammerSought.
  19. ^ 본도르프, 안데르스"Logimix: Prolog에 대해 자체 적용 가능한 부분 평가자."로직 프로그램 종합과 변환.1993년 런던 스프링거. 214-227.
  20. ^ Gifford, Clive. "Eigenratios of Self-Interpreters". Blogger. Retrieved 10 November 2019.
  21. ^ Kent, Allen; Williams, James G. (April 5, 1993). Encyclopedia of Computer Science and Technology: Volume 28 - Supplement 13. New York: Marcel Dekker, Inc. ISBN 0-8247-2281-7. Retrieved Jan 17, 2016.

외부 링크