Apollo-11：リンカーの代わりにインクルージョンを使用する

最近デジタル化されてリポジトリになり、元のApollo 11ガイダンスコンピューターのソースコードがGithubで表示できるようになりました。

ではMAIN.agc、レポ作者のコメント、彼らはその

巨大なモノリシックソースコードを、より小さく管理しやすいチャンク、つまり個別のソースファイルに分割します。

少し後で、著者は述べています

単純にソースファイルを個別にアセンブルしてからリンクして実行可能ファイルを形成するのではなく、何万行ものソース行がインクルードによって結合される理由を合理的に尋ねられる場合があります。答えは、元の開発チームにはリンカーがなかったということです。

リンカとは何か知っており、リンカの要点は理解していますが、「ASMに関する限り」「結合によって結合される」というフレーズは聞いたことがありません。

これは何を意味するのでしょうか？リンカはプログラミングにおいて非常に重要であることを考えると、「組み込み手段」によるリンカのこの置換が何であり、それがどのように機能するのか私は興味があります。

それらは単純なテキストの連結/挿入を意味するようです。つまり、ソーステキストが個別のファイルに分割されていても、プログラムはモジュールに分割されていませんでした。

単純な包含はリンクとどのように比較されますか？

したがって、＃include "someCFile.c"を使用することで、単純なインクルードが実現されます。

デフォルトでは、リンカーはランタイムライブラリを追加します。含める場合、これを含める必要があります。

オブジェクトにはエントリポイントや名前付きの変数が含まれている可能性があるテーブルを含める必要がないため、インクルードの方がスペースが少なくて済むと思います。動的リンクでは、エントリポイントテーブルが存在する必要があります。静的リンクがそれを削除するかどうかはわかりませんが、削除しないと思います。

処理速度の点では、組み込みはおそらく少し高速です（動的にリンクされたライブラリの場合は間違いなく）。ただし、それほど柔軟ではなく、複数のアプリケーションが同じライブラリを共有できませんでした。

バイナリサイズを考慮すると、インクルードはより大きくなります。

コンパイル時間を考慮すると、インクルードにはさらに時間がかかります。

NASAのナビゲーションコンピューターでは、ナビゲーションコンピューターが1つのプログラムしか実行しなかったため、単純な組み込みで問題ありませんでした。