Аполлон-11: Використання включення замість лінкера


9

Нещодавно оцифровані та перетворені на репо, оригінальний вихідний код комп'ютерного наведення Apollo 11 став доступним для перегляду на Github .

У MAIN.agc автор репо коментує, що вони

розділити величезний монолітний вихідний код на менші, більш керовані фрагменти - тобто, на окремі # вихідні файли.

Трохи пізніше автор констатує

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

Я знаю, що таке лінкери, і я розумію їхню суть, але я ніколи не чув про фразу (наскільки це стосується ASM) "приєднаний шляхом включення".

Що це означає? Враховуючи, що лінкери - це велика справа в програмуванні, мені цікаво, що таке заміна лінкерів на "засоби включення" і як це працює.


7
Прикладом "об'єднаного шляхом включення" може бути #includeдиректива в C. Іншими словами, замість того, що кодовий бінг, складений на компоненти, які потім пов'язані між собою, схоже, що $позначення включає вміст цього файлу, щоб генерувати один великий вихідний файл. Потім один великий вихідний файл збирається як єдине ціле.
Девід Арно

1
@DavidArno ваш коментар здається кращою відповіддю, ніж будь-який із двох відповідей, які зараз є на дошці.
Ross Presser

Відповіді:


18

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


-2

Як просте включення порівнюється зі зв’язуванням?

Отже, просте включення здійснюється за допомогою #include "someCFile.c".

За замовчуванням лінкери додадуть бібліотеку виконання. З урахуванням цього потрібно було б включити.

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

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

З огляду на двійковий розмір, включення було б більшим.

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

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


2
Я не думаю, що це відповідає на питання "що це таке і як це працює".
tofro

tofro: Я інтерпретував "Що це означає?" як би це означало з практичної точки зору з точки зору двійкового розміру та швидкості виконання.
Роберт Барон

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

Швидкість виконання була б швидшою, оскільки всі функції мінімальної операційної системи знаходяться в межах виконуваного файлу, тому це просто виклики на відміну від використання переривань (я розглядаю мінімальну операційну систему, таку як DOS, де вона використовувала перериви 8086 здійснювати системні дзвінки). Крім того, оскільки вся операційна система буде включена, це займе більше місця, ніж коли її немає, і додасть часу на компіляцію.
Роберт Барон
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.