Como se estrutura um projeto de linguagem de montagem?

5

Então, estou fazendo um curso MIPS depois de voltar para a escola; e estamos nos aproximando do ponto em que começamos nosso projeto final.

Sempre fui uma pessoa para projetos grandes e bem estruturados: muitas ferramentas de suporte, zonas de controle bem separadas e preocupação com o projeto, testes extensivos, e assim por diante. Infelizmente, eu realmente não conheço muito, ou nenhum, ferramental para código em assembly.

Inferno, no mais básico, eu não sei como compor vários arquivos (ou virar isso de cabeça: como separar grupos de procedimentos em arquivos, e inter-referenciar entre eles). prática padrão (ish) para essas coisas?

Com exceção de outras informações, suspeito que possa ter que usar o pré-processador C (ou m4 ): P para compor componentes; mas além disso, como você sugere que eu estruture um projeto maior?

Also welcome: Any advice on writing relatively maintainable / shareable, clean, assembly-language code, beyond “use 8-space hard-tabs.”

    
por ELLIOTTCABLE 09.06.2016 / 10:02
fonte

2 respostas

4

Um livro pode ser escrito sobre esse assunto. Eu aposto que alguns têm. . .

É difícil responder porque cada cadeia de ferramentas tem suas próprias forças, defeitos e peculiaridades. Eu devo ter estruturado diferentes projetos de meia dúzia de maneiras diferentes, mas vou mencionar os dois que eu mais usei.

Para quase todas as técnicas, você precisa particionar os componentes adequadamente. O objetivo é tornar cada módulo 1) uma caixa preta bem definida e documentada que possa ser facilmente usada sem a necessidade de cavar o código, e 2) geral o suficiente para que possa ser reutilizada como está em projetos subseqüentes. Todos os meus projetos usam os módulos "matemática", "dispatcher" e "timer". Então pode haver módulos para o SPI, I2C, SCI, PWM etc. Na maioria das vezes, essa separação de funcionalidade é bastante intuitiva.

A primeira técnica é montar cada módulo separadamente e depois colocá-los todos em uma biblioteca de objetos ("objeto" como código de máquina, não "objeto" como na programação orientada a objetos). Então, quando você escreve o programa principal, você apenas faz chamadas para as rotinas de sua biblioteca, e o vinculador irá automaticamente incluir os módulos de objeto necessários em seu executável.

Mas algumas cadeias de ferramentas não suportam bem as bibliotecas de objetos ou tornam difícil de criar e manter. Nessa situação, eu "incluo" cada módulo de origem necessário no final do programa principal, e o montador cria um grande módulo de objeto (o que facilita para o vinculador).

Em ambos os casos, o programa principal começa com uma lista em "includes" para as definições de hardware e as definições de macro (eu uso LOTS de macros, tanto para legibilidade quanto para portabilidade). Então eu adiciono o código principal. Se eu estou usando uma biblioteca de objetos, então é isso. Se eu estiver usando uma biblioteca de origem, termino com uma lista de "includes" para os módulos de origem necessários.

Eu poderia continuar, mas é tarde. . .

    
por 09.06.2016 / 11:12
fonte
-1

Eu escrevi e mantive um pacote comercial de tamanho razoável em linguagem assembly (40.000 linhas de código de 16 bits e 35.000 linhas de 8 bits). Funcionou bem e teve zero bugs.

As únicas comunicações entre módulos possíveis eram que um símbolo (um endereço no código de programa ou um endereço de dados na memória) poderia ser declarado público em um módulo e externo em outro. Eu não me incomodei com bibliotecas porque assemblers e linkers são rápidos o suficiente de qualquer maneira, então compilar e ligar tudo a cada vez funcionava muito bem.

Arquivos de cabeçalho foram usados para definir constantes, mas também poderiam ser usados para declarar símbolos externos também.

Essa é a mecânica disso. Quanto à escolha do que dividir em qual módulo de origem, isso é programar como uma arte literária e você precisa descobrir o que funciona melhor para você. Eu tinha uma camada de rotinas de utilidade (mesmo aritméticas) na parte inferior e, em seguida, divisões verticais para diferentes áreas de funcionalidade.

A liberdade de montagem é ao mesmo tempo libertadora e desafiadora, mas é uma oportunidade inigualável de desenvolver seu próprio estilo.

    
por 09.06.2016 / 18:30
fonte