Чому перед першим перекладачем був написаний перший упорядник?

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

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

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

• З перекладачем ви повинні зберігати і пам'ять, і програму. У епоху, коли 1 кб пам’яті було величезною розкішшю, збереження низького сліду пам’яті працювало. А для інтерпретації потрібно трохи більше пам’яті, ніж виконання компільованої програми.
• Сучасні процесори надзвичайно складні з величезними каталогами інструкцій. Тож написання хорошого укладача - це справді виклик. Старі процесори були набагато простішими, тому навіть компіляція була простішою.
• Сучасні мови набагато складніші за старі, тому навіть компілятори набагато складніші. Старі мови, таким чином, мали б простіші компілятори.

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

На той час кращі користувацькі інтерфейси в основному обмежувались перфокартами та телевізійними принтерами . У 1961 році система SAGE стала першим дисплеєм CATode-Ray Tube (CRT) на комп'ютері. Таким чином, інтерактивна природа перекладача була не кращою або природною набагато пізніше.

Численні комп'ютери 1950-х років використовували перемикачі на передній панелі для завантаження інструкцій, а вихід був просто рядами ламп / світлодіодів, а любителі навіть використовували перемикачі на передній панелі та світлодіоди у 1970-х. Можливо, ви знайомі з сумнозвісним Altair 8800 .

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

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

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

Додаток

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

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

З точки зору інформатики, компілятори та перекладачі є як перекладачами , так і за рівнем складності для впровадження.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Тому що перекладачам потрібні компілятори, щоб працювати.

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

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

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

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

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

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