Notas de Aula - MAC 211 - Laborat�rio de Programa��o

Aula 2 - 19/2/2009 - Preparando o caminho para a Linguagem de Montagem

Do c�digo-fonte de alto n�vel ao c�digo execut�vel

O ciclo de busca-execu��o

• O ENIAC (1945) era programado atrav�s de cabos e chaves liga/desliga
• A arquitetura proposta por John Von Neumann previa que o programa tamb�m era armazenado na mem�ria.
• Portanto, o computador funcionaria atrav�s de um ciclo de busca e execu��o (fetch-execute cycle):
1. O processador obt�m (l�) uma instru��o da mem�ria.
2. O processador executa essa instru��o.
3. O processador volta para o passo 1 avan�ando para a posi��o seguinte da mem�ria (a n�o ser no caso de uma instru��o de jmp ou similar)

Hist�ria do surgimento dos computadores pessoais

• Muitas vezes � dito que o primeiro computador pessoal da hist�ria foi o Altair lan�ado em 1975, mas a coisa n�o � t�o simples assim.
• A p�gina http://www.blinkenlights.com/pc.shtml cont�m um ponto de vista interessante sobre esse assunto que mostra que a coisa evoluiu muito mais lentamente.

Evolu��o da Arquitetura da fam�lia 80x86

• Arquitetura do 8080 usado no Altair:

• Arquitetura do 8086 usado nos primeiros IBM PC:

• Arquitetura do 80386, usados em PCs da d�cada de 1990:

Por que programar em linguagem de montagem? (Fonte: Linux Assembly HOWTO)

• you can access machine-dependent registers and I/O
  
  you can control the exact code behavior in critical sections that might otherwise involve deadlock between multiple software threads or hardware devices
  
  you can break the conventions of your usual compiler, which might allow some optimizations (like temporarily breaking rules about memory allocation, threading, calling conventions, etc)
  
  you can build interfaces between code fragments using incompatible conventions (e.g. produced by different compilers, or separated by a low-level interface)
  
  you can get access to unusual programming modes of your processor (e.g. 16 bit mode to interface startup, firmware, or legacy code on Intel PCs)
  
  you can produce reasonably fast code for tight loops to cope with a bad non-optimizing compiler (but then, there are free optimizing compilers available!)
  
  you can produce hand-optimized code perfectly tuned for your particular hardware setup, though not to someone else's
  
  you can write some code for your new language's optimizing compiler (that is something what very few ones will ever do, and even they not often)
  
  i.e. you can be in complete control of your code

Por que n�o programar em linguagem de montagem? (Fonte: Linux Assembly HOWTO)

• Assembly is a very low-level language (the lowest above hand-coding the binary instruction patterns). This means
  
  it is long and tedious to write initially
  
  it is quite bug-prone
  
  your bugs can be very difficult to chase
  
  your code can be fairly difficult to understand and modify, i.e. to maintain
  
  the result is non-portable to other architectures, existing or upcoming
  
  your code will be optimized only for a certain implementation of a same architecture: for instance, among Intel-compatible platforms each CPU design and its variations (relative latency, through-output, and capacity, of processing units, caches, RAM, bus, disks, presence of FPU, MMX, 3DNOW, SIMD extensions, etc) implies potentially completely different optimization techniques. CPU designs already include: Intel 386, 486, Pentium, PPro, PII, PIII, PIV; Cyrix 5x86, 6x86, M2; AMD K5, K6 (K6-2, K6-III), K7 (Athlon, Duron). New designs keep popping up, so don't expect either this listing and your code to be up-to-date.
  
  you spend more time on a few details and can't focus on small and large algorithmic design, that are known to bring the largest part of the speed up (e.g. you might spend some time building very fast list/array manipulation primitives in assembly; only a hash table would have sped up your program much more; or, in another context, a binary tree; or some high-level structure distributed over a cluster of CPUs)
  
  a small change in algorithmic design might completely invalidate all your existing assembly code. So that either you're ready (and able) to rewrite it all, or you're tied to a particular algorithmic design
  
  On code that ain't too far from what's in standard benchmarks, commercial optimizing compilers outperform hand-coded assembly (well, that's less true on the x86 architecture than on RISC architectures, and perhaps less true for widely available/free compilers; anyway, for typical C code, GCC is fairly good);
  
  And in any case, as moderator John Levine says on comp.compilers,
  
  "compilers make it a lot easier to use complex    data structures,
  and compilers don't get bored halfway through
  and generate reliably pretty good code."
  
  They will also correctly propagate code transformations throughout the whole (huge) program when optimizing code between procedures and module boundaries.
  
  

Sistemas de numera��o

• Decimal
• 123 = 1*10**2 + 2 * 10**1 + 3*10**0 = 100 + 20 + 3
• 123.456 = 1*10**2 + 2*10**1 + 3*10**0 + 4*10**-1 + 5*10**-2 + 6*10**-3
• Binario
• 11001010 = 1*2**7 + 1*2**6 + 0*2**5 + 0*2**4 + 1*2**3 + 0*2**2 + 1*2**1 + 0*2**0 = 128 + 64 + 8 + 2  = 202 (na base 10)
• Exercicio: converter 3 numeros de 8 bits para decimal
• Exercicio: converter um numero de 16 bits para decimal (calcular os 2 bytes em separado, depois multiplicar o mais significativo por 256 e somar o menos significativo)
• Exercicio: converter 3 numeros decimais para binario (professor faz o primeiro)
• converter 2725 -> 2725/2 = 1362 -> 681 -> 340 -> 170 -> 85 -> 42 -> 21 -> 10 -> 5 -> 2 -> 1
• portanto 2725 (decimal) = 101010100101 (binario) = 1+4+32+128+512 +2048
• outra forma de calcular para quem sabe as pont�ncias de 2 de cor: qual a pot�ncia de dois mais alta que cabe dentro do n�mero a transformar? (e.g. 131)
• alunos fazem outros dois numeros usando uma tecnica diferente em cada conversao
• bits mais significativos
• os 8 bits de um byte sao numerados de 0 a 7 da direita para a esquerda
• Hexadecimal
• digitos de 0 a F
• exemplos: 1234 FEA DEAD BEEF 0AFB FEED DEAF
• 2B (hexa) = 2*16 + 11 (decimal) = 43 (decimal)
• potencias: 1, 16, 256, 4096, 65536
• 137 (decimal): 137/16 = 8 sobram 9, entao 137 (decimal) = 89
• conferir: 8*16 + 9 = 137, confere.
• exercicios: converter dois numeros em cada direcao
• hexadecimais sao usados pois sao bem compactos, sao faceis de converter para binario e com dois digitos se representa exatamente um byte (nem mais nem menos).
• Calculadora calctool no Linux trabalha com bases 2, 8, 10 e 16.

Refer�ncias

• P�gina interessante de um curso na Universidade de Illinois sobre este assunto