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

Critérios de Avaliação

VALORAÇÕES

Existem 6 valores (dos 20 disponíveis para o projecto) associados a esta entrega:

• gestão do projecto: 1 valor
  • projecto com a estrutura correcta no repositório CVS: 0.5 valores (i.e., código que não apresente a estrutura canónica de um compilador desenvolvido com a CDK é considerado sem a estrutura correcta -- consultar estas páginas sobre o desenvolvimento do projecto com base no repositório CVS)
  • projecto compila e produz compilador "pwn" ("pwn", com letras minúsculas: variações correspondem a "não compilação"): 0.5 valores

Se o projecto compilar, poderão ser atribuídos mais 5 valores (desenvolvimento do compilador), distribuídos como se segue:

• Flex (completo): 1.5 valores
  • Tokens correspondentes aos símbolos e palavras chave (simples ajuste do Simple)
  • Identificadores (simples ajuste do Simple)
  • Inteiros (deve estar implementada a base 16 -- a base 10 já está implementada no Simple)
  • Reais (extensão dos inteiros)
  • Strings (extensão do Simple)
  • O Flex deve retornar os tokens ao byacc (sobre DEBUG, ver abaixo) -- o não retorno de tokens penaliza fortemente toda a componente Flex (ver penalizações)

• BYACC (completo): 1 valor
  • Regras correspondentes a literais de reais e strings (simples extensão do Simple)
  • Regras correspondentes a ciclos, etc. (simples extensão e adaptação do Simple)
  • Regras correspondentes a declarações de variáveis
  • Regras correspondentes a declarações/definições de funções
  • As acções correspondentes às regras definidas no BYACC devem estar implementadas (simples criação de nós) -- a não implementação corresponde a penalizações (var abaixo)

• Nós (nodes) (completo): 1 valor
  • Todos os nós necessários para a linguagem (utilizados na especificação BYACC e em passos subsequentes) devem ser criados
  • A não criação de nós motivada pela ausência de definição de acções no BYACC é penalizada (ver abaixo)
  • Sugere-se (por simplicidade de gestão do código) a separação das várias classes de nós em namespaces coerentes (à la Compact; este aspecto, no entanto, não é avaliado)

• Semântica (visitors) (xml_writer completo; postfix_writer ver a seguir): 1.5 valores
  • O "visitor" xml_writer deve estar completamente implementado (ver também DEBUG abaixo)
  • O "visitor" postfix_writer deve ter todos os métodos (correspondentes aos nós, tal como o xml_writer), embora alguns possam estar ainda vazios (i.e., podem não executar qualquer acção)
  • Métodos correspondentes a acções semelhantes às existentes devem ser modelados nos existentes (exemplo, do_while_node -> do_for_node) (mesmo que não modificados numa primeira instância)
  • A presença de implementações de semântica no postfix_writer (tabela de símbolos, validação de tipos, etc.) não é penalizada, mas não será avaliada nesta entrega

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 Simple sem substituição por funcionalidade equivalente do compilador do projecto: 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.

Pauta

<runphp> echo<<<___EOT___

</tbody>

___EOT___; </runphp>