Assembler no Linux

Assembly no Linux é possível? Essa é a pergunta que muitos fazem, velhos tempos DOS e MSX, tempos que não voltam mais, será? Neste artigo abordo como os veteranos de Assembly podem voltar a se divertir sem a necessidade de DOS ou MSX.

[ Hits: 32.384 ]

Por: Cleber J Santos em 17/02/2009


Assembly no Linux é possível?



Tempos de DOS e MSX, velhos tempos que não voltam mais, onde programadores se divertiam com o livros para DOS, e que hoje encontramos todos reeditados. Não pude desfrutar dessa época, mas para quem deve lembrar eram livros que ensinavam a fazer coisas fantásticas para a época, como criar relógios no canto da tela

Para todos aqueles que não puderam desfrutar de boas literaturas do tempo, hoje estão de volta. Sempre tive uma grande queda por linguagens antigas, como COBOL, BASIC,PASCAL, FORTRAN e claro o ASSEMBLY, mas dentre todas essas eu sempre achei que Assembly era coisa de doido, e ainda acho, sendo assim não tenho como garantir minha própria sanidade mental já que vi algumas coisas para doidos, digamos que pude provar do Elixir da loucura.

O Unix, Linux, FreeBSD, e não apenas este mas outros também da família BSD, nos oferece igual e se não muito maior potencial para fuçadores natos como eu. Bem sabemos o quanto estas plataformas se tornaram famosas tanto em grandes servidores como em sistemas embutidos (embedded systems).

Digamos que neste artigo vamos fazer um paralelo do que encontrava-se nas antigas literaturas conforme citado acima, e como "portar" os mesmos raciocínio para o Linux. Claro levando em consideração as características do sistema, não teremos como criar um exemplo do tipo relógio no canto da tela, não que não dê, mas é trabalhoso e teríamos que estender muito este artigo, vou tentar buscar a cabo com as explicações sobre como se comportam o que chamamos de interfaces disponíveis.

Modo Real e Modo protegido
Antes de mais nada lembremos das limitações que eram encontradas nos processadores antigos, 640 Kb se quer pareciam ser um problema já que para a época era o que se tinha disponível. A grande maioria eram baseados em processadores como o Z80 (Microprocessadores de 8 Bits e com endereçamento máximo e direto de 64Kb).

Já nos 80286, existia um modo de trabalho do processador que era chamado de modo protegido. Ou seja, quando o processador era ligado, se comportava como um 8086, mas após a entrada neste modo, novas características eram habilitadas, como maior capacidade de endereçamento de memória, permissões de acesso dessa memória etc.

A grosso modo podemos dizer que processadores em modo real, eram por exemplo os 386 que se portavam como um 8086, rodando diretamente programas, como o DOS em 16 Bits, com endereçamento de até 640 Kb, não importando o quanto tivesse instalado na máquina. E o modo protegido eram aqueles que apresentavam além de as vantagens citadas, a melhoria de forma de entrada e saída deste modo para o modo real, outra das vantagens do modo protegido eram as facilidades de multitarefas e que com certeza revolucionaram os programas da época.

A explicação sobre processadores de modo real e modo protegido se deu apenas para mostrar que o Linux no seu boot, inicia em "Modo real", mas muda para o "Modo protegido", em um dado momento. Portanto existem as regras deste modo, como o que chamamos de permissões de escrita, leitura e execução em trechos da memória. E com isso esclarecemos o por que não dá para dizer igual no DOS, alterar um endereço diretamente, sem levarmos em conta a quem pertence.

No caso do Linux, temos a memória que está protegida pelo Kernel, e que está disponível para os programas dos usuários (Kernel e User memories). Esta tentativa poderia causar um erro de segmentação (Segmentation Fault), uma exceção que é disparada pelo processador e sinalizada pelo Kernel, indicando que foi tentado uma operação não permitida.

Bem, agora sabemos que o Linux utiliza o máximo que pode de um processador e que é um sistema multitarefa, multiusuários e de 32 bits, que roda em "Modo protegido". Fazendo um paralelo sobre a BIOS, está claro que o software que roda nas BIOS de hoje em dia estão bem mais elaborados que antigamente até por que hoje em dia os Hardwares existente exigem isso, mas ainda temos a mesma limitação de interface como antigamente, inclusive se usa a mesma interface para os programas.

Mas estas interfaces não foram pensadas para um sistema multitarefa como o Linux, e portanto se fosse permitido usar as funções da BIOS, programando no Linux, teríamos um problema.

As rotinas não prevêem que mais de um processo pode tentar acessar o mesmo recurso e, portanto não implementam travas para isso, vamos ilustrar um pequeno exemplo em C, antes de mais nada vou dar uma explicadinha. A grosso modo o que faremos é, usar uma função que quando executada, checa se o flag busy é 0 (zero), se for significa que o recurso está livre, sendo assim é inicializado, flag setado para 1 e se procede o resto da função.

1  int Func (void) {
2     static char busy=0;
3     if (!busy){
4        init_stuff();
5        busy=1;
6     }
7     else {
8        fprintf(stderr,"Recurso ocupado\n");
9        return ERROR;
10    }
11 }

Na linha 2 criamos uma variável estática e inicializamos ela com o valor 0 para o flag, dessa forma sinalizamos o uso de um recurso, caso não esteja em uso linha 3, setamos na linha 5 o valor 1 do flag cimo 1 a fim de sinalizar o não uso de um recurso, caso o valor seja diferente de 1 então imprimimos na tela a mensagem de recurso ocupado que neste caso é um retorno de erro.

Enquanto este flag for 1, nenhum outro processo pode acessá-las, claro, existem as chamadas race-conditions, mas aqui estamos apenas demonstrando uma forma de checar o uso de um recurso em um ambiente multitarefa e que poderia com muita facilidade se transformar em algo caótico no meu ponto de vista como programador.

    Próxima página

Páginas do artigo
   1. Assembly no Linux é possível?
   2. Sintaxes Intel e AT&T
   3. Syscalls
Outros artigos deste autor

Ajustando o desempenho de discos rígidos

FreeBSD + Zope/Plone, uma idéia frustrante?

Escrevendo scripts no GIMP, pintando a cobra

Software Livre é o futuro

Screen, eita ferramenta porreta!

Leitura recomendada

Fazendo o Palm/Treo Funcionar no Ubuntu/KUbuntu

Impressora JPG no Linux compartilhada para Windows

Como criar pacotes "task" para o APT

Afrescalhando o Slackware

Criação de um repositório (mrepo) - Red Hat e CentOS 5 (com atualização na RHN para RedHat)

  
Comentários
[1] Comentário enviado por removido em 17/02/2009 - 20:55h

Artigo muito bom!
Até lembrei dos velhos tempos do MSX com o cartucho Mega Assembler. Para aumentar as vidas dos joguinhos era sensacional.

[2] Comentário enviado por f_Candido em 17/02/2009 - 21:53h

Me lembra um certo livro...
Bibliografia seria interessante.


Abraços

[3] Comentário enviado por Teixeira em 18/02/2009 - 07:02h

Viajei!!!!!

Muito boa essa "pequena" abordagem da Assembly Language dentro do universo Linux.

Se possível, gostaria de saber algo sobre utilização de cores, e diferenças de abordagem entre VGA e SVGA, e também que ferramentas ideais deveremos ter para programar em Assembly, tanto em computadores antigos quanto nos mais modernos.
Também como lidar com periféricos especiais (PCMCIA, USB, SATA, etc.).
Não precisa descer a detalhes, apenas alguma informação básica.

Uma opinião pessoal: TUDO que se refere ao Assembly sempre lembra algum livro...

Parabéns.


[4] Comentário enviado por m4iir1c10 em 18/02/2009 - 08:05h

Fiquei com vontade de voltar no tempo, muito bacana mesmo esse artigo, lendo ele me lembrei daquela interface de fundo azul com letras brancas que eu passava horas em frente dela sem me dar conta que o tempo estava voando... e claro que lembrei de um livro tmb... (concordo com o Teixiera)

[5] Comentário enviado por cleberjsantos em 18/02/2009 - 09:59h

Opa galera...

Valeu, legal mesmo, Texeira sobre VGA e SVGA inclusive sobre diversas abordagens estarei escrevendo novos artigos ;) Acho que é a forma mais fácil de entrar e falar do assunto, quanto a ferramentas ideais... Boa pergunta, normalmente vai de programador para programador, por exemplo neste artigo eu usei nada mais que o Kate como IDE para escrever o código, mas só fiz isso por que não havia ainda configurado meu VIM.

O que eu recomendo fortemente é que tanto para PC's novos quanto os da época da pedra lascada, use Linux claro :D tenha em mãos o <a href="http://www.gnu.org/software/binutils/">binutils</a>;, com ele você vai poder determinar que tipo de assembler deseja ter, sendo assim a cada desenvolvimento você terá que compilar o binutils para trabalhar com o assembler para determinado ambiente, ter o GCC para compilar e um bom chimarrão ou uma boa xícara de café ;)

Bem, conforme eu disse eu vou escrever mais sobre assembler, no meu site (www.cleberjsantos.com.br) claro, vai sair primeiro e depois estarei postando aqui, dai pretendo abordar o máximo possível de assembler para o Linux.

Ah, uma dica legal, vejam este artigo, é um sistema operacional feito em Assembler, e o mais bacana é que roda em um disquete, sendo assim não precisa dizer o poder do assembler: http://www.vivaolinux.com.br/artigo/MenuetOS-O-extraordinario-minisistema-operacional/

[6] Comentário enviado por cabrulcs_ em 19/02/2009 - 23:32h

De uma utilidade incrivel para mim. Até porque para programar antenas e microprocessadores, ou é assembly, ou não se programa! E infelizmente na faculdade ainda se necessita muito do DOS. Agora tenho uma saída na minha interminável luta de somente usar GNU/Linux.

... No final das contas, tudo é ASSEMBLY!!!

=D

Muito bom artigo!!!

[7] Comentário enviado por admtempos em 20/02/2009 - 09:16h

Muito bom este post ainda mais eu como sou iniciante no mundo de programação apesar de esta programando em php, ja tenho um pequeno conhecimento em c, mais o meu maior sonho e aprender a programar em assemble

[8] Comentário enviado por cleberjsantos em 20/02/2009 - 10:02h

Pois é, eu tbm estava me perguntando por que só DOS???? Ai batendo a cabeça no teclado eu vi a luz no final do tunel... hehehe.

[9] Comentário enviado por femars em 20/02/2009 - 14:34h

Só para título de curiosidade sobre AT&T, O "Criador" de C++ é o Bjarne Stroustrup (http://pt.wikipedia.org/wiki/Ficheiro:BjarneStroustrup.jpg), e que trampa para AT&T, inclusive o projeto que hj é o vnc tb saiu da AT&T.

[10] Comentário enviado por zend em 06/03/2009 - 11:31h

owww coisa boaaaaaaaa

[11] Comentário enviado por hra em 06/03/2009 - 14:18h

Muito bom.
É comovente saber que ainda existem programadores em linguagem de baixo nível (linguagens mais próximas da maquina que do homem).

Vou dar algumas informações para tentar complementar:

Em DOS a interrupção de serviços do sistema era a 21, onde se fazia quase tudo, ler teclado, mandar texto para a tela, acessar sistema de arquivos, etc. Essa interrupção é provida pelo kernel do DOS para ser acionada pelo programa, diferentemente de interrupções de hardware.
No linux é a interrupção 80 que provê todos esses recursos, claro que com um mapeamento totalmente próprio.

Em programação de Modo Real podíamos acessar a placa de vídeo diretamente pelo endereço de memória B800:0000, cada par de bytes correspondia a um caractere na tela. Em modo protegido esse endereço não existe, já que nesse modo cada processo recebe blocos de memória conforme requisita ao sistema, e esses blocos não correspondem a memória real e sim a memória virtual (que inclusive pode estar em swap).
Mesmo que tivesse acesso a placa de vídeo, no linux cada usuário tem um pseudo-terminal que não está necessariamente sendo exibido no hardware local.

Acesso a portas de hardware também é restrito. Nem adianta tentar acessar o hardware por uma seção de usuário, apenas módulos do kernel tem esse acesso.

É isso aí.
Assembly é tudo de bom.


Contribuir com comentário




Patrocínio

Site hospedado pelo provedor RedeHost.
Linux banner
Linux banner
Linux banner

Destaques

Artigos

Dicas

Tópicos

Top 10 do mês

Scripts