왜 첫 번째 컴파일러가 첫 번째 통역사 전에 작성 되었습니까?

첫 번째 컴파일러는 Grace Hopper가 1952 년에 작성했으며 Lisp 인터프리터는 1958 년 John McCarthy의 학생 Steve Russell이 작성했습니다. 컴파일러 작성은 인터프리터보다 훨씬 어려운 문제인 것 같습니다. 그렇다면 왜 첫 번째 컴파일러가 첫 번째 통역사보다 6 년 전에 작성된 것입니까?

컴파일러 작성은 인터프리터보다 훨씬 어려운 문제인 것 같습니다.

그것은 오늘날에도 맞을지 모르지만 저는 60 년 전에는 그렇지 않다고 주장합니다. 몇 가지 이유 :

• 통역사를 사용하면 통역사와 프로그램을 모두 메모리에 보관해야합니다. 1kb의 메모리가 엄청나게 고급 스러웠던 시대에는 실행 메모리 공간을 적게 차지하는 것이 핵심이었습니다. 그리고 해석에는 컴파일 된 프로그램을 실행하는 것보다 약간 더 많은 메모리가 필요합니다.
• 최신 CPU는 방대한 명령 카탈로그로 인해 매우 복잡합니다. 따라서 좋은 컴파일러를 작성하는 것은 정말 어려운 일입니다. 오래된 CPU는 훨씬 간단해서 컴파일도 더 간단했습니다.
• 현대 언어는 이전 언어보다 훨씬 복잡하므로 컴파일러조차 훨씬 더 복잡합니다. 따라서 오래된 언어에는 더 간단한 컴파일러가 있습니다.

근본적인 요점은 1950 년대의 컴퓨팅 하드웨어 환경이 컴퓨터의 배치 지향 처리를 고려할 때 컴파일러 만 실현 가능하도록 만들었다는 것입니다.

당시 더 나은 사용자 인터페이스는 주로 펀치 카드 및 텔레타이프 프린터로 제한되었습니다 . 1961 년 SAGE 시스템 은 컴퓨터에서 최초의 음극선 관 (CRT) 디스플레이가 되었습니다. 따라서 인터프리터의 인터랙티브 한 특성은 훨씬 더 나을 때까지 바람직하지 않거나 자연스럽지 않았습니다.

1950 년대의 수많은 컴퓨터는 전면 패널 스위치를 사용하여 명령을로드했으며 출력은 단순히 일련의 램프 / LED였으며, 애호가들은 심지어 전면 패널 스위치 및 LED를 1970 년대까지 사용했습니다. 아마 당신은 악명 높은 Altair 8800에 익숙 할 것입니다 .

다른 하드웨어 제한 사항으로 인해 통역사도 불가능했습니다. 1950 년대에 컴퓨터에서 주 메모리 (예 : RAM)의 사용이 극도로 제한되었습니다. 반도체 집적 회로 (1958 년까지 출시되지 않았 음) 이전의 메모리는 자기 코어 메모리 또는 지연 라인 메모리 로 제한 되었으며, 비트 또는 워드 단위 로 측정되었으며 접두사는 없습니다. 2 차 저장 메모리 (예 : 디스크 또는 테이프)의 속도가 느려져 해석되는 프로그램이로드되기 전에도 인터프리터에 사용되는 메모리가 많지 않으면 낭비로 간주됩니다.

IBM의 John Backus가 이끄는 팀이 1954-57 년에 FORTRAN 컴파일러를 만들 때 메모리 제한이 여전히 중요한 요소였습니다. 이 혁신적인 컴파일러는 최적화 컴파일러 이기 때문에 성공했습니다 .

1950 년대의 컴퓨터의 대부분은 거의 가지고 어떤 운영 체제, 동적 연결 및 가상 메모리 관리 등의 단독 현대적인 기능을하자, 그래서 통역의 생각은 그 당시 너무 급진적이고 비현실적이었다.

추가

1950 년대의 언어는 원시적이었습니다. 그들은 단지 포함 작은 종종 기본 하드웨어의 지침 또는 대상으로 사용의 문제 정의에 의해 하나의 영향을 운영 줌.

당시 컴퓨터는 오늘날 컴퓨터를 생각한다는 의미에서 범용 컴퓨터가 아닙니다. 재 구축 할 필요없이 재 프로그래밍 할 수 있다는 것은 혁신적인 개념으로 간주되었습니다. 이전에는 사람들이 전자 기계 기계 (일반적으로 계산기)를 사용 하여 답 을 계산 하거나 계산했습니다 (1950 년대 대부분의 응용 프로그램은 본질적으로 숫자였습니다).

컴퓨터 과학의 관점에서 볼 때, 컴파일러와 통역사는 번역가 이며 구현하기가 거의 동일합니다.

첫 번째 프로그래밍 언어는 매우 단순했고 (예를 들어 재귀는 없었 음) 기계 아키텍처에 가깝습니다. 번역은 간단한 과정이었다 .

컴파일러는 프로그램 실행을위한 데이터와 소스 코드를 해석하기 위해 테이블을 함께 유지해야하는 인터프리터보다 프로그램으로서 더 단순했습니다. 그리고 인터프리터는 프로그램 소스 코드와 기호 테이블을 위해 더 많은 공간을 차지 합니다.

컴파일러는 운영 체제를 덮어 쓰는 독립 실행 형 프로그램이 될 수있을 정도로 메모리가 부족할 수 있습니다 (비용과 아키텍처상의 이유로). 컴파일 된 프로그램을 실행하려면 컴파일 후 OS를 다시로드해야했습니다. ... 실제 작업을 위해 통역사를 운영하는 것이 단순히 옵션이 아님을 분명히합니다 .

사실, 컴파일러에 필요한 단순성은 컴파일러가 그리 좋지 않은 정도였습니다 (코드 최적화는 아직 초기 단계에 있습니다). 수작업으로 작성된 기계 코드는 적어도 60 년대 후반까지 컴파일러에서 생성 한 코드보다 훨씬 더 효율적이라는 평판을 받았습니다. 컴파일 된 코드의 크기를 아주 훌륭한 프로그래머의 작업과 비교 한 코드 확장 비율 개념도있었습니다 . 대부분의 (전체?) 컴파일러의 경우 일반적으로 1보다 컸습니다. 이는 프로그램이 느리고 더 중요한 것은 더 많은 메모리가 필요한 큰 프로그램입니다. 이것은 60 년대에도 여전히 문제였습니다.

컴파일러의 관심은 특히 다양한 분야의 과학자와 같은 전문가를 계산하지 않은 사용자에게 프로그래밍 편의성에 관한 것이 었습니다. 이 관심은 코드 성능이 아니 었습니다. 그러나 여전히 프로그래머 시간은 저렴한 리소스로 간주되었습니다. 비용은 하드웨어에서 소프트웨어로 전환 된 1975-1980 년까지 컴퓨터 시간이었습니다. 컴파일러조차도 일부 전문가들에 의해 진지하게 받아들이지 않았다는 것을 의미합니다 .

컴퓨터 시간이 매우 비싸다 는 것은 대부분의 사람들에게 그 아이디어가 웃길 수있을 정도로 통역사 자격을 상실하는 또 다른 이유였다 .

Lisp의 경우 는 매우 특별합니다. 언어가 매우 간단하여 실행 가능하게 만들었습니다 (58 년에 컴퓨터가 조금 더 커졌습니다). 더 중요한 것은 Lisp 인터프리터는 사용성 문제와 관계없이 Lisp의 자체 정의 가능성 ( 메타 순환 성 ) 에 대한 개념 증명이었습니다 .

Lisp의 성공은이 자체 정의가 프로그래밍 구조를 연구하고 새로운 언어를 디자인하는 데 (그리고 기호 계산의 편의성) 훌륭한 테스트 베드가 되었기 때문입니다.

나는 그 질문의 전제에 동의하지 않습니다.

Adm. Hopper의 첫 번째 컴파일러 (A-0)는 링커 나 매크로 언어와 비슷했습니다. 그녀는 테이프에 서브 루틴을 저장했고 (각각 번호가 할당 된) 서브 루틴 및 인수 목록으로 프로그램이 작성되었습니다. 컴파일러는 요청 된 서브 루틴을 테이프에서 복사하여 완전한 프로그램으로 다시 정렬합니다.

그녀는시의 선집을 편찬하는 것과 같은 의미에서 "컴파일"이라는 단어를 사용했습니다. 여러 항목을 하나로 모아서 정리했습니다.

첫 번째 컴파일러에는 내가 알 수있는 한 렉서 또는 파서가 없었으므로 현대 컴파일러의 먼 조상이되었습니다. 그녀는 나중에 영어와 비슷한 구문을 목표로 다른 컴파일러 (B-0, 일명 FLOW-MATIC)를 만들었지 만 Lisp 인터프리터와 거의 같은시기 인 1958 년 또는 1959 년까지 완료되지 않았습니다.

따라서 나는 그 질문 자체가 약간 잘못되었다고 생각합니다. 컴파일러와 통역사가 거의 동시에 동시에 진화 한 것으로 보입니다. 당시 같은 시대에 많은 과학자들이 생각했던 아이디어를 공유했기 때문에 의심의 여지가 없습니다.

https://stackoverflow.com/a/7719098/122763 에서 인용을 통해 더 나은 답변을 얻을 수 있습니다 .

방정식의 다른 부분은 컴파일러가 어셈블러 위의 단계 추상화라는 것입니다. 먼저 우리는 기계 코드를 하드 코딩했습니다. "우리"는 어셈블러였습니다. 모든 점프 및 오프셋 등은 16 진수 (또는 8 진수)로 수동 계산 된 다음 종이 테이프 또는 카드에 펀칭되었습니다. 따라서 어셈블러가 등장했을 때 시간을 크게 절약했습니다. 다음 단계는 매크로 어셈블러입니다. 이를 통해 일련의 기계 명령어로 확장되는 매크로를 작성할 수 있습니다. 따라서 포트란과 코볼은 큰 발전이었습니다. 리소스 (스토리지, 메모리 및 CPU주기)가 부족하다는 것은 범용 인터프리터가 기술이 성장할 때까지 기다려야한다는 것을 의미했습니다. 대부분의 초기 인터프리터는 바이트 코드 엔진 (오늘의 Java 또는 CLR과 같지만 기능이 훨씬 적음)이었습니다. UCSD 파스칼은 매우 인기 있고 빠른 언어였습니다. MS Basic은 후드 아래의 바이트 코드 엔진이었습니다.

명령 오버 헤드 측면에서, 실행중인 프로세서에 전적으로 의존했습니다. 업계는 한동안 큰 RISC 대 CISC 혼란을 겪었습니다. 저는 IBM, Data General, Motorola, Intel (나타 났을 때), TI 및 기타 여러 사용자를 위해 직접 어셈블러를 작성했습니다. p- 코드를 "해석"하는 데 필요한 사항에 영향을 줄 수있는 명령어 세트, 레지스터 등에는 상당히 큰 차이가있었습니다.

시간 기준으로 저는 1972 년경 전화 회사에서 프로그래밍을 시작했습니다.

모든 것을 메모리에 보관하지 않으면 컴파일 된 코드가 훨씬 빠릅니다. 이 시대에는 함수가 컴파일 된 코드에 결합되었다는 것을 잊지 마십시오. 컴파일하지 않으면 어떤 기능이 필요한지 모릅니다. 그래서, 당신은 함수를 호출하고 있습니다. 아, 아직 디스크에서가 아니라, 우리는 50 대 초반이 아니라 카드에서 왔습니다! 런타임에!

물론, 해결 방법을 찾을 수는 있지만 아직 발견되지 않았습니다. 언어는 매우 간단하고 기계 코드와 그리 멀지 않았습니다. 그리고 컴파일은 쉽고 충분했습니다.

첫 번째 컴파일러가 작성되기 전에 사람들은 어셈블러 코드를 작성했는데 이는 일반 이진 코드와 비교할 때 큰 발전이었습니다. 당시에는 컴파일러가 컴파일 한 코드가 어셈블러 코드보다 효율적이지 않다는 강력한 주장이있었습니다. 당시 (컴퓨터 비용)과 (프로그래머 비용)의 관계는 오늘날과 크게 다릅니다. 따라서 그 관점에서 컴파일러에 대한 강한 저항이있었습니다.

그러나 컴파일러는 인터프리터보다 훨씬 효율적입니다. 그 시점에서 통역사 작성을 제안했다면 사람들은 당신이 미쳤다고 생각했을 것입니다. 백만 달러의 컴퓨터를 구입 한 다음 코드 해석에 90 %의 전력을 낭비한다고 상상할 수 있습니까?

루핑 프로그램을 해석하기 전에 반복해서 읽을 수있는 매체에 저장해야합니다. 대부분의 경우 적합한 매체는 RAM입니다. 코드는 일반적으로 사람이 읽을 수있는 언어의 경우 천공 된 카드에 입력되기 때문에 RAM에 저장되기 전에 코드에 대해 어떤 종류의 처리를 수행해야합니다. 많은 경우에, 천공 카드 텍스트를 프로세서에 의해 직접 실행하기에 적합한 형태로 처리하는 것은 인터프리터를 통해 효율적으로 처리 될 수있는 형태로 처리하는 것보다 더 어렵지 않다.

초기 컴파일러의 목표는 디스크에 어셈블리 언어 또는 객체 코드 파일을 생성하는 것이 아니라 실행할 준비가 된 RAM에 코드를 작성하는 것이 었습니다. 방해가되지 않는 운영 체제가 없을 때 이것은 실제로 놀랍도록 쉽습니다. 컴파일러는 메모리의 한쪽 끝에서 시작하여 코드를 생성하고 다른 쪽 끝에서 시작하는 변수 및 분기 대상을 할당 할 수 있습니다. 명령문에 레이블 "1234"가 표시되면 컴파일러는 "1234"라는 변수에 현재 코드 생성 주소로 이동하여 해당 변수가없는 경우 해당 변수를 작성하는 명령을 저장합니다. "goto 1234"문은 변수가없는 경우 "1234"변수를 만든 다음 해당 변수로 이동합니다 (해당 명령문이 실행되기 전에 저장된 적절한 위치로 점프하기를 희망 함).gotogoto컴파일 이 언제 어디로 옮길 지 알기 때문에 아직 정의되지 않은 레이블 -변수. 코드를 생성하는 가장 효율적인 방법은 아니지만 컴퓨터가 처리해야하는 프로그램의 크기에는 적합합니다.

인터프리터가 작동하려면 컴파일러가 필요하기 때문입니다.

위의 진술은 사실이 아닙니다. 엄밀히 말하면 컴파일러를 사용하거나 상호 작용하지 않고도 인터프리터를 만들 수 있습니다 . 그러나이 작업의 결과는 내가 당신이 그 용어로 의미한다고 생각하는 것과 크게 다르지 않을 것입니다.

엄밀한 의미에서 컴파일러와 인터프리터는 완전히 다른 일을합니다. 컴파일러는 일부 소스에서 텍스트를 읽고 어셈블리 언어, 기계 코드, 다른 고급 언어, 데이터 구조 또는 기타 다른 형식으로 변환합니다. 한편, 통역사는 어떤 종류의 데이터 구조를 취하고이를 기반으로 명령을 수행합니다.

오늘날 우리가 "컴파일러"라고 생각하는 것은 실제로 코드 생성기 와 짝을 이룬 컴파일러입니다 . 어떤 소스에서 데이터를 가져 와서 보이는 형식에 따라 코드를 어떤 형식으로 출력하는 프로그램입니다. 이는 컴파일러에있어 상당히 직관적 인 사용이며, 컴파일러가 처음 만들어진 것 중 하나였습니다. 그러나 다른 방식으로 보면 통역사가하는 것과 매우 유사 해 보입니다. 더 일반적인 작업을 수행하는 대신 항상 코드를 출력하지만 원칙은 동일합니다.

다른 쪽에서 보면 인터프리터가 데이터를 어딘가에서 가져와야 합니다. 이것은 단지 데이터이므로 다른 종류의 데이터를 작성하는 것과 같은 방식으로 작성할 수 있습니다. 해석에 대해 이야기하고 있기 때문에 텍스트 파일의 지침에 따라 데이터를 작성할 수있는 것은 당연합니다. 그러나 그렇게하려면 텍스트를 읽고 데이터 구조를 만들 무언가가 필요 하며 컴파일러 입니다. 코드 생성기 대신 인터프리터에 연결되어 있지만 컴파일러는 모두 동일합니다.

그래서 컴파일러가 먼저 작성되었습니다. 데이터 구조를 해석한다는 아이디어는 컴파일러가 고안된 경우에도 새로운 것이 아니었지만, 컴파일러는 프로그래머가 텍스트로 구조를 구축 할 수있는 "누락 된 링크"였습니다.

또 다른 요인 : 첫 번째 컴파일러를 작성할 때 기계 시간 비용이 현재보다 훨씬 높았습니다. 통역사는 더 많은 기계 시간을 사용합니다.