Compiladores/Pautas 2018-2019/Pauta do Projecto: Entrega Intermédia

From Wiki**3

< Compiladores‎ | Pautas 2018-2019
AVISOS - Avaliação em Época Normal

Esclarecimento de dúvidas:

  • Consultar sempre o corpo docente atempadamente: presencialmente ou através do endereço oficial da disciplina [1].
  • Não utilizar fontes de informação não oficialmente associadas ao corpo docente (podem colocar em causa a aprovação à disciplina).
  • Não são aceites justificações para violações destes conselhos: quaisquer consequências nefastas são da responsabilidade do aluno.

Requisitos para desenvolvimento, material de apoio e actualizações do enunciado (ver informação completa em Projecto de Compiladores):

  • O material de apoio é de uso obrigatório e não pode ser alterado.
  • Verificar atempadamente (mínimo de 48 horas antes do final de cada prazo) os requisitos exigidos pelo processo de desenvolvimento.

Processo de avaliação (ver informação completa em Avaliação do Projecto):

  • Datas: 2019/03/22 17:00 (inicial); 2019/04/12 17:00 (intercalar); 2019/05/24 17:00 (final); 2019/05/27-2019/05/31 (teste prático).
  • Todas as entregas são cruciais para o bom desenvolvimento do projecto, sendo obrigatórias: a não realização de uma entrega implica a exclusão da avaliação do projecto e, por consequência, da avaliação da disciplina.
  • Verificar atempadamente (até 48 horas antes do final de cada prazo) os requisitos exigidos pelo processo de avaliação, incluindo a capacidade de acesso ao repositório.
  • Apenas se consideram para avaliação os projectos existentes no repositório oficial. Apenas se considera para avaliação o ramo 'main'.
  • Trabalhos não presentes no repositório no final do prazo têm classificação 0 (zero) (não são aceites outras formas de entrega). Não são admitidas justificações para atrasos em sincronizações do repositório. A indisponibilidade temporária do repositório, desde que inferior a 24 horas, não justifica atrasos na submissão de um trabalho.
  • A avaliação do projecto pressupõe o compromisso de honra de que o trabalho correspondente foi realizado pelos alunos correspondentes ao grupo de avaliação.
  • Fraudes na execução do projecto terão como resultado a exclusão dos alunos implicados do processo de avaliação em curso.
Material de Uso Obrigatório
As bibliotecas CDK e RTS de apoio ao desenvolvimento do projecto são de uso obrigatório:
A máquina virtual, fornecida para desenvolvimento do projecto, já contém todo o material de apoio.
Uso Obrigatório: Repositório GIT
Apenas se consideram para avaliação os projectos existentes no repositório GIT oficial. Apenas se considera para avaliação o ramo main.

Trabalhos não presentes no repositório no final do prazo têm classificação 0 (zero) (não são aceites outras formas de entrega). Não são admitidas justificações para atrasos em sincronizações do repositório. A indisponibilidade temporária do repositório, desde que inferior a 24 horas, não justifica atrasos na submissão de um trabalho.

Prazo de Revisão

PAUTA FECHADA

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

Critérios de Avaliação

LER COM ATENÇÃO

A entrega intermédia vale 6 valores em 20.

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.

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.

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 "m19" ("m19", 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 (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)
  • 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" type_checker 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)
    • 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 (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

O despiste de problemas em especificações Flex pode ser realizado de forma simples utilizando os métodos descritos em How to Debug a Flex Specification.

O visitor xml_writer 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

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).

Problemas na análise lexical
  • .* - uso indevido do padrão
  • chars - definição indevida (não existem na linguagem)
  • comments - problemas com comentários (em excesso ou em falta)
  • doubles - problemas com vírgula flutuante (definições incompletas)
  • idents - problems com identificadores
  • ints - problemas com inteiros (definições incompletas ou excessivas)
  • ops - problemas com operadores e afins
  • (bad) patterns - problemas genéricos com escrita de padrões lexicais
  • strings - problemas na definição de strings (composição, concatenação indevida, etc.)
  • [outros] - casos específicos (contactar professor responsável)
Problemas na análise sintáctica
  • conflicts - conflitos no analisador LALR(1) (não avaliado nesta entrega)
  • decls - problemas nas declarações (e.g. mistura com expressões ou com instruções)
  • empty rules - regras sem semântica associada
  • exprs - problemas nas expressões (em falta ou com inclusão de casos errados)
  • funcalls - problemas nas chamadas a funções (e.g. não estão definidos como expressões)
  • funcs - problemas (vários) nas declarações/definições de funções
  • lvals - problemas na definição de left-values (e.g. ausência de definições ou incompletas)
  • precs - problemas na definição de precedências (tipicamente, em excesso ou sem correspondência com o manual)
  • tokens - problemas na definição de tokens (tipicamente, em excesso ou sem correspondência com o manual)
  • read - problemas na definição da expressão de leitura (verificar manual de referência)
  • semantics - problemas na definição de acções semânticas
  • (simple) - contém apenas a definição original (linguagem Simple)
  • strings - problemas na definção de cadeias de caracteres
  • syntax - problemas na definição da gramática ou na semântica (nó) correspondente (verificar manual de referência)
  • [outras anotações] - casos específicos (contactar professor responsável)
Problemas na análise semântica e na geração de código (nós e XML)

Nos nós:

  • lvals - problemas na definição ou uso de left-values
  • decls - problemas na definição de declarações/definições de funções/variáveis
  • read_node - uso de left-value no read_node (não é uma atribuição, pelo que não tem left-values); ou derivação de basic_node (mas deve ser uma expressão); ou derivação de unary_expression (mas não tem argumentos); ou remoção do nó
  • [outros nós] - nós com problemas (nós excedentários ou em falta ou com problemas na definição)
  • [outras anotações] - casos específicos (contactar professor responsável)

No visitor xml_writer:

  • ast - o método "ast" do compilador não foi chamado no parser (.y), pelo que a AST está indefinida
  • empty - métodos vazios ou funcionalmente vazios
  • (incomp) - código incompleto
  • [outras anotações] - casos específicos (contactar professor responsável)

Pauta

Aqui: https://fenix.tecnico.ulisboa.pt/disciplinas/Com5645111326-2/2018-2019/2-semestre/pautas-da-disciplina