인터프리터

3. 종류

인터프리터는 실행할 수 있는 명령어 집합과 실행 순서대로 나열된 명령어 목록으로 구성된다.^[3] 각 명령어는 변경하려는 데이터와 변경 방법에 대한 정보를 포함한다.^[3] 예를 들어, `ADD Books, 5`는 `Books` 변수에 5를 더하라는 요청으로 해석될 수 있다.^[3]

인터프리터는 다양한 작업을 위한 광범위한 명령어를 가지지만, 기본적인 수학 연산, 분기, 메모리 관리에 대한 명령어는 대부분의 인터프리터를 튜링 완전하게 만든다.^[3] 많은 인터프리터는 가비지 수집기 및 디버거와 통합되어 있다.^[3]

인터프리터는 소스 코드를 처리하는 방식에 따라 여러 종류로 나뉜다.

3. 1. 바이트코드 인터프리터

3. 2. 스레드 코드 인터프리터

3. 3. 추상 구문 트리 인터프리터

3. 4. JIT(Just-In-Time) 컴파일

3. 5. 자체 해석기

3. 6. 템플릿 인터프리터

4. 작동 방식

인터프리터는 실행 가능한 명령어 집합과 프로그래머가 실행하려는 순서대로 나열된 명령어 목록으로 구성된다. 각 명령어는 프로그래머가 변경하려는 데이터와 데이터를 변경하는 방법에 대한 정보를 포함한다. 예를 들어, 인터프리터는 `ADD Books, 5`를 읽고 이를 `Books` 변수에 5를 더하라는 요청으로 해석할 수 있다.

인터프리터는 다양한 작업을 수행하도록 특화된 광범위한 명령어를 가지고 있지만, 기본적인 수학 연산, 분기, 메모리 관리에 대한 명령어들을 일반적으로 찾을 수 있으며, 이는 대부분의 인터프리터를 튜링 완전하게 만든다. 많은 인터프리터는 가비지 수집기 및 디버거와 긴밀하게 통합되어 있다.

인터프리터는 각 가상 명령에 연결된 명령 본체와 디스패치 기구를 가지며, 호스트 머신에서 실행 가능하다. 가상 명령군으로 구성된 코드를 인수로 인터프리터가 실행되면 가상 명령에 따라 제어가 이동하고 해당 명령 본체가 실행된다. 이를 반복함으로써 인터프리터는 코드를 실행한다.

인터프리터 방식은 컴파일러 방식보다 실행 속도가 느린 경향이 있는데, 컴파일러는 프로그램 내 문 해석을 실행 전에 한 번만 수행하지만, 인터프리터는 문마다, 실행 시마다 반복하기 때문이다.

4. 1. 명령 본체

4. 2. 디스패치

5. 컴파일러와의 비교

고급 프로그래밍 언어로 작성된 프로그램은 인터프리터에 의해 직접 실행되거나, CPU가 실행할 수 있도록 컴파일러(및 어셈블러와 링커)에 의해 기계어로 변환된다. 컴파일러는 소스 코드에서 기계어 수준으로의 거의 모든 변환을 한 번에 수행하는 반면, 인터프리터는 문장이나 함수가 실행될 때마다 이 변환 작업의 일부를 수행한다.^[5] 효율적인 인터프리터에서는 많은 변환 작업이 분리(factor out)되어 프로그램, 모듈, 함수 또는 문장이 처음 실행될 때만 수행되므로, 컴파일러의 작동 방식과 매우 유사하다.

컴파일러 시스템은 링커를 포함하여 독립 실행형 기계어 프로그램을 생성하는 반면, 인터프리터 시스템은 고급 프로그램에서 설명하는 작업을 수행한다.^[5]

전통적인 컴파일에서 링커의 실행 가능한 출력은 일반 운영 체제에서 실행될 때 재배치 가능하며, 오브젝트 코드 모듈과 유사하지만 이 재배치가 실행을 위해 프로그램을 로드할 때 동적으로(런타임에) 수행된다는 차이점이 있다.

프로그래밍 언어 처리계의 구현에는 인터프리터와 컴파일러 두 가지가 있다고 여겨져 왔다. 인터프리터는 실행을 수행하지만, 컴파일러는 실행을 수행하지 않는다는 차이가 있다.

일반적으로 인터프리터의 장점과 단점은 다음과 같이 설명된다.

• 장점: 프로그램을 작성하는 도중에도 일단 작성된 부분까지 실행할 수 있으며, 프로그래머가 기대한 대로 동작하는지, 혹은 기대와 다르게 동작하는지 조기에 확인하고 발견할 수 있다. 수정 후 빠르게 실행하여 재확인할 수 있다.
• 단점: 실행 속도가 느리다. 루프 부분 등에서는 한 번 구문 해석한 문장도 매번 새롭게 처음부터 해석과 실행을 하므로 컴파일러 방식에 비해 실행 속도가 느리다.

6. 장점과 단점

인터프리터 방식은 컴파일러 방식에 비해 실행 속도가 느리다는 단점이 있다. 컴파일러는 프로그램 실행 전에 전체 코드를 한 번에 기계어로 변환하지만, 인터프리터는 코드를 한 줄씩 읽고 실행할 때마다 해석 및 변환 과정을 거치기 때문이다.

단순한 인터프리터의 경우, 반복문(루프)이 실행될 때마다 동일한 문장을 반복해서 해석하고 실행한다. 이는 컴파일러가 실행 전에 전체 코드를 한 번만 변환하는 것과 대조적이다. 변수 접근 시에도 인터프리터는 식별자와 메모리 위치 간의 매핑을 실행 중에 반복해서 확인해야 하므로 속도가 더욱 느려진다.^[6]

디스패치(dispatch)는 인터프리터가 가지는 본질적인 비용이다. 컴파일 방식에서는 컴파일 시에 디스패치에 해당하는 명령 본체 정렬이 이루어져 실행 시에는 디스패치 비용이 발생하지 않는다. 반면 인터프리터는 디스패치 비용과 명령 수를 곱한 만큼의 추가 비용이 발생한다.

디스패치는 분기 예측을 어렵게 하여 명령어 파이프라인을 사용하는 CPU의 속도에 영향을 미친다.^[32] 2000년대 이전 CPU에서는 인터프리터의 속도 저하가 이 때문이라고 여겨졌으나, 2010년대 이후 CPU(Haswell 등)에서는 예측기 성능 향상으로 영향이 줄었다.^[33]

하지만 개발 속도와 실행 속도 사이의 균형을 맞추기 위해 다양한 방법이 개발되었다. 예를 들어, 일부 LISP^영어 처리 시스템에서는 인터프리터 코드와 컴파일된 코드를 함께 사용하고 변수를 공유할 수 있다.

컴파일러 방식은 실행 속도가 빠르지만, 개발 과정에서 수정 및 테스트에 시간이 오래 걸린다. 반면, 인터프리터 방식은 실행 속도는 느리지만, 개발 과정에서 수정 및 테스트가 빠르다.

6. 1. 개발 편의성

6. 2. 이식성

7. 응용 분야

• 인터프리터는 명령 줄 언어 및 글루 언어에 자주 사용된다.
• 자기 수정 코드는 인터프리터에서 쉽게 구현할 수 있다. 이는 LISP^영어와 인공지능 연구가 인터프리터의 기원이었던 것과도 관련이 있다.
• 가상 머신을 사용하여, 특정 아키텍처를 다른 아키텍처에서 실행시키는 가상화는 기본적으로 인터프리터이다.
• 샌드박스에서 인터프리터 또는 가상 머신은 소스 코드의 명령을 모두 실제로 실행할 필요가 없다. 특히 컴퓨터 보안을 위협하는 처리는 실행을 거부할 수 있다.
• 더 현대적인 장비에서 구식 및 사용 불가능한 하드웨어를 위해 작성된 컴퓨터 소프트웨어를 실행하기 위한 에뮬레이터로도 활용된다.

8. 프로그래밍 언어

인터프리터 방식으로 실행되는 대표적인 프로그래밍 언어는 다음과 같다.

최초의 인터프리트 방식의 고급 언어는 리스프였다. 스티브 러셀은 1958년 IBM 704 컴퓨터에 리스프를 최초로 구현하였다. 러셀은 존 매카시의 논문을 읽고 리스프의 eval 함수가 기계어로 구현될 수 있다는 것을 발견했는데, 이는 매카시를 놀라게 했다.^[40] 그 결과 작업 중인 리스프 인터프리터가 만들어졌으며, 이는 리스프 프로그램 실행, 더 정확히 말해 "리스프 식의 평가"에 사용될 수 있었다.

9. 기타

펀치 카드 시스템에서 펀치 카드를 읽어 그 내용을 사람이 읽을 수 있는 문자로 펀치 카드에 인쇄하는 기계를 인터프리터라고 불렀다. 예를 들어 IBM 550|IBM 550^영어 (1930년)와 IBM 557|IBM 557^영어 (1954년)가 있다.^[1]

일반적으로 C 언어는 컴파일러로 처리되지만, 디버깅 및 교육용으로 인터프리터 형식의 C 언어 처리기도 있다. CINT, Ch, C-Terp 등이 그 예이다.^[1]

참조

_[1] 문서 'In this sense, the CPU is also an interpreter, of machine instructions.'
_[2] 문서 Although this scheme (combining strategy 2 and 3) was used to implement certain BASIC interpreters already in the 1970s, such as the efficient BASIC interpreter of the ABC 80, for instance.
_[3] 논문 Interpretative sub-routines 1952
_[4] 문서 According to what reported by Paul Graham in Hackers & Painters, p. 185, McCarthy said: "Steve Russell said, look, why don't I program this eval..., and I said to him, ho, ho, you're confusing theory with practice, this eval is intended for reading, not for computing. But he went ahead and did it. That is, he compiled the eval in my paper into IBM 704 machine code, fixing Software bug, and then advertised this as a Lisp interpreter, which it certainly was. So at that point Lisp had essentially the form that it has today..."
_[5] 웹사이트 Why was the first compiler written before the first interpreter? https://arstechnica.[...] 2014-11-08
_[6] 문서 FOLDOC Interpreter
_[7] 웹사이트 Compilers vs. interpreters: explanation and differences https://www.ionos.co[...] 2022-09-16
_[8] 간행물 The Structure and Performance of Interpreters http://citeseerx.ist[...]
_[9] 웹사이트 The Difference Between Compilers and Interpreters http://www.antlr.org[...]
_[10] 서적 Mikroelektronik in der Amateurpraxis Militärverlag der Deutschen Demokratischen Republik 1987
_[11] 논문 Basic-Compreter für U880 1984
_[12] 웹사이트 AST intermediate representations http://lambda-the-ul[...]
_[13] 논문 A Tree-Based Alternative to Java Byte-Codes http://oberon2005.ob[...] 2020-12-20
_[14] 웹사이트 Announcing SquirrelFish http://webkit.org/bl[...] Webkit.org 2008-06-02
_[15] 논문 Efficient implementation of the Smalltalk-80 system http://portal.acm.or[...] 1984
_[16] 웹사이트 openjdk/jdk https://github.com/o[...] 2021-11-18
_[17] 웹사이트 HotSpot Runtime Overview https://openjdk.java[...] Openjdk.java.net 2022-08-06
_[18] 뉴스 Demystifying the JVM: JVM Variants, Cppinterpreter and TemplateInterpreter https://metebalci.co[...]
_[19] 웹사이트 JVM template interpreter https://programmerso[...]
_[20] 간행물 Logimix: A self-applicable partial evaluator for Prolog https://web.archive.[...] 1993
_[21] 웹사이트 Eigenratios of Self-Interpreters http://eigenratios.b[...] 2019-11-10
_[22] 서적 Encyclopedia of Computer Science and Technology: Volume 28 - Supplement 13 https://books.google[...] Marcel Dekker, Inc 2016-01-17
_[23] 서적 bit 単語帳 共立出版 1990-08-15
_[24] 문서 この意味では、CPUは機械語インタプリタであると見ることができる。
_[25] 문서 An interpreter dispatches a virtual instruction body to emulate each virtual instruction in turn.
_[26] 문서 we defined dispatch as the mechanism used by a high level language virtual machine to transfer control from the code to emulate one virtual instruction to the next.
_[27] 문서 現在では、「インタプリタ / コンパイラ」という区分に関しては状況が変わっており、に言わせると『だが、それらは必ずしも相互排他的に2つに分類できるわけではない。なぜなら多くのインタプリタ方式の処理系は、コンパイラが行っているような変換も内部で行っているからだ。』とも言われ、『「インタプリタ言語」あるいは「コンパイラ言語」といった呼称も見掛けることがあるが、これらは単にその言語の規範的実装がインタプリタかコンパイラかを示しているに過ぎない（実際、詳しく調べれば、実験的な程度の実装まで含めれば両方ともあるということも多い）。』という見解も出てくることになる。高水準言語は基本的に抽象であり、（理想的には）特定の実装からは独立している。しかし、動的プログラミング言語のようにインタプリタでの実装が向いている方向性の言語、あるいはその逆もあるということは確かである.
_[28] 웹사이트 日本のソフトウェアの草創期：座談会：日本のソフトウェアの草創期 http://id.nii.ac.jp/[...]
_[29] 문서 Recursive Functions of Symbolic Expressions and Their Computation by Machine, Part I のこと
_[30] 문서 History of Lisp の、§3 の最後のほうに、次のようにある「S.R. Russell noticed that eval could serve as an interpreter for LISP, promptly hand coded it, and we now had a programming language with an interpreter. (段落) The unexpected appearance of an interpreter ...(後略)」
_[31] 문서 ポール・グレアムの『ハッカーと画家』（原著「Hackers & Painters、185ページ）によれば、マッカーシーは「ラッセルは『ねえ、この eval をプログラムしようか』と言った。…私は『ほう、ほう。君は理論と実際を混同している。この eval は読み物として書いたもので、実際に動かすために書いたものじゃない』と答えた。しかし彼はそれをやってのけた。つまり彼は私の論文にある eval を IBM 704 の機械語にコンパイルして、バグを修正し、それを LISP インタプリタだと宣伝したし、実際それはそのとおりだった。だからその時点で LISP は今日のような形態を本質的に備えていた」と述べたという。
_[32] 논문 Branch Prediction and the Performance of Interpreters - Don’t Trust Folklore None 2015-02
_[33] 논문 Branch Prediction and the Performance of Interpreters - Don’t Trust Folklore None 2015-02
_[34] 문서 つまり、近年では高速化にはキャッシュのほうが重要なので、高速化に有利か否かはわからない。
_[35] 웹사이트 AST intermediate representations http://lambda-the-ul[...] Lambda the Ultimate forum
_[36] 논문 A Tree-Based Alternative to Java Byte-Codes http://www.ics.uci.e[...]
_[37] 웹사이트 Annoucing SquirelFish http://webkit.org/bl[...]
_[38] 간행물 Efficient implementation of the Smalltalk-80 system http://portal.acm.or[...] 1984
_[39] 문서
_[40] 서적 Hackers & Painters