Wiki**3

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:
CDK14 - "Compiler Development Kit" media:libcdk14-201902132207.tar.bz2 RTS4 - "Run Time System" media:librts4-201602111900.tar.bz2
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: 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. 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. 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). A criação de novos nós não apresenta quaisquer dificuldades (são classes muito simples) 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. 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