| 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: 2016/03/18 17:00 (inicial); 2016/04/15 17:00 (intercalar); 2016/05/20 17:00 (final); 2016/05/20-2016/05/27 (teste prático).
- A entrega inicial, sendo crucial para o projecto, é obrigatória e sua não realização 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 CVS.
- Apenas se consideram para avaliação os projectos existentes no repositório CVS oficial.
- 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 CVS
|
| Apenas se consideram para avaliação os projectos existentes no repositório CVS oficial.
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
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)
- 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 (exemplo, do_while_node -> do_repeat_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:
- 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
A entrega intermédia vale 6 valores em 20.
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.
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
- bases - problemas com bases (em falta)
- chars - definição indevida (não existem na linguagem)
- comments - problemas com comentários (em excesso ou em falta)
- delims - problemas com delimitadores
- floats - problemas com vírgula flutuante (definições incompletas)
- ids - problems com identificadores
- ints - problemas com inteiros (definições incompletas ou excessivas)
- keywords - problemas com palavras chave (a mais ou a menos)
- negative literals - problemas com valores negativos (não existem)
- ops - problemas com operadores e afins
- patterns - problemas genéricos com escrita de padrões lexicais
- strings - problemas na definição de strings (composição, concatenação indevida, etc.)
- type tokens - problemas com definição de tipos (e.g., uso do mesmo token dos literais)
- [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)
- 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 (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)
- [outros nós] - nós com problemas (excedentários 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 methods - métodos vazios ou funcionalmente vazios
- [outras anotações] - casos específicos (contactar professor responsável)
|
Pauta
<runphp>
echo<<<___EOT___
___EOT___;
</runphp>