Tại sao trình biên dịch đầu tiên được viết trước trình thông dịch đầu tiên?

Trình biên dịch đầu tiên được viết bởi Grace Hopper vào năm 1952 trong khi trình thông dịch Lisp được viết vào năm 1958 bởi sinh viên John Russell của John McCarth. Viết một trình biên dịch có vẻ như là một vấn đề khó khăn hơn nhiều so với một phiên dịch viên. Nếu đó là như vậy, tại sao trình biên dịch đầu tiên được viết sáu năm trước khi phiên dịch đầu tiên?

Viết một trình biên dịch có vẻ như là một vấn đề khó khăn hơn nhiều so với một phiên dịch viên.

Điều đó có thể đúng ngày hôm nay, nhưng tôi sẽ lập luận rằng đó không phải là trường hợp khoảng 60 năm trước. Một vài lý do tại sao:

• Với một trình thông dịch, bạn phải giữ cả nó và chương trình trong bộ nhớ. Trong thời đại mà 1kb bộ nhớ là một thứ xa xỉ lớn, việc giữ cho dung lượng bộ nhớ chạy thấp là chìa khóa. Và phiên dịch đòi hỏi nhiều bộ nhớ hơn một chương trình biên dịch.
• CPU hiện đại là vô cùng phức tạp với danh mục hướng dẫn khổng lồ. Vì vậy, viết một trình biên dịch tốt thực sự là một thách thức. CPU cũ đơn giản hơn nhiều, do đó, việc biên dịch thậm chí còn đơn giản hơn.
• Các ngôn ngữ hiện đại phức tạp hơn nhiều so với các ngôn ngữ cũ, vì vậy ngay cả các trình biên dịch cũng phức tạp hơn nhiều. Ngôn ngữ cũ do đó sẽ có trình biên dịch đơn giản hơn.

Điểm cơ bản là môi trường phần cứng máy tính của những năm 1950 đã khiến nó chỉ có một trình biên dịch là khả thi khi xử lý theo định hướng hàng loạt các máy tính hồi đó.

Vào thời điểm đó, giao diện người dùng tốt hơn chủ yếu giới hạn ở thẻ đục lỗ và máy in teletype . Năm 1961, hệ thống SAGE trở thành màn hình Cathode-Ray Tube (CRT) đầu tiên trên máy tính. Vì vậy, bản chất tương tác của một thông dịch viên là không thích hợp hoặc tự nhiên cho đến sau này.

Nhiều máy tính trong những năm 1950 đã sử dụng các công tắc bảng mặt trước để tải hướng dẫn, và đầu ra chỉ đơn giản là các dãy đèn / đèn LED, và những người có sở thích thậm chí đã sử dụng các công tắc & đèn LED bảng mặt trước vào những năm 1970. Có lẽ bạn đã quen thuộc với Altair 8800 khét tiếng .

Những hạn chế phần cứng khác cũng làm cho phiên dịch viên không khả thi. Có rất ít bộ nhớ chính (ví dụ RAM) trong các máy tính vào những năm 1950. Trước khi mạch tích hợp bán dẫn (không xuất hiện cho đến năm 1958), bộ nhớ bị giới hạn ở bộ nhớ lõi từ hoặc bộ nhớ dòng trễ được đo bằng bit hoặc từ , không có tiền tố. Kết hợp với sự chậm chạp của bộ nhớ lưu trữ thứ cấp (ví dụ như đĩa hoặc băng), nó sẽ bị coi là lãng phí, nếu không có khả năng sử dụng nhiều bộ nhớ cho trình thông dịch, ngay cả trước khi chương trình được giải thích được tải.

Giới hạn bộ nhớ vẫn là một yếu tố chính khi nhóm trưởng của John Backus tại IBM tạo ra trình biên dịch FORTRAN vào năm 1954-57. Trình biên dịch sáng tạo này chỉ thành công vì nó là trình biên dịch tối ưu hóa .

Hầu hết các máy tính trong năm 1950 hầu như không có bất kỳ hệ điều hành, chúng ta hãy tính năng hiện đại một mình như liên kết động và quản lý bộ nhớ ảo, vì vậy ý tưởng của một thông dịch viên đã quá cực đoan và không thực tế lúc bấy giờ.

Phụ lục

Ngôn ngữ của những năm 1950 là nguyên thủy. Họ chỉ bao gồm một nhỏ số ít các hoạt động, thường bị ảnh hưởng bằng cách hướng dẫn các phần cứng cơ bản hoặc định nghĩa vấn đề sử dụng nhắm mục tiêu của họ.

Vào thời điểm đó, máy tính hiếm khi là máy tính có mục đích chung theo nghĩa mà chúng ta nghĩ về máy tính ngày nay. Rằng họ có thể lập trình lại mà không cần phải xây dựng lại được coi là một khái niệm mang tính cách mạng - trước đây người ta đã sử dụng máy điện cơ (thường là máy tính) để tính toán hoặc tính toán câu trả lời (phần lớn các ứng dụng trong những năm 1950 có bản chất là số).

Theo quan điểm của Khoa học máy tính, các trình biên dịch và thông dịch viên đều là các dịch giả và có độ phức tạp gần bằng nhau để thực hiện.

Các ngôn ngữ lập trình đầu tiên khá đơn giản (ví dụ không có đệ quy) và gần với kiến ​​trúc máy đơn giản. Bản dịch sau đó là một quá trình đơn giản .

Trình biên dịch đơn giản hơn là một chương trình so với trình thông dịch sẽ phải kết hợp cả dữ liệu để thực hiện chương trình và các bảng để diễn giải mã nguồn. Và trình thông dịch sẽ chiếm nhiều không gian hơn , cho chính mã nguồn chương trình và cho các bảng biểu tượng.

Bộ nhớ có thể rất khan hiếm (vì cả lý do chi phí và kiến ​​trúc) mà trình biên dịch có thể là các chương trình độc lập ghi đè lên hệ điều hành (tôi đã sử dụng một trong số này). Hệ điều hành phải được tải lại sau khi biên dịch để chạy chương trình đã biên dịch. ... Điều đó làm rõ rằng việc chạy một trình thông dịch cho công việc thực sự đơn giản không phải là một lựa chọn .

Thành thật mà nói, sự đơn giản cần có của trình biên dịch là trình biên dịch không tốt lắm (tối ưu hóa mã vẫn còn ở giai đoạn sơ khai, khi được xem xét ở tất cả). Mã máy viết tay, ít nhất là cho đến cuối những năm sáu mươi ở một số nơi, danh tiếng là hiệu quả hơn đáng kể so với mã trình biên dịch tạo ra. Thậm chí còn có một khái niệm về tỷ lệ mở rộng mã , so sánh kích thước của mã được biên dịch với công việc của một lập trình viên rất giỏi. Nó thường lớn hơn 1 đối với hầu hết các trình biên dịch (tất cả?), Có nghĩa là các chương trình chậm hơn và quan trọng hơn là các chương trình lớn hơn cần nhiều bộ nhớ hơn. Đây vẫn là một vấn đề trong những năm sáu mươi.

Sự quan tâm của trình biên dịch là sự dễ dàng trong lập trình, đặc biệt đối với người dùng không phải là chuyên gia điện toán, chẳng hạn như các nhà khoa học trong các lĩnh vực khác nhau. Sự quan tâm này không phải là hiệu suất mã. Tuy nhiên, thời gian lập trình viên sau đó được coi là một tài nguyên giá rẻ. Chi phí là vào thời gian máy tính, cho đến năm 1975-1980, khi chi phí chuyển từ phần cứng sang phần mềm. Điều đó có nghĩa là ngay cả trình biên dịch cũng không được thực hiện nghiêm túc bởi một số chuyên gia .

Chi phí rất cao cho thời gian sử dụng máy tính là một lý do khác khiến người phiên dịch bị loại , đến mức chính ý tưởng đó sẽ gây cười cho hầu hết mọi người.

Trường hợp của Lisp rất đặc biệt, bởi vì đây là một ngôn ngữ cực kỳ đơn giản khiến nó khả thi (và máy tính đã trở nên lớn hơn một chút trong 58). Quan trọng hơn, trình thông dịch Lisp là một bằng chứng về khái niệm liên quan đến khả năng tự xác định của Lisp ( tính tuần hoàn ), độc lập với bất kỳ vấn đề nào về khả năng sử dụng.

Sự thành công của Lisp chủ yếu là do sự tự xác định này đã khiến nó trở thành một thử nghiệm tuyệt vời để nghiên cứu các cấu trúc lập trình và thiết kế các ngôn ngữ mới (và cũng vì sự thuận tiện cho tính toán biểu tượng).

Tôi không đồng ý với tiền đề của câu hỏi.

Trình biên dịch đầu tiên của Đô đốc Hopper (A-0) giống như một trình liên kết hoặc ngôn ngữ macro. Cô lưu trữ các chương trình con trên một băng (mỗi người được gán một số) và các chương trình của cô sẽ được viết dưới dạng một danh sách các chương trình con và đối số. Trình biên dịch sẽ sao chép các chương trình con được yêu cầu từ băng và sắp xếp lại chúng thành một chương trình hoàn chỉnh.

Cô ấy đã sử dụng từ "biên dịch" theo cùng một nghĩa là người ta biên soạn một tuyển tập các bài thơ: thu thập các mục khác nhau lại thành một tập.

Trình biên dịch đầu tiên đó không có trình biên dịch hoặc trình phân tích cú pháp, theo như tôi có thể nói, điều này làm cho nó trở thành tổ tiên xa của một trình biên dịch hiện đại. Sau đó, cô đã tạo ra một trình biên dịch khác (B-0, còn gọi là FLOW-MATIC) với mục tiêu là một cú pháp giống tiếng Anh hơn, nhưng nó đã không được hoàn thành cho đến năm 1958 hoặc 1959 - cùng thời gian với trình thông dịch Lisp.

Do đó, tôi nghĩ rằng bản thân câu hỏi là một chút sai lầm. Dường như các trình biên dịch và phiên dịch cùng phát triển gần như chính xác cùng một lúc, không còn nghi ngờ gì nữa do việc chia sẻ các ý tưởng sẽ có nhiều nhà khoa học suy nghĩ theo cùng một dòng trong những ngày đó.

Một câu trả lời tốt hơn với các trích dẫn ở đây: https://stackoverflow.com/a/7719098/122763 .

Phần khác của phương trình là các trình biên dịch là một bước trừu tượng trên một trình biên dịch. Đầu tiên chúng tôi có mã máy cứng. "Chúng tôi" là người lắp ráp. Mỗi bước nhảy và bù, v.v ... được tính toán bằng tay thành hex (hoặc bát phân) và sau đó đục lỗ vào băng giấy hoặc thẻ. Vì vậy, khi các nhà lắp ráp xuất hiện, đó là một công cụ tiết kiệm thời gian rất lớn. Bước tiếp theo là các nhà lắp ráp vĩ mô. Điều đó đã cho khả năng viết một macro sẽ mở rộng thành một bộ hướng dẫn máy. Vì vậy, Fortran và Cobol là một bước tiến lớn. Việc thiếu tài nguyên (lưu trữ, bộ nhớ và chu kỳ cpu) có nghĩa là các phiên dịch viên mục đích chung phải chờ công nghệ phát triển. Hầu hết các trình thông dịch ban đầu là các công cụ mã byte (như Java hoặc CLR ngày nay, nhưng với khả năng ít hơn nhiều). UCSD Pascal là một ngôn ngữ rất phổ biến (và nhanh chóng). MS Basic là một công cụ mã byte dưới mui xe.

Về mặt chi phí hướng dẫn, nó hoàn toàn phụ thuộc vào bộ xử lý nào đang được chạy. Ngành công nghiệp đã trải qua một cuộc khủng hoảng RISC vs CISC lớn trong một thời gian. Cá nhân tôi đã viết trình biên dịch cho IBM, Data General, Motorola, Intel (khi họ xuất hiện), TI và một số người khác. Có một sự khác biệt khá đáng kể trong các tập lệnh, thanh ghi, v.v. sẽ ảnh hưởng đến những gì được yêu cầu để "diễn giải" mã p.

Để tham khảo thời gian, tôi bắt đầu lập trình trong công ty điện thoại vào khoảng năm 1972.

Nếu bạn không giữ mọi thứ trong bộ nhớ, mã được biên dịch sẽ nhanh hơn nhiều. Đừng quên rằng, trong những thời điểm này, các hàm được nối với mã được biên dịch. Nếu bạn không biên dịch, bạn không biết bạn sẽ cần những chức năng nào. Vì vậy, bạn đang gọi các chức năng từ ... Ồ, không phải từ đĩa, chúng tôi đang ở trong 50 mối quan hệ đầu tiên, nhưng từ thẻ! Trong thời gian chạy!

Tất nhiên, có thể tìm thấy một cách giải quyết, nhưng chúng chưa được tìm thấy, vì các ngôn ngữ rất đơn giản và không quá xa mã máy. Và biên dịch là dễ dàng và đủ.

Trước khi trình biên dịch đầu tiên được viết, mọi người đã viết mã trình biên dịch mã, đó là một tiến bộ rất lớn so với mã nhị phân đơn giản. Vào thời điểm đó, có một lập luận mạnh mẽ rằng mã được biên dịch bởi trình biên dịch sẽ kém hiệu quả hơn mã trình biên dịch - tại thời điểm đó, mối quan hệ của (chi phí máy tính) với (chi phí lập trình viên) khác nhiều so với ngày nay. Vì vậy, đã có sức đề kháng mạnh mẽ chống lại trình biên dịch từ quan điểm đó.

Nhưng trình biên dịch là rất hiệu quả hơn nhiều so với phiên dịch viên. Nếu bạn đã đề nghị viết một thông dịch viên vào thời điểm đó, mọi người sẽ nghĩ bạn bị điên. Bạn có thể tưởng tượng việc mua một máy tính triệu đô và sau đó lãng phí 90% sức mạnh của nó để giải thích mã không?

Trước khi một chương trình lặp có thể được diễn giải, nó phải được lưu trữ trong một phương tiện có thể được đọc nhiều lần. Trong hầu hết các trường hợp, phương tiện phù hợp duy nhất sẽ là RAM. Vì mã thường sẽ được nhập vào thẻ đục lỗ - đối với các ngôn ngữ có thể đọc được của con người - dường như hầu như trống rỗng, một số loại xử lý phải được thực hiện theo mã trước khi được lưu trữ trong RAM. Trong nhiều trường hợp, xử lý văn bản thẻ đục lỗ thành một hình thức phù hợp để thực thi trực tiếp bởi bộ xử lý không thực sự khó khăn hơn việc xử lý nó thành một hình thức có thể được xử lý hiệu quả thông qua trình thông dịch.

Lưu ý rằng mục tiêu của các trình biên dịch ban đầu không phải là tạo ra tệp ngôn ngữ lắp ráp hoặc mã đối tượng trên đĩa, mà là để kết thúc mã trong RAM đã sẵn sàng để thực thi. Điều này thực sự dễ dàng đáng ngạc nhiên khi không có hệ điều hành nào cản trở. Một trình biên dịch có thể tạo mã bắt đầu từ một đầu của bộ nhớ và phân bổ các biến và các mục tiêu nhánh bắt đầu từ đầu kia. Nếu một câu lệnh được đánh dấu bằng nhãn "1234", trình biên dịch sẽ lưu trữ trong biến có tên là "1234" một lệnh để chuyển đến địa chỉ tạo mã hiện tại, tạo biến đó nếu nó không tồn tại. Một câu lệnh "goto 1234" sẽ tạo ra một biến "1234" nếu nó không tồn tại, và sau đó nhảy đến biến đó [hy vọng sẽ có một bước nhảy đến vị trí thích hợp được lưu trữ trong đó trước khi câu lệnh đó thực thi].gotomột nhãn chưa được xác định, vì nó biết khi nào gotobiên dịch nơi nó sẽ nhảy - đến một biến. Đó có thể không phải là cách hiệu quả nhất để tạo mã, nhưng nó phù hợp với kích thước của các chương trình mà máy tính dự kiến ​​sẽ xử lý.

Bởi vì thông dịch viên cần trình biên dịch để làm việc.

Tuyên bố trên không thực sự đúng. Nói đúng ra, bạn có thể tạo một trình thông dịch mà không bao giờ sử dụng hoặc tương tác với trình biên dịch. Nhưng kết quả của việc này sẽ không giống với những gì tôi nghĩ bạn muốn nói.

Theo nghĩa chặt chẽ, trình biên dịch và phiên dịch làm những việc hoàn toàn khác nhau. Trình biên dịch đọc văn bản từ một số nguồn và chuyển đổi nó thành một số định dạng khác: ngôn ngữ lắp ráp, mã máy, ngôn ngữ cấp cao khác, cấu trúc dữ liệu hoặc bất cứ thứ gì khác. Một thông dịch viên, trong khi đó, có một cấu trúc dữ liệu thuộc loại nào đó và thực hiện các hướng dẫn dựa trên nó.

Ngày nay, cái mà chúng ta nghĩ là "trình biên dịch" thực sự là một trình biên dịch đã được ghép nối với một trình tạo mã : một chương trình lấy dữ liệu từ một số nguồn và xuất mã theo một số định dạng dựa trên những gì nó nhìn thấy. Đó là cách sử dụng khá trực quan cho trình biên dịch và đó là một trong những điều đầu tiên trình biên dịch được tạo ra. Nhưng nếu bạn nhìn nó theo một cách khác, điều này có vẻ rất giống với những gì một phiên dịch viên làm. Nó luôn xuất mã thay vì thực hiện các hoạt động chung hơn, nhưng nguyên tắc là như nhau.

Nếu chúng ta nhìn nó từ phía bên kia, một thông dịch viên cần lấy dữ liệu từ đâu đó . Đây chỉ là dữ liệu, vì vậy bạn có thể xây dựng nó theo cùng cách bạn xây dựng bất kỳ loại dữ liệu nào khác. Vì chúng ta đang nói về giải thích, có vẻ tự nhiên rằng bạn có thể xây dựng dữ liệu của mình dựa trên các hướng dẫn trong tệp văn bản. Nhưng để làm điều đó, bạn cần một cái gì đó để đọc trong văn bản và tạo cấu trúc dữ liệu của bạn và đó là trình biên dịch . Nó được nối với trình thông dịch thay vì trình tạo mã, nhưng nó là trình biên dịch hoàn toàn giống nhau.

Đó là lý do tại sao trình biên dịch được viết đầu tiên. Ý tưởng diễn giải các cấu trúc dữ liệu không phải là mới ngay cả khi các trình biên dịch được hình thành, nhưng các trình biên dịch là "liên kết bị thiếu" cho phép các lập trình viên xây dựng các cấu trúc đó ra khỏi văn bản.

Một yếu tố khác: Khi các trình biên dịch đầu tiên được viết, chi phí thời gian của máy cao hơn rất nhiều so với bây giờ. Thông dịch viên sử dụng nhiều thời gian máy hơn.