| POR ONDE COMEÇAR | |||
Se você não sabe nada sobre conjunto de instruções, registradores, pilha, etc, não se preocupe. À medida que for necessário, todos os conceitos serão introduzidos. Antes de mais nada, vamos dar uma olhada na ferramenta de trabalho que iremos utilizar: o assembler. O verbo assemble, em inglês, significa reunir, armar, construir, montar. Um assembler, portanto, é um construtor (de programas, é claro ;-). Para se comunicar com o assembler utilizamos algumas convenções que o programa exige para poder executar as tarefas que se deseja. Cada assembler tem suas próprias convenções. Nos Tutoriais NumaBoa vamos utilizar o MASM32 como assembler, mas você pode usar qualquer um, como por exemplo o TASM. As diferenças são pequenas e é fácil se adaptar. |
|||
Quando você escreve um programa, na realidade está escrevendo um texto que contém um roteiro que deve ser transformado em um programa. Este texto é transformado em duas etapas. Primeiro precisa ser transformado em um novo roteiro que contenha as instruções para a CPU. Esta tradução produz os assim chamados arquivos objeto. O programa que produz arquivos objeto é chamado de assembler ou compilador. Os arquivos objeto, por sua vez, servem de fonte para outro tipo de programa: o linker. Os linkers adicionam referências de endereços aos arquivos objeto e os transformam em arquivos executáveis, a versão final do seu programa. Resumindo as etapas, temos o seguinte: Arquivo Texto (.ASM) ---> Arquivo Objeto (.OBJ) ---> Arquivo Executável (.EXE) Editor de Texto Assembler (compilador) Linker O MASM é um aplicativo que pode coordenar o seu trabalho: possui um editor de texto, um compilador e um linker. Através da janela do MASM você pode gerenciar todo o processo de produção de um programa. Aliás, todos os tutoriais NumaBoa estão baseados no MASM. Você pode escrever seu texto (ou script) em qualquer editor de texto, até com o bloco de notas do Windows. Como usaremos o MASM, podemos usar o editor de texto do próprio. Se escrevermos uma receita de bolo no editor de texto e pedirmos para o MASM (compilador+linker) transformá-lo em um programa... o MASM vai ficar perdidinho da silva. É preciso criar um texto que o MASM entenda e, o que é mais importante, obedecendo uma determinada estrutura. |
|||
A primeira informação que o MASM precisa para poder trabalhar é o tipo de CPU para a qual se destina o programa. Isto é necessário para que o compilador possa escolher o conjunto de instruções compatíveis com a CPU (lembra da comparação feita no texto Porque Assembly?? Precisa escolher o combustível certo para o tipo do motor). Como pretendemos produzir programas de 32 bits, indicamos o conjunto de instruções para o processador do tipo 80386 em diante (80386, 80486, Pentium etc). Geralmente, trabalhar com o conjunto de instruções do 386 é mais do que suficiente. Como é que passamos essa informação para o compilador? Usando uma diretiva apropriada: .386 ---> para processadores do tipo 80386 .486 ---> para processadores do tipo 80486 Por enquanto, nada de programa. Ainda precisamos indicar qual é o modelo de memória que deve ser usado. Um executável é carregado na memória de acordo com o modelo de memória definido durante a compilação. Na época dos computadores de 16 bits, o programa era carregado na memória em segmentos de tamanho predefinido. Era uma complicação danada gerenciar a execução do programa: para cada endereço era necessário indicar o segmento correspondente e saltar de um segmento para outro - parecia soluço e "comia" um monte de processamento. Com o advento dos 32 bits, os executáveis são carregados na memória em endereços contíguos. Imagine um segmento único de memória contendo o executável, uma tripa enorme contendo a sequência de instruções. Este modelo de memória foi denominado de FLAT, ou seja, modelo plano. Então, lá vai mais uma diretiva: .MODEL FLAT Nosso programa, com toda certeza (?) vai realizar algum trabalho, ou seja, vai ter funções. As funções geralmente precisam de dados para executar uma tarefa. Estes dados podem ser gerados na própria função ou serem enviados a elas. Dados enviados a uma função são chamados de parâmetros. A forma de mandar estes parâmetros também precisa ser definida previamente: se houver mais de um parâmetro, podemos enviá-los de frente para trás ou de trás para frente, ou seja, da esquerda para a direita ou da direita para a esquerda. Vamos a um exemplo: suponha que uma função espere receber dois parâmetros (param1 e param2). Podemos enviá-los na sequência param1, param2 ou na sequência param2, param1. A primeira convenção de passagem de parâmetros é conhecida como PASCAL e a segunda como convenção C. Os parâmetros recebidos são guardados temporariamente num registrador da CPU chamado de pilha (stack). Imagine a pilha como sendo uma pilha de caixas de sabão em pó no supermercado (hehehe). À medida que você colocar novas caixas na pilha, a pilha vai crescendo; à medida que tira, a pilha vai encolhendo; se você tirar uma caixa do meio da pilha, as caixas vão cair. Como o conteúdo da pilha é alterado quando uma função é chamada, ou a própria função pode alterá-lo, é preciso fazer um ajuste de pilha a cada retorno de função... senão a pilha "cai" e o programa dá pau. Na convenção de passagem de parâmetros do tipo Pascal, a função chamada fica sendo responsável pelo ajuste da pilha antes do retorno. Na convenção C, é a rotina chamadora a responsável. Existe uma terceira convenção de passagem de parâmetros denominada STDCALL (abreviação de STanDard CALL - chamada padrão). Usando esta convenção, os parâmetros são enviados da direita para a esquerda (como na convenção C) mas é a função chamada que é responsável pelo ajuste da pilha. A STDCALL é um híbrido das convenções Pascal e C. Os sistemas win32 utilizam exclusivamente a convenção de passagem de parâmetros STDCALL. Podemos e devemos completar a diretiva acima com: .MODEL FLAT, STDCALL Na maioria das vezes, o programa precisa de dados inicializados (com valores definidos) para poder começar a funcionar. São coisas do tipo nome do aplicativo, título da janela principal etc. Para indicar ao MASM que vamos listar nomes de variáveis e seus respectivos valores, usamos a diretiva .DATA. Tudo que o compilador encontrar nas linhas subsequentes, até encontrar outra diretiva, ele vai considerar como variáveis (dados) inicializados. Também podemos preparar variáveis não inicializadas, ou seja, fazemos com que o assembler ponha determinados nomes de variáveis na lista de variáveis. Estes dados não inicializados (sem valores definidos) podem ser usados posteriormente pelo nosso código. A diretiva .DATA? faz a indicação. Variáveis, como o próprio nome indica, podem ter seus valores alterados. No nosso projeto, pode ser que necessitemos de dados de valores fixos, as assim chamadas constantes. Neste caso, utilizamos a diretiva .CONST. Todos estes dados, indicados antes do programa propriamente dito, podem ser usados em qualquer ponto do código. Tanto faz se estamos no módulo principal ou em alguma subrotina (função), estes dados estão sempre disponíveis e acessíveis. São os chamados dados globais (variáveis e constantes). Enquanto o programa estiver sendo executado, estes dados ficam preservados. Só são destruídos quando o programa termina. Ufa! Finalmente chegamos no miolo do programa. É onde deve ficar o código que indica como nosso programa deve se comportar e o que deve realizar. A diretiva usada não poderia ser outra: .CODE indica o início do nosso código. Só que esta é a última diretiva da estrutura e o assembler não tem como saber onde ela termina. Estabelecemos então o limite com um rótulo seguido por dois pontos. O <rótulo> dá um nome à área de código e indicamos o fim da área com um "end <rótulo>". Você pode escolher o nome que quiser, por exemplo:
.CODE ---> Início do código
inicio: ---> Rótulo indicando o início da área de código
... (seu código)
end inicio ---> Fim da área de código
Em resumo, a estrutura que o MASM entende e aceita para assemblar e linkar é a seguinte:
.386
.MODEL FLAT, STDCALL
.DATA
... (aqui vão seus dados inicializados)
.DATA?
... (aqui vão seus dados não inicializados)
.CONST
... (aqui vão suas constantes)
.CODE
inicio:
... (aqui vai todo o código do programa)
end inicio
Por enquanto, é só... e tudo isto. Depois que você estiver programando em Assembly durante algum tempo, vai usar esta estrutura de diretivas automaticamente, sem problema algum - mas sempre é bom revisar o que realmente significam e como devem ser utilizadas. Para você que está começando, então isto tudo é novidade. Dê mais uma lida no texto e fixe bem os conceitos para evitar futuras dores de cabeça com programas "mal comportados". |
|||
Se existe um prólogo então deveria existir um contrálogo, ou mesmo um atélogo. Como não existiam, agora vão existir: declaro-os vivos e os promovo a entidades do jargão do Assembly NumaBoa. Bem, neste atélogo está o resumo do texto:
Um [] da vovó Vicki |
| Localizador | ||
|
| Localizador || @ Info NumaBoa > oicìliS > Assembly > Por onde começar Créditos: vovó Vicki webdesign sobMedida by vickiSoft - /informatica/oiciliS/assembler/comecinho.php (12.01.02) versão 1.2 de 02.08.03 Licença Creative Commons 1998-2006 Aldeia NumaBoa Exceto onde especificamente declarado, todo material deste site é disponibilizado de acordo com a Licença Creative Commons. | ||