Como j´a foi definido, um compilador ´e um programa especial capaz de traduzir um arquivo escrito em uma linguagem de programa¸c˜ao espec´ıfica em um outro arquivo contendo as instru¸c˜oes, dados e endere¸cos que possibi- litam a execu¸c˜ao do programa por um processador particular. O compilador ´e, portanto, capaz de entender um algoritmo expresso em termos de uma linguagem de programa¸c˜ao, convertendo-o nas instru¸c˜oes necess´arias para sua execu¸c˜ao por um processador particular (vide Figura 4.9).
Figura 4.9: Compilador e cross-compilador
Todas as defini¸c˜oes internas s˜ao transformadas em c´odigo. Fun¸c˜oes, es- truturas de dados e vari´aveis externas, tem apenas o local de chamada mar- cado em tabelas de s´ımbolos externos para liga¸c˜ao posterior com bibliotecas ou outros m´odulos de c´odigo. Al´em de considerar o processador que execu- tar´a tais instru¸c˜oes, alguns aspectos da arquitetura e do sistema operacional devem ser observados pelos compiladores como forma de produzir c´odigo verdadeiramente ´util para uma dada arquitetura computacional.
No Exemplo 4.1 temos um trecho de c´odigo escrito em linguagem de alto n´ıvel e um poss´ıvel resultado de compila¸c˜ao.
Os compiladores podem gerar c´odigo de duas maneiras b´asicas, isto ´e, empregando dois modos de endere¸camento: o absoluto e o reloc´avel.
Quando no modo de endere¸camento absoluto, o compilador ima- gina que o programa ser´a sempre executado numa ´unica e bem determinada regi˜ao de mem´oria. Sendo assim, durante a compila¸c˜ao, o compilador associa diretamente posi¸c˜oes de mem´oria a estruturas de dados, vari´aveis, endere¸cos de rotinas e fun¸c˜oes do programa. Em outras palavras, o compilador fixa
// trecho de c´odigo fonte; trecho de c´odigo compilado while (...) { 0200: . . . ... a = a + 1; LOAD 500 . . . ...
printf("%d\n", a); CALL printf .
.
. ...
} JNZ 0200
Exemplo 4.1 Resultado da compila¸c˜ao
os endere¸cos de execu¸c˜ao do programa, realizando por completo o binding, tornando-se assim compiladores absolutos.
Figura 4.10: Arquivo objeto gerado atrav´es de compila¸c˜ao absoluta Na Figura 4.10, onde se apresenta a estrutura interna de arquivos gerados atrav´es de compila¸c˜ao absoluta, temos os elementos seguintes:
Cabe¸calho Regi˜ao onde s˜ao colocadas informa¸c˜oes gerais sobre o arquivo objeto e suas partes. Tamb´em conhecido como header.
C´odigo Segmento onde reside o c´odigo do programa, propriamente dito. ´E gerado da mesma forma que na compila¸c˜ao absoluta.
TSE A tabela de s´ımbolos externos ´e o local onde s˜ao listadas as posi¸c˜oes de chamada de s´ımbolos externos (vari´aveis, estruturas ou fun¸c˜oes).
Os arquivos objeto produzidos tem seus endere¸cos calculados a partir de um endere¸co de origem padronizado ou informado antes da compila¸c˜ao. Este endere¸co de origem, a partir do qual os demais s˜ao definidos, ´e chamado de endere¸co base de compila¸c˜ao ou apenas de endere¸co base. Desta maneira a compila¸c˜ao se torna mais simples, mas como conseq¨uˆencia direta disto temos que:
4.5. CRIAC¸ ˜AO DE PROGRAMAS 105 • um arquivo de programa execut´avel s´o pode ser executado numa regi˜ao
fixa de mem´oria;
• n˜ao podem existir duas ou mais instˆancias do mesmo programa exe- cut´avel na mem´oria, a n˜ao ser que se realizem compila¸c˜oes adicio- nais for¸cando a gera¸c˜ao do c´odigo para uso em diferentes regi˜oes de mem´oria;
• dois ou mais diferentes programas execut´aveis n˜ao podem ser carrega- dos na mem´oria a n˜ao ser que tenham sido compilados prevendo exa- tamente a ordem de carregamento e as ´areas adicionais de mem´oria que venham a utilizar;
• duas ou mais imagens execut´aveis n˜ao podem se sobrepor na mem´oria (ocupar os mesmos endere¸cos de mem´oria) total ou parcialmente; • uma imagem execut´avel deve sempre ocupar uma regi˜ao cont´ınua de
mem´oria;
• a soma das imagens poss´ıveis de serem carregadas em mem´oria para execu¸c˜ao paralela tem que ser menor ou igual a quantidade total de mem´oria dispon´ıvel.
As raz˜oes para estas limita¸c˜oes s˜ao simples e todas baseadas no fato de que dentro do arquivo objeto s´o existem n´umeros bin´arios. Tais n´umeros representam tanto os c´odigos das instru¸c˜oes do processador como os dados constantes do programa e tamb´em os endere¸cos determinados pelo compila- dor. Como existem apenas n´umeros bin´arios em todo o arquivo objeto, n˜ao ´e trivial a distin¸c˜ao entre instru¸c˜oes, dados e endere¸cos, tornando pratica- mente imposs´ıvel:
• reverter a compila¸c˜ao, pois o binding se tornou irrevers´ıvel, n˜ao sendo poss´ıvel reconstituir-se o espa¸co l´ogico que originou o programa; • modificar o endere¸camento do programa pois n˜ao se pode distinguir
que s˜ao os endere¸cos dentro dos arquivos objeto gerados pelos compi- ladores absolutos.
Quando no modo de endere¸camento reloc´avel, o compilador conti- nua realizando todas as suas tarefas, como no caso da compila¸c˜ao absoluta, fixando os endere¸cos de execu¸c˜ao durante a compila¸c˜ao, mas al´em de gerar o c´odigo o compilador reloc´avel monta o arquivo objeto da seguinte forma: O ´unico elemento novo no arquivo objeto ´e a TER (tabela de en- dere¸cos reloc´aveis) onde s˜ao relacionadas as posi¸c˜oes de todos os en- dere¸cos existentes dentro do bloco de c´odigo cujo valor depende da posi¸c˜ao inicial do c´odigo, ou seja, lista todos os endere¸cos relativos existentes.
Figura 4.11: Arquivo objeto gerado atrav´es de compila¸c˜ao reloc´avel Desta forma, a TER relaciona onde est˜ao os endere¸cos que deveriam ser modificados para permitir a transposi¸c˜ao da imagem execut´avel de uma regi˜ao de mem´oria para outra, constituindo o segredo dos compiladores re- loc´aveis, pois ´e atrav´es desta tabela que o binding torna-se revers´ıvel, ou melhor, alter´avel, o que corresponde dizer que o binding n˜ao se realizou por completo. Portanto temos as seguintes implica¸c˜oes:
• ainda n˜ao ´e poss´ıvel reverter-se a compila¸c˜ao em si pois apesar do binding ser alter´avel, ainda ´e imposs´ıvel reconstituir-se o espa¸co l´ogico original do programa;
• ´e poss´ıvel que outra entidade venha a modificar o atual endere¸camento do programa, pois os endere¸cos est˜ao evidenciados na TER, sendo que tal modifica¸c˜ao possibilita determinar o espa¸co f´ısico do programa em fun¸c˜ao da disponibilidade de mem´oria do sistema.
De qualquer forma o uso de compiladores reloc´aveis proporcionar´a as seguintes situa¸c˜oes:
• um arquivo de programa execut´avel poder´a ser executado em diversas regi˜oes de mem´oria, a serem determinadas pelo sistema operacional; • poder˜ao existir duas ou mais instˆancias do mesmo programa execut´avel
na mem´oria, sem a necessidade da realiza¸c˜ao de compila¸c˜oes adicionais para for¸car a gera¸c˜ao do c´odigo para uso em diferentes regi˜oes de mem´oria;
• dois ou mais diferentes programas execut´aveis poder˜ao ser carrega- dos na mem´oria sem que seja necess´aria a previs˜ao da ordem exata de carregamento e as ´areas adicionais de mem´oria que venham a ser utilizadas;
• duas ou mais imagens execut´aveis n˜ao podem se sobrepor na mem´oria (ocupar os mesmos endere¸cos de mem´oria) total ou parcialmente;
4.5. CRIAC¸ ˜AO DE PROGRAMAS 107 • uma imagem execut´avel deve sempre ocupar uma regi˜ao cont´ınua de
mem´oria;
• a soma das imagens poss´ıveis de serem carregadas em mem´oria para execu¸c˜ao paralela tem que ser menor ou igual a quantidade total de mem´oria dispon´ıvel.
Vemos que uma parte das limita¸c˜oes provocadas pelo uso de compilado- res absolutos podem ser contornadas com o uso do modelo de compila¸c˜ao reloc´avel. Como os ligadores n˜ao exercem participa¸c˜ao no binding no to- cante a modifica¸c˜ao ou finaliza¸c˜ao do binding, temos que os carregadores s˜ao os candidatos naturais a finaliza¸c˜ao do binding no caso da compila¸c˜ao reloc´avel.