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

From Wiki**3

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

Prazo de Revisão

A entrega intermédia pode ser revista até à data da entrega final do projecto.

Critérios de Avaliação

LER COM ATENÇÃO

A avaliação da entrega intermédia considera a execução de intervenções em várias regiões do código do compilador em desenvolvimento, assim como a gestão do projecto correspondente.

A avaliação é realizada sobre a versão existente no CVS no final do prazo para a entrega intermédia. Projectos que não apresentem alterações relativamente ao conteúdo inicial do repositório CVS ou relativamente à entrega inicial não serão considerados.

Advertem-se os alunos sobre a consulta de colegas de anos anteriores. Estas consultas podem ser positivas, mas comportam algum risco, pois o processo e critérios de avaliação podem ter mudado. Além disso, a proficiência do colega pode majorar negativamente o resultado da avaliação em curso. Não são admitidas quaisquer justificações com base na história da disciplina.

Estas condições são aplicáveis à data da entrega intermédia.

Em caso de dúvidas suscitadas por qualquer elemento neste texto, no projecto, ou na disciplina em geral, os alunos são fortemente encorajados a consultar o corpo docente.

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.

Legenda

A entrega intermédia vale 6 valores em 20.

Resultados de compilação: (a disponibilizar)

Os alunos são fortemente encorajados a compreender/verificar/corrigir os problemas reportados. Alunos cujo projecto não compile (e apenas esses), podem solicitar correcção de versão nova a partir do CVS (desconto aplicável). Não se considerarão outras alterações na avaliação intermédia.

A atribuição de pontos (positivos e negativos) é como já foi anunciado (resumido abaixo).

Existem 6 factores correspondentes a pontos positivos:

  • CVS: existência do projecto com estrutura correcta no repositório, incluindo presença de relatórios: 0.50 val.
  • Compilação: capacidade de produzir o executável 'pwn': 0.50 val. (este factor condiciona a atribuição dos restantes)
  • Léxico: qualidade e nível de desenvolvimento da especificação do analisador lexical: 1.50 val.
  • Sintaxe: qualidade e nível de desenvolvimento da especificação do analisador sintáctico: 1.00 val.
  • Nós: qualidade e nível de desenvolvimento da família de nós da árvore produzida pelo analisador sintáctico: 1.00 val.
  • Semântica: qualidade e nível de desenvolvimento dos geradores: 1.50 val.

Existem 2 factores correspondentes a pontos negativos:

  • Remoção da funcionalidade existente no Compact (até -4.00 val.)
  • Não implementação das acções do analisador sintáctico e correspondentes nós, etc. (até -2.00 val.)
  • Utilização de C em lugar de C++ (ver pormenores nos critérios) (até -1.00 val.)
  • Não utilização do material obrigatório (at -6.00 valores)

Quaisquer dúvidas ou sugestões, relativas a esta informação, devem ser enviadas ao responsável pela disciplina.

As questões relativas às colunas "Problemas" devem ser resolvidas quanto antes (nos horários de dúvidas ou, sendo possível, por correio electrónico).

Pauta

<runphp> echo<<<___EOT___

</tbody>

___EOT___; </runphp>