Compiladores/Pautas 2014-2015/Pauta do Projecto: Entrega Intermédia

From Wiki**3

< Compiladores‎ | Pautas 2014-2015
Revision as of 17:05, 9 February 2015 by Root (talk | contribs)

Prazo de Revisão

Critérios de Avaliação

VALORAÇÕES

PENALIZAÇÕES

Existem penalizações relativas à (deficiente) execução do projecto.

São considerados os seguintes aspectos preliminares:

  1. A linguagem do projecto contém a linguagem Simple, pelo que não há razão para não utilizar completamente o compilador Simple, eventualmente com pequenas alterações.
  2. A semântica da linguagem do projecto contém a da linguagem Simple, pelo que a implementação de alguns aspectos da linguagem do projecto não requer qualquer reimplementação relativamente ao Simple.
  3. O compilador Simple foi fornecido completamente funcional, assim como a versão inicial do compilador do projecto no respositório CVS (igual ao Simple e apenas alterado para ter o nome apropriado).
  4. A criação de novos nós não apresenta quaisquer dificuldades (são classes muito simples)
  5. O código dos métodos do visitor xml_writer corresponde a uma simples impressão dos atributos dos nós, através de uma travessia da árvore que formam e que os contém.
  6. O compilador é obrigatoriamente desenvolvido em C++.

Considerando os aspectos 1. a 6., são aplicadas as seguintes penalizações:

  • Destruição de funcionalidade do compilador Compact sem substituição por funcionalidade equivalente do compilador OB1: 4 valores

Não definição dos nós para regras BYACC em avaliação (ver acima) ou não utilização de nós definidos para a escrita dessas acções: 2 valores

A utilização de funções e estruturas C, quando existem alternativas directas C++ (malloc em lugar de new, por exemplo; strcmp, etc. em lugar da classe std::string; e outras) terá uma penalização máxima de 1 valor

× Não utilização de qualquer material obrigatório: 6 valores (e considera-se projecto não realizado)

DEBUG

Esta secção é apresentada como auxiliar ao aluno no despiste de problemas durante o desenvolvimento do compilador, especialmente para aliviar o problema do "debug via printf" (que pode, mesmo assim, continuar a ser usado).

Em lugar de destruir código, frequentemente para colocar no seu lugar uma instrução de escrita (algo que é, por vezes, executado de forma deficiente), sugere-se a utilização das potencialidades integradas nas ferramentas e no material de desenvolvimento:

No Flex, depois do primeiro %%, colocar (separado da primeira coluna do ficheiro por, pelo menos, um espaço), a instrução set_debug(1); (assume-se que a %opção debug está activa). Esta acção activa a produção de saída de "debug" do Flex, onde são indicadas a execução dos emparelhamentos de caracteres e a activação de regras, com indicação da linha da especificação que foi utilizada.

%option debug 
... 

%% 
        { set_debug(1); } 

... resto das regras...  

%% 

No shell, dar o seguinte comando (activa também o "debug" no BYACC, indicando a zona da gramática que está a ser utilizada):

export YYDEBUG=1

O visitor XMLwriter foi concebido para produzir uma representação textual hierárquica (árvore XML) correspondente ao programa em compilação. É muito útil para inspeccionar a contrução da árvore de nós por parte do BYACC, permitindo, inclusivamente, a apresentação gráfica.

Legenda

Pauta

<runphp> echo<<<___EOT___

</tbody>

___EOT___; </runphp>