Чому перший компілятор написаний до першого інтерпретатора?

Перший компілятор був написаний Грейс Хоппер в 1952 році, а інтерпретатор Lisp був написаний у 1958 році студентом Джона Маккарті Стівом Расселом. Написання компілятора виглядає набагато складніше, ніж інтерпретатор. Якщо це так, то чому перший компілятор, написаний за шість років до першого перекладача?

72
Якщо ви приймаєте інструкції, що виконують ваш процесор, як їх інтерпретація, це те, що я бачу (але реалізовані за допомогою апаратних засобів), то твердження про те, що перший інтерпретатор було написано після першого компілятора. До речі, я знаю, що це не допоможе питання/відповідь. Це просто цікавий коментар з іншої точки зору.
додано Автор vartec, джерело
Я завжди припускав, що, оскільки сама концепція монтажників і компіляторів та перекладачів не існувала спочатку, все це повинно бути винайдене з нуля. Отже, перша ідея полягала в тому, щоб взяти читаний текст і перекласти в машинний код (тобто, асемлерів і компіляторів), що було природно, оскільки комп'ютери можуть працювати тільки з машинним кодом! І ідея "прийняти читаний текст і зробити те, що вона каже" прийшла пізніше.
додано Автор David N. Welton, джерело
Грейс Хоппер і FLOW-MATIC не раніше 1955/56, публічний реліз 1957. Фортран є першою головною складовою мовою, приблизно в 1957 році. Lisp був дуже дивний.
додано Автор alex, джерело
тому що в той час було більше потреби в компіляторі, ніж перекладач
додано Автор matte, джерело
Насправді, я чув, що Маккарті вважає, що LISP є нездійсненним. Саме Рассел усвідомив, що універсальна функція Маккарті з керівництва LISP a) була інтерпретатором і b) була реалізована.
додано Автор Lawrence B. Crowell, джерело
@ JörgWMittag - Перший закон Кларка - "Коли відомий, але літній учений стверджує, що щось можливо, він майже напевно має рацію. Коли він стверджує, що щось неможливо, він дуже ймовірно помиляється". (Хоча я не думаю, що ви могли б сказати, що Маккарті був "похилого віку", будучи тільки близько 32 в той час - але, враховуючи, що це було дуже ранні дні, і він був у нього вже більше 10 років, я вважаю, що він був досить Набагато «старий», куди б він не пішов, так ... :-).
додано Автор Matthew, джерело
Маккарті не написав перекладача LISP. Маккарті винайшов математичний формалізм. Стів Рассел, один з учнів лабораторії MIT AI в той час, зрозумів, що може написати перекладача для виконання фантазійних рейсів Маккарті, а решта - історія.
додано Автор Mark McKinstry, джерело
@slebetman Ах ... Вихор. Думаю, ви маєте рацію. Що стосується Беббіджа, gedankenexperimenten не розраховує - ви повинні побудувати річ, щоб виграти :-)
додано Автор somid3, джерело
@slebetman Гм, мікрокод прийшов довго після 1958 року. Ми говоримо про вакуумні труби і дискретні транзистори в ті часи.
додано Автор somid3, джерело
@RossPatterson: Перша мікрокодова машина була побудована в 1947 році на MIT. Мікрокод був записаний у вигляді масиву діодів
додано Автор Laplacian, джерело
Можливо, першим інтерпретатором були мікрокоди - перекладені біти 1s і 0s, розташовані в логічному форматі, який інженери можуть легко зрозуміти в гнізді щурів сигналів, які необхідно правильно встановити, щоб CPU виконав інструкцію. У цьому випадку інтерпретатор з'явився перед компілятором ;-)
додано Автор Laplacian, джерело
Аналітичний двигун не був думкою, просто невдалий проект Kickstarter. Досить було побудовано для сина Беббіджа, щоб використовувати для розрахунку (баггі) цифр PI. Вони побудували досить повний процесор (млин), який може запускати жорсткі програми, які вони просто не мали ресурсів для створення оперативної пам'яті (магазину).
додано Автор Laplacian, джерело
Про що я говорю? Я забув, чому я сказав, що перекладач прийшов першим! Перша мікрокодова машина/інтерпретатор була вперше описана Аналітичним движком Чарльза Беббіджа в 1837 році. інструкції рівня, які важко реалізувати лише як передачі та механізми водозбору. Хоча технічно вона ніколи не була побудована, але вона була розроблена (письмовий перекладач)
додано Автор Laplacian, джерело
@MrLister sorta випадок "вирізання середньої людини" ви маєте на увазі? Звучить абсолютно розумно.
додано Автор jwenting, джерело
Джерело, що це були перший компілятор і інтерпретатор? Схоже, це велике припущення, якщо ви не можете його підтримати.
додано Автор jmibanez, джерело
Пункт: те, що написав Хупер в 1952 році (A-0), її називали "компілятором", але не вважали б компілятором нинішніми стандартами (навіть стандартами 1960-х років). Навіть тоді, це було більш точно назвав "Асамблея Link Loader". За більшістю рахунків, першим справжнім завершеним компілятором був FORTRAN в 1957 році Джон Бекус.
додано Автор Joe C, джерело
Я підозрюю, що до Lisp були перекладачі, але, мабуть, не Тьюрінг.
додано Автор Daniel R Hicks, джерело
Компілювати перший інтерпретатор? : P (лише частково язик у щоку, інтерпретатор складний (більше, ніж простий компілятор), і було б неприємним писати ефективний в машинному коді)
додано Автор Vality, джерело
Історія про Грейс Хоппер як першого автора компілятора добре відома: cs.yale.edu/homes/tap/Files/hopper-story.html Інтерпретатор lisp був спочатку призначений для компіляції, поки Russell не зрозумів інструкції, які можна було б перекласти безпосередньо www-formal.stanford.edu/jmc/history/lisp/…
додано Автор Peter, джерело
Відредаговано, щоб віддати належне незаповненим героям академії - аспіранту
додано Автор Peter, джерело

10 Відповіді

Написання компілятора набагато складніше, ніж інтерпретатор.

Це може бути вірно сьогодні, але я б стверджував, що це було не так, як це було 60 років тому. Кілька причин:

  • За допомогою інтерпретатора ви повинні зберігати і його, і програму в пам'яті. У епоху, коли 1 кб пам'яті була величезною розкішшю, ключовим моментом було збереження низького обсягу пам'яті. І інтерпретація вимагає трохи більше пам'яті, ніж запуск зібраної програми.
  • Сучасні процесори надзвичайно складні з величезними каталогами інструкцій. Так що написання хорошого компілятора дійсно є проблемою. Старі процесори були набагато простішими, тому навіть компіляція була простішою. ​​
  • Сучасні мови набагато складніше, ніж старі мови, тому навіть компілятори набагато складніші. Таким чином, старі мови матимуть простіші компілятори.
97
додано
Просто пам'ятаю. Мій друг розповів, як він написав перекладача спеціального призначення, тому що для складеної програми недостатньо пам'яті.
додано Автор Vanja, джерело
Перші компілятори, де люди. (Коли люди є перекладачами, нам не потрібні комп'ютери). Тоді хтось повинен був розглянути написання компілятора на компільованій мові (єдині, які вони мали, але як час склали мої люди).
додано Автор Vanja, джерело
і без компілятора вам доведеться написати перекладача в збірці
додано Автор matte, джерело
@richard: Коли люди були перекладачами/калькуляторами, їх посада називалася "комп'ютерною". Тому, коли люди були інтерпретаторами, вони були буквально комп'ютерами. Проект Манхеттена використовував тисячі "комп'ютерів" (по-справжньому посада, серйозно), до яких ядерні фізики посилали свої розрахунки поштою, щоб бути виконаними. Насправді, в проекті також працювали математики, які розбили розрахунки інженерів, які сформулювали розрахунки з теорій фізиків, які надсилатимуть «комп'ютери».
додано Автор Laplacian, джерело
@richard Люди <�я> є перекладачами. Ви ніколи не переступали код у вашій голові? Це тлумачення. Ми просто надзвичайно повільний перекладач.
додано Автор situee, джерело
@Luaan: Не тільки це, але відносна вартість між пам'яттю та воротами була такою, що схема для виконання функції часто може бути дешевшою, ніж кількість пам'яті, необхідної для зберігання коду, який інакше був би необхідний для його виконання.
додано Автор supercat, джерело
@Luaan як осторонь ... був компілятором, але в цій історії більше. Від Вікіпедії "FORTRAN був наданий для IBM 1401 інноваційним компілятором, який складається з 63 пропусків. Він тримав програму в пам'яті і завантажував накладання, які поступово перетворювали її на місце у виконувану форму, як описано Haines et al., виконувана форма не була машинною мовою; , передбачаючи P-код UCSD Паскаля на два десятиліття. "
додано Автор user40980, джерело
Дайте докладну інформацію про компілятор Fortran для корпорації IBM . Ми думаємо про 1 прохід, 2 проходження або, можливо, про три кроки ускладнення - кожен крок робить десятки тисяч операцій. Тоді в пам'яті не можна було так триматись - так більше проходить, причому кожен прохід набагато менший. "Компілятор 1401 FORTRAN має 63 фази, в середньому 150 інструкцій на фазу і максимум 300 інструкцій на будь-якій фазі". Для порівняння, Паскаль був розроблений таким чином, щоб його можна було реалізувати за допомогою одного компілятора.
додано Автор user40980, джерело
@ratchetfreak І це було. Як і перші компілятори.
додано Автор Joe C, джерело
Насправді .... Нещодавно я прочитав, що Комп'ютер Apollo Guidance, який використовувався в польотах місяця 60-х років, мав перекладача: wiki запису "... перекладач надав багато інших інструкцій, ніж AGC, які підтримувалися ..." Я вважаю, що цей "інтерпретатор" більше схожий на " 16 "інтерпретатор вбудований у старі комп'ютери Apple II, ніж щось подібне до LISP.
додано Автор Rory O'Kane, джерело
@richard Я думав про це теж, але забув згадати.
додано Автор Euphoric, джерело
@MichaelT Це жорстке ядро ​​- і Fortran був досить простий мовою, в порівнянні навіть з C. І Turbo Паскаль, о боже, це було просто так приголомшливо. Неймовірно швидкі, низькі вимоги до пам'яті і легка в роботі (за винятком тих дратівливих рядків!: D)
додано Автор Luaan, джерело
Тепер написання компілятора легше. Посилання є складною частиною, і коли ви пишете інтерпретатор, ви просто уникаєте проблеми, дозволяючи компілятору писати перекладача в більшій частині роботи. Крім цього, компілятор просто ставить дані та інструкції для виконання ЦП. Це набагато простіше, ніж обробка повної віртуальної машини в програмному забезпеченні :)
додано Автор Luaan, джерело
@richard подібний fabiensanglard.net/anotherWorld_code_review ? Зверніть увагу, що це була віртуальна машина/інтерпретатор з дуже специфічною метою. Також слід звернути увагу на fabiensanglard.net/prince_of_persia/pop_boot.php , що дозволило завантажувати великі двійкові файли в штук.
додано Автор deostroll, джерело

Важливим моментом є те, що обчислювальне апаратне середовище 1950-х років зробило його таким, що тільки компілятор був здійсненним з урахуванням пакетної орієнтації комп'ютерів тоді.

У той час кращі інтерфейси користувача обмежувалися лише перфокартами та телетайпними принтерами . У 1961 році система SAGE стала першим Відображення ефірної трубки (CRT) на комп'ютері. Таким чином, інтерактивний характер перекладача не був бажаним або природним до набагато пізніше.

Numerous computers in the 1950s used front panel switches to load instructions, and the output was simply rows of lamps/LEDs, and hobbyists even used front-panel switches & LEDs into the 1970s. Maybe you're familiar with the infamous Altair 8800.

Інші обмеження щодо обладнання також зробили перекладачі нездійсненними. У 1950-х роках у комп'ютерах була дуже обмежена доступність первинної пам'яті (наприклад, оперативної пам'яті). До напівпровідникової інтегральної схеми (яка не прийшла до 1958 року) пам'ять обмежувалася пам'яттю магнітного ядра або пам'ять лінії затримки , яка була виміряна в бітах або словах , немає префікса. У поєднанні з повільністю вторинної пам'яті для зберігання (наприклад, диска або стрічки) вважається марнотратним, якщо не неможливим мати більшу частину пам'яті, що використовується для інтерпретатора, ще до того, як програма була інтерпретована.

Обмеження пам'яті все ще залишалися головним фактором, коли команда, яку очолював Джон Бекус в IBM, створила компілятор FORTRAN у 1954—57. Цей інноваційний компілятор був успішним лише тому, що це оптимізуючий компілятор .

Більшість комп'ютерів у 1950-х роках майже не мали жодної операційної системи, не кажучи вже про сучасні функції, такі як динамічні зв'язки та управління віртуальною пам'яттю, тому ідея інтерпретатора була занадто радикальною і непрактичною в той час.

Addendum

Мови 1950-х років були примітивними. Вони включали лише невеликий кілька операцій, на які часто впливали інструкції основного обладнання або визначення проблеми їхнього цільового використання.

На той час комп'ютери рідко були загальними комп'ютерами в тому сенсі, що ми думаємо про комп'ютери сьогодні. Те, що вони були перепрограмовані без необхідності перебудови, вважалося революційною концепцією - раніше люди використовували електромеханічні машини (як правило, калькулятори) для обчислення або розрахунку відповідей (більшість додатків у 1950-ті були числовими природи).

З точки зору комп'ютерних наук, компілятори та інтерпретатори є одночасно перекладачами і приблизно рівними по складності.

42
додано
@supercat - 1973 - але комп'ютер, про який йде мова (EDP-18, за продуктами освітніх даних), був відносно літнім навіть тоді. Досі, це що ми мали (та маюче будь-який комп'ютер зв'язати з у середній школі у ранньому-внутрішньому-70е було незвичайне) так як ми подумали це було досить дивуємо. :-)
додано Автор Matthew, джерело
@supercat - так, використовувалися телетайпи, але вони були далекі від "інтерактивних". Перший комп'ютер, який я запрограмував, мав пам'ять, що складалася з 18-бітних слів - 1K з них. Сама пам'ять була обертовим барабаном , тому, коли ви включили комп'ютер, вам довелося чекати, поки пам'ять підійде до швидкості. У нього був прикріплений телетайп, і ви могли б A) читати символ, введений з клавіатури або читати за допомогою пристрою для читання паперової стрічки (з точки зору комп'ютера обидва були однаковими), B) написати символ до "принтера" "телетайпу. Ах, великі дні - ВЕЛИКІ дні ..! ТО МОЄ ГРЕЙЛ ТЕПЛЕВО?!?!? :-)
додано Автор Matthew, джерело
@BobJarvis: Який рік це було б?
додано Автор supercat, джерело
Чи використовували комп'ютери телетайпи до появи часу? Я б очікував, що вони або використовують лінійні принтери або котушку до стрічки. Інакше, через 1-8 секунд комп'ютер повинен був би почекати після кожного рядка тексту, який представляв би 1-8 секунд, що комп'ютер міг би бути, але не був, що робив щось корисне.
додано Автор supercat, джерело
Це набагато краща і повна відповідь, ніж прийнята.
додано Автор Andy Wilson, джерело

Перші мови програмування були досить простими (без рекурсії для наприклад) і близькою до машинної архітектурі, яка була сама просто. Переклад тоді був простим процесом .

Компілятор був простішим, ніж програма-інтерпретатор повинні зберігати разом дані для виконання програми і таблиці для інтерпретації вихідного коду. І перекладач займе більше місця , для себе, для вихідного коду програми та для символічного таблиці.

Пам'ять може бути такою мізерною (як з причин витрат, так і з архітектурних причин) що компілятори можуть бути автономними програмами, які переписали операційної системи (я використовував одну з них). ОС довелося перезавантажити після компіляції для запуску скомпільованої програми. ... що робить дайте зрозуміти, що використання інтерпретатора для реальної роботи просто не є можливим .

Щоб бути правдою, простота, необхідна для компіляторів, була такою, що компілятори були не дуже хороші (оптимізація коду була ще в дитинстві, коли розглядалися взагалі). Рукописний машинний код мав, принаймні до кінця шістдесятих в деяких місцях репутація буття значно ефективніше, ніж код, створений компілятором. Існувало навіть поняття коефіцієнта розширення коду , яке порівнювало розмір складеного коду на роботу дуже гарного програміста. Це було звичайно більше, ніж 1 для більшості (всіх?) компіляторів, що означало більш повільні програми, і набагато важливіше, великі програми, що вимагають більшої пам'яті. Це було все ще проблема в шістдесятих роках.

Інтерес компілятора був у простоті програмування, особливо для користувачів які не були обчислювальними фахівцями, такими як вчені в різних поля. Цей інтерес не був ефективністю коду. Але все ж, програміст Час тоді вважався дешевим ресурсом. Вартість була в комп'ютері Час, до 1975-1980 рр., коли вартість перейшла від апаратного до програмного забезпечення. Це означає, що навіть компілятор не сприймався серйозно деякі фахівці .

The very high cost of computer time was yet another reason for disqualifying interpreters, to the point that the very idea would have been laughable for most people.

The case of Lisp is very special, because it was an extremely simple language which made it feasable (and the computer had become a bit bigger in 58). More importantly, the Lisp interpreter was a proof of concept regarding the self definability of Lisp (meta-circularity), independently of any issue of usability.

Успіх Lisp пояснюється в основному тим, що ця самовизначеність зробила це відмінний тест для вивчення структур програмування та дизайну нових мов (а також для зручності символічного обчислення).

12
додано
Мій, як жирний .
додано Автор Pharap, джерело
@ anonymous-downvoter Опублікування без пояснювального коментаря показує, що хтось може бути дурним. Проте не сказано, хто.
додано Автор Amir Ali Akbari, джерело
@Pharap Це неправильний стиль? Моя мета полягає в тому, щоб полегшити пошук ключової інформації, допускаючи при цьому більш вільний стиль, ніж просто перерахування фактів. Я повинен зізнатися, що це не дуже ефективно на цьому сайті SE.
додано Автор Amir Ali Akbari, джерело

Я не згоден з передумовою питання.

Перший компілятор Хоппера (A-0) був більше схожий на лінкер або макро-мову. Вона зберігала підпрограми на стрічці (кожному присвоєно номер), а її програми будуть записані як список підпрограм і аргументів. Компілятор буде копіювати запитувані підпрограми з касети і повторно упорядкувати їх у повну програму.

Вона використовувала слово "compile" в тому ж сенсі, що збирає антологію віршів: збираючи різні елементи разом в один том.

Цей перший компілятор не мав lexer або parser, наскільки я можу сказати, що робить його далеким предком сучасного компілятора. Пізніше вона створила ще один компілятор (B-0, a.k.a. FLOW-MATIC) з метою більш англійського синтаксису, але він не був завершений до 1958 або 1959 року - приблизно в той же час, що і інтерпретатор Lisp.

Тому, я думаю, що це питання трохи помиляється. Схоже, що компілятори та перекладачі розвивалися майже одночасно, без сумніву, завдяки обміну ідеями, які в ті часи мали б думки багатьох вчених.

Краще відповісти цитатами тут: https://stackoverflow.com/a/7719098/122763 .

4
додано

Інша частина рівняння полягає в тому, що компілятори були ступеневою абстракцією над асемблером. Спочатку ми мали жорсткий код машини. "Ми" були асемблером. Кожен стрибок і зсув, і т. Д. Був розрахований вручну в шістнадцяткову (або вісімкову) і потім пробиту в паперову стрічку або карти. Тому, коли на сцену прийшли асемблери, це було величезним заощадженням часу. Наступним кроком були асемблери макросів. Це дало можливість написати макрос, який розширився б у набір машинних інструкцій. Отже, Фортран і Кобол були величезним кроком вперед. Нестача ресурсів (зберігання, пам'ять і цикли процесорів) означала, що перекладачам загального призначення доводилося чекати зростання технологій. Більшість ранніх інтерпретаторів були двигунами байт-коду (наприклад, Java або CLR сьогодні, але з набагато меншими можливостями). UCSD Pascal був дуже популярною (і швидкою) мовою. MS Basic був двигуном байт-коду під капотом. Таким чином, "компіляція" дійсно мала генерувати потік байт-коду, який фактично виконувався під час виконання.

З точки зору накладних команд, це повністю залежало від того, який процесор виконувався. Промисловість пройшла через велике потрясіння RISC проти CISC на деякий час. Я особисто написав асемблер для IBM, Data General, Motorola, Intel (коли вони з'явилися), TI, і кілька інших. Існувала досить значна різниця в наборах інструкцій, регістрів тощо, які могли б впливати на те, що потрібно для "інтерпретації" p-коду.

Як довідник часу я почав програмувати в телефонній компанії близько 1972 року.

3
додано

Якщо ви не зберігаєте все в пам'яті, скомпільований код набагато швидше. Не забувайте, що в ці моменти функції були приєднані до скомпільованого коду. Якщо ви не збираєтеся, ви не знаєте, які функції вам знадобляться. Отже, ви називаєте функції з ... Ох, не з диска ще, ми вже на початку 50-х, але з карток! Під час виконання!

Звичайно, можна знайти обхідні шляхи, але їх ще не було знайдено, для мов було дуже просто і не так далеко від машинного коду. І компіляція була легкою і достатньою.

2
додано

Ще один фактор: коли були написані перші компілятори, вартість машинного часу була набагато вищою, ніж зараз. Перекладачі використовують набагато більше машинного часу.

1
додано

Перш ніж був написаний перший компілятор, люди писали ассемблерний код, який був величезним прогресом порівняно з простим двійковим кодом. У той час існував сильний аргумент, що код, складений компілятором, буде менш ефективним, ніж код ассемблера - тоді відношення (вартості комп'ютера) до (вартість програміста) було набагато, значно відрізняється від сьогоднішнього. Отже, з цієї точки зору існував сильний опір проти компіляторів.

Але компілятори набагато ефективніші, ніж перекладачі. Якби ви запропонували писати перекладача на той момент, люди думали, що ви з розуму. Ви можете уявити собі покупку комп'ютера на мільйон доларів, а потім витрачати 90% своєї влади на інтерпретацію коду?

1
додано
@delnan Ці системи працювали з тактовою частотою в kiloHertz, тому втрата продуктивності в 3-5 разів, швидше за все, була б різницею між програмою, яка завершилася успішно, до того, як система вийшла з ладу через збій обладнання (наприклад, виснаження вакуумної трубки) чи ні. Апаратні збої були щоденним явищем у 1950-х роках, якщо я пам'ятаю правильно.
додано Автор Dark Shikari, джерело
До того, як був написаний перший компілятор, більшість програм були фактично написані в реальному машинному коді, а не в мові асемблера (оп-коди мнемоніка).
додано Автор Dark Shikari, джерело
@supercat Так, це хороший момент.
додано Автор Paul Muir, джерело
@ gnasher729 Ну, Forth ;-) ВМ, і в деякій мірі мова, повинні бути розроблені для цього. Наприклад, динамічне введення може зайняти своє, статично типізована або нетипізована мова полегшить роботу. Ви вказуєте перший байт коду операції, зберігаєте код для коду операції i за BASE + (i << k) для відповідного коду k , після чого кожен код операції можна відправити в три інструкції, давати або приймати один в залежності від того, як фантазії набір інструкцій: (1) Отримати код операції. (2) Обчислити код адреси. (3) Перейти до цієї адреси. Додайте більше, якщо інструкція має аргументи (не завжди необхідні для машин стека).
додано Автор Paul Muir, джерело
Я не знаю багато про комп'ютери 1950-х років, але принаймні для простих машин фон Неймана пізніх десятиліть, накладні витрати інтерпретатора становитимуть від двох до п'яти інструкцій (можливо, від чотирьох до десяти циклів) для кожної інтерпретованої команди: Decode, космічний стрибок, можливо декодування додаткові аргументи. Якщо ви зробите інтерпретований набір команд достатньо високим (щоб ви виконали декілька машинних команд на інструкцію перекладача), це було б менше 90% і, можливо, навіть прийнятно. Дивіться також: Forth.
додано Автор Paul Muir, джерело
@gnasher: У 1974 році я побудував високопродуктивний інтерпретатор BASIC для Keronix (гм, Data General Nova клонів), який використовував байт-орієнтований P-код для кодування BASIC оператора. Треба було приблизно 25-50 машинних інструкцій для "інтерпретації" pCode, 10 з них для самого вибору байтів. (У 1969 році я зробив маркер, який зайняв більше, тому що він повинен був фактично розібрати вирази). Але це wasnt та isnt "gazillions".
додано Автор Keith, джерело
delnan: Покажіть мені інтерпретатор, який може інтерпретувати з п'ятьма накладними інструкціями. А Форт не є інтерпретованою мовою, це гидота :-). На жаль, я маю на увазі різьбову мову. Щось на зразок BASIC приймає інструкції для інтерпретації одного твердження.
додано Автор gnasher729, джерело
@delnan: Великі труднощі з перекладачами полягають у тому, що якщо ви починаєте з програм на перфокартах, то передача програми в оперативну пам'ять у формі, яка може ефективно інтерпретуватися, не сильно відрізняється від того, щоб ввести її у форму, яка відповідає реальним інструкціям. Для великих програм інтерпретований байтовий код може бути більш компактним, ніж машинний код, але тільки якщо програма була великою, заощадження швидше за все перевищували б вартість перекладача.
додано Автор supercat, джерело

Перш ніж програма інтерпретації циклу може бути інтерпретована, вона повинна бути збережена в середовищі, яку можна багаторазово зчитувати. У більшості випадків єдиним придатним середовищем буде оперативна пам'ять. Оскільки код зазвичай вводиться на перфокартах, які, для читаних мовами людей, можуть бути значною мірою порожніми, необхідно виконати певну обробку коду, перш ніж він буде збережений в оперативній пам'яті. У багатьох випадках обробка тексту перфорованої карти у формі, яка підходить для безпосереднього виконання процесором, не є більш складною, ніж її обробка у формі, яку можна ефективно обробляти через інтерпретатора.

Зверніть увагу на те, що метою перших компіляторів було не створення мови або файлу об'єктного коду на диску, а скоріше коду в оперативній пам'яті, який був готовий до виконання. Це насправді дивно легко, коли немає жодної операційної системи, яка б заважала. Компілятор може генерувати код, починаючи з одного кінця пам'яті, і виділяти змінні і цілі галузі, починаючи з іншого. Якщо оператор позначений міткою "1234", компілятор зберігатиме в змінну з назвою "1234" інструкцію для переходу до поточної адреси генерації коду, створюючи цю змінну, якщо вона не існує. Оператор "goto 1234" створить змінну "1234", якщо вона не існує, а потім перейти до цієї змінної [яка буде сподіватися, що перейти до відповідного розташування, збереженого в ній, до виконання цієї операції]. Зауважте, що компілятор не повинен робити нічого особливого, щоб дозволити коду goto мітку, яка ще не була визначена, оскільки вона знає, коли goto компілює, де збирається стрибати - до змінної. Це може бути не найефективнішим способом генерування коду, але він є адекватним розмірам програм, якими повинні були працювати комп'ютери.

1
додано
Диск? Умммм ... ні. Стрічка. Великі, повільні стрічки з котушками до котушки. І багато їх. Пам'ятаю, що я пішла на лекцію Грейс Мюррей Хопер (подвійно мені цікаво, тому що я був головним системним аналізом і мічманом у військово-морському загоні ВМС на території кампусу, а CAPT Hopper служив морським офіцером). Вона розповіла історію, де, за її словами, вона прийшла з ідеєю написання невикористаних частин програми на стрічку - вона назвала її "використовуючи допоміжне сховище". "Але", сказала вона, "ідея не прижилася, поки IBM не зробила те ж саме і назвала її віртуальною пам'яттю". CAPT Hopper дійсно не любив IBM ... :-)
додано Автор Matthew, джерело
@BobJarvis: Я не розглядав цей аспект, але одна і та ж загальна однопрохідна конструкція, яка була б використана для компіляції готового коду до оперативної пам'яті, могла б добре працювати з накопичувачем; вихід з компілятора перейде на стрічку, тоді стрічка буде перемотана і прочитана в послідовні адреси пам'яті і запущена безпосередньо, без необхідності мати будь-яку частину компілятора в пам'яті одночасно.
додано Автор supercat, джерело

Оскільки перекладачі потребують компіляторів для роботи.

Вищенаведене твердження насправді не так. Власне кажучи, ви можете створити інтерпретатор, ніколи не використовуючи або іншим чином взаємодіючи з компілятором. Але результати цього не виглядатимуть дуже схоже на те, що я думаю, ви розумієте під цими термінами.

У строгому сенсі компілятори та перекладачі роблять зовсім інші речі. Компілятор читає текст з якогось джерела і перетворює його в інший формат: мова асемблера, машинний код, інша мова високого рівня, структура даних або інше. Інтерпретатор, тим часом, приймає певну структуру даних і виконує на її основі інструкції.

What we tend to think of as a "compiler" nowadays is actually a compiler that has been paired with a code generator: a program that takes in data from some source, and outputs code in some format based on what it sees. That's a fairly intuitive use for compilers, and it was one of the first things compilers were created for. But if you look at it another way, this seems very similar to what an interpreter does. It always outputs code instead of performing more general operations, but the principle is the same.

If we look at it from the other side, an interpreter needs to get its data from somewhere. This is just data, so you can build it up in the same ways you'd build up any other kind of data. Since we're talking about interpretation, it seems natural that you could build your data based on instructions in a text file. But to do that, you'd need something to read in the text and create your data structure, and that's a compiler. It's hooked up to the interpreter instead of to a code generator, but it's a compiler all the same.

That's why compilers were written first. The idea of interpreting data structures wasn't new even when compilers were conceived, but compilers were the "missing link" that let programmers build those structures out of text.

0
додано
Послідовність символів "END" перетворюється в 128; "ЗА", 129; "NEXT", 130; "DATA", 131; Такі перетворення виконуються за допомогою "жадного" відповідності, у контекстно-вільному режимі. Якщо набрати "1 TENDER SUPREME", він буде проаналізований як [T] [END] [E] [R] [пробіл] [S] [U] [P] [REM] [E]. Коли буде виконано, він буде бачити "T", підбирати будь-які додаткові літери або цифри, шукати "T" як ім'я змінної, шукати знак рівності, не бачити один, і позначати синтаксичну помилку. Той факт, що END не має сенсу, як що-небудь інше, ніж перший маркер у висловленні, не має відношення до токенізатора.
додано Автор supercat, джерело
Не можна посилатися на текстовий редактор, який завантажив вхідний файл у форматі UTF-8 у список рядків UTF-16 як "компілятор"; перетворення, зроблені MS-BASIC, коли програма набирається, насправді не є більш суттєвими.
додано Автор supercat, джерело
Оригінальний інтерпретатор Basic для Apple] [був, з того, що я розумію, вручну переведений в машинний код і ніколи не існував у машиночитаному форматі вихідного коду. Я не впевнений, що "компілятор", ви б сказали, був використаний для його створення.
додано Автор supercat, джерело
Типові мікрокомп'ютерні інтерпретатори BASIC не виробляють нічого навіть віддалено нагадує синтаксичне дерево. Я не знайомий з оригінальним інтерпретатором Apple BASIC (називається "цілим BASIC"), але інтерпретатор BASIC, реалізований Microsoft для Apple ("Applesoft BASIC"), Commodore та інші компанії, зберігає текст програми як є, крім двох : (1) кожному рядку передував 16-розрядний номер рядка і 16-розрядний адреса наступного рядка, а за ним - нульовий байт; (2) кожне ключове слово було замінено на один байт, який мав високий набір бітів. Крім цього, вирази були проаналізовані ...
додано Автор supercat, джерело
... символ за символом зліва направо; оператор типу A = 1234 перетворить цифри 1, 2, 3 і 4 у число з плаваючою точкою під час виконання.
додано Автор supercat, джерело
Конвертер між кодуванням тексту, який здійснює перетворення символів за символом необроблених даних, замість виконання будь-якого семантичного аналізу тексту. Перетворення, зроблені інтерпретатором BASIC (MS або Apple або C64 або будь-який інший), менш складні, ніж ті, які виконуються, скажімо, інтерпретатором JavaScript, але вони значно складніші, ніж перетворення кодування, або навіть ті, що виконуються асемблером. Саме це підриває його до землі компілятора.
додано Автор The Spooniest, джерело
@supercat: Я не знаю, як був створений інтерпретатор Basic, про який ви згадували, але я не кажу про компілятори, які використовуються для створення інтерпретаторів. Я говорю про компіляторів, які є частиною перекладачів. Як частина свого коду, Apple] [інтерпретатор BASIC потребує певного способу, щоб прочитати в текстових файлах, що містять код BASIC, і створити синтаксичне дерево з тексту, який він потім виконує. Код, який робить це, є компілятором; він не генерує машинний код, але він все ще виконує завдання зчитування коду і переведення його в іншу форму.
додано Автор The Spooniest, джерело
@supercat: Це звучить ближче до байт-коду, ніж дерево синтаксису, тож я помиляюся в цьому. Але головне все ще стоїть: псевдобайт-код все ще повинен бути побудований з тексту, а код, який робить це, є компілятором.
додано Автор The Spooniest, джерело
@supercat: те, що ви описуєте, більше схоже на ассемблера, ніж інтерпретатор BASIC. Ассемблери не є компіляторами, це правда, але BASIC не є мовою асемблера: здається примітивним за сьогоднішніми мірками, але це все ще значний крок вперед від металу.
додано Автор The Spooniest, джерело