Observacoes sobre o EP1

[Nelson Posse Lago <lago@that.com.br>]

Ola' a todos,

Bom, depois de corrigir os EPs de linguagem de montagem, nos (os
monitores) gostariamos de fazer algumas observacoes sobre o codigo de
voces (alem dessas observacoes gerais, deixamos algumas observacoes sobre
os trabalhos no panda):

- o arquivo readme que foi pedido nao e' uma mera formalidade para amolar
  a paciencia dos alunos. A ideia e' informar:
  - o que e' o programa ("esse programa calcula o produto escalar de dois
    vetores n-dimensionais cujas coordenadas sao fornecidas
    interativamente pelo usuario");
  - qual a estrutura do codigo, para facilitar a vida de quem vai ler o
    fonte do programa ("o programa le as n coordenadas em dois vetores
    alocados dinamicamente e executa o calculo atraves de uma funcao em
    linguagem de montagem chamada 'produto_escalar'; essa funcao avanca
    dois ponteiros pelos dois vetores, multiplica as coordenadas e acumula
    a soma em %EBX");
  - como compilar o programa ("para compilar, digite gcc -o prodesc ep1.c
    ep1.s");
  - observacoes gerais ("o numero maximo permitido de coordenadas de cada
    vetor e' 65535; o programa nao verifica se houve estouro de memoria na
    alocacao dos vetores; para ler as coordenadas, o programa usa a
    biblioteca 'blah', que precisa estar disponivel no sistema; etc.
    etc.").

- O estilo de escrita de codigo varia muito entre pessoas, instituicoes
  etc. Eu costumo considerar o estilo proposto para o kernel do linux como
  sendo muito bom. Sugiro que voces leiam o texto disponivel em
  /usr/src/linux/Documentation/CodingStyle e a pagina do prof. Feofiloff,
  http://www.ime.usp.br/~pf/algoritmos/aulas/layout.htm .

- comentar codigo e' uma arte: comentarios a mais sao quase tao ruins
  quanto comentarios a menos, e o que e' "a mais" e "a menos" e' um tanto
  quanto subjetivo (mas eu achei que a maioria dos EPs que tiveram
  problemas com isso pecaram para o lado "a menos"). O livro "the practice
  of programming" ("a pratica da programacao", disponivel em portugues) de
  Kernighan & Pike, fala um pouco sobre isso.

- Algumas pessoas se preocuparam em tratar possiveis erros ao longo do
  programa (estouro de memoria, valores invalidos fornecidos pelo usuario
  etc.). Essa e' uma pratica muito saudavel que deveria ser seguida por
  todos, embora uma boa estrategia para tratamento de erros seja uma coisa
  dificil de desenvolver.

- Poucas pessoas usaram o comando "loop"; ao inves disso, fizeram os
  lacos com "jnz" ou algo semelhante. Em geral, e' bom interiorizar o
  "sotaque" que cada linguagem de programacao sugere como sendo o mais
  comum, muito embora outras formas de realizar a mesma operacao existam.

- quando a funcao em assembler e' chamada, os dados que foram colocados na
  pilha para que ela acesse sao dados temporarios da funcao assembler, ou
  seja, voce pode modifica-los `a vontade; nao e' preciso copia-los para
  uma outra variavel local.

- Varias pessoas leram o valor do tamanho do vetor com uma variavel
  "short"; isso limita o tamanho maximo do vetor a 32767 coordenadas ao
  inves de 65535, que e' o que e' sugerido pela especificacao do EP. Por
  outro lado, varios usaram variaveis "int" para ler o tamanho dos
  vetores; embora isso seja muito menos grave, nao coincide com o que
  esta' no enunciado do EP, ja' que ali esta' evidente que a funcao
  assembler deve ser capaz de tratar vetores de ate' 65535 coordenadas.

- Alguns EPs alocaram "n+1" posicoes em cada vetor. Nao consegui descobrir
  por que, mas no caso do EP certamente essa nao e' a coisa certa a fazer;
  se o programa estava "dando pau" sem isso, ha' algum erro de logica no
  programa.

O primeiro item pode parecer bobagem, mas num trabalho um pouco maior que
o EP1 (por exemplo, o EP2), e' fundamental.

Bom, e' isso.

Ate' +,
Nelson e Thiago