Apollo-11: Usando inclusão em vez de um vinculador

Recentemente digitalizado e transformado em um repositório, o código-fonte original do computador de orientação Apollo 11 foi disponibilizado para visualização no Github .

Em MAIN.agc , o autor do repo comenta que eles

divida o enorme código fonte monolítico em blocos menores e mais gerenciáveis - ou seja, em arquivos # individuais de origem.

Um pouco mais tarde, o autor afirma

Pode-se razoavelmente perguntar por que dezenas de milhares de linhas de origem são unidas por meio de inclusão, em vez de simplesmente reunir os arquivos de origem individualmente e depois vinculá-los para formar o executável. A resposta é que a equipe de desenvolvimento original não tinha vinculador.

Eu sei o que são os linkers e compreendo o objetivo deles - mas nunca ouvi falar da frase (no que diz respeito ao ASM) "unida por meio da inclusão".

O que isto significa? Considerando que os linkers são muito importantes em programação, estou curioso sobre o que é essa substituição de linkers por "meios de inclusão" e como ela funciona.

— 8protons
fonte

Um exemplo de "unido por meio de inclusão" seria a #includediretiva em C. Em outras palavras, em vez do código bing compilado nos componentes que são então vinculados, parece que a $notação inclui o conteúdo desse arquivo, a fim de gerar um grande arquivo de origem. Esse arquivo de origem grande é compilado como uma única entidade.

— David Arno

@DavidArno, seu comentário parece ser uma resposta melhor do que qualquer uma das duas respostas atualmente no fórum.

— Ross Presser

Respostas:

Eles parecem significar concatenação / inserção textual simples. Em outras palavras, mesmo que o texto de origem tenha sido dividido em arquivos individuais , o programa não foi dividido em módulos .

— Jörg W Mittag
fonte

-2

Como a inclusão simples se compara à vinculação?

A inclusão simples é realizada usando #include "someCFile.c".

Por padrão, os vinculadores adicionarão uma biblioteca de tempo de execução. Com a inclusão, isso teria que ser incluído.

Suspeito que a inclusão ocuparia menos espaço, pois os objetos não precisariam ter tabelas contendo pontos de entrada e potencialmente variáveis com nomes. Na vinculação dinâmica, a tabela do ponto de entrada deve estar lá. Não tenho certeza se a vinculação estática a removeria ou não, acho que não.

Em termos de velocidade de processamento, a inclusão é provavelmente um pouco mais rápida (definitivamente no caso de bibliotecas vinculadas dinamicamente), no entanto, não é tão flexível, pois vários aplicativos não poderiam compartilhar a mesma biblioteca.

Considerando o tamanho binário, a inclusão seria maior.

Considerando o tempo de compilação, a inclusão levaria mais tempo.

Para o computador de navegação da NASA, a inclusão simples era aceitável, pois o computador de navegação executava apenas um programa.

— Robert Baron
fonte

Eu não acho que isso responda à pergunta "o que é e como funciona".

— tofro

tofro: Interpretei o "O que isso significa?" como o que significaria do ponto de vista prático em termos de tamanho binário e velocidade de execução.

— Robert Baron

"inclusão seria maior" - Não entenda isso. Se o código está dentro, está dentro e usa o espaço - independentemente de como entrou no binário. Nem concorde com o tempo de compilação - uma compilação completa levará tempo idêntico. Você só ganha velocidade ao fazer builds incrementais, e duvido que isso já tenha sido praticado nos anos

— 60

A velocidade de execução seria mais rápida, pois todas as funções de um sistema operacional mínimo estão dentro do executável; portanto, são apenas chamadas, em vez de usar interrupções (estou considerando um sistema operacional mínimo, como o DOS, onde ele usou as interrupções do 8086 para fazer chamadas do sistema). Além disso, como todo o sistema operacional seria incluído, isso consumiria mais espaço do que quando não é e aumentaria o tempo de compilação.

— Robert Baron