Compiladores/Pautas 2022-2023/Pauta do Projecto: Entrega "zero"

From Wiki**3

< Compiladores‎ | Pautas 2022-2023
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: 2023/05/15 17:00 (inicial); 2023/05/30 17:00 (intercalar); 2023/06/16 17:00 (final); 2023/06/16-19 (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

Os resultados da entrega inicial podem ser revistos, nos horários de dúvidas, até à data da entrega intermédia.

Critérios de Avaliação

A entrega inicial é obrigatória.

LER COM ATENÇÃO

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

Considerando que é um passo crucial na concepção do projecto, a não realização desta entrega conduz automaticamente a uma classificação de 0 (zero) na componente de avaliação relativa ao Projecto e consequente exclusão da avaliação da disciplina no ano lectivo actual.

Ver também: Compiladores/Projecto de Compiladores/Avaliação do Projecto (Época Normal).

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

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 2 valores (dos 20 disponíveis para o projecto) associados a esta entrega:

  • gestão do projecto: 0.5 valores
    • projecto com a estrutura correcta no repositório GIT: 0.25 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 GIT)
    • projecto compila e produz compilador "mml" ("mml", com letras minúsculas: variações correspondem a "não compilação"): 0.25 valores

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

  • Classes dos nós do compilador (completo): 1.0 valores
    • Reutilização dos nós da CDK (simples ajuste do Simple)
    • Definição ou extensão de elementos existentes (simples ajuste do Simple)
    • Definição de novas declarações/definições (variáveis/funções) (completo)
    • Definição de novas instruções (completo)
    • Definição de novas expressões (completo)
    • Definição de outros elementos (completo)
    • Sugere-se (por simplicidade de gestão do código) a separação das várias classes de nós em namespaces coerentes (à la Simple)
    • Não é necessário criar as regras na especificação Bison para criar os nós (se for feito, é conveniente para o progresso do projecto, mas não é avaliado nesta entrega)
  • Métodos dos "visitors" (completo): 0.5 valores
    • Reutilização de métodos já definidos (simples ajuste do Simple)
    • Definição de todos os métodos do_X (correspondentes ao nó da class X) em todos os visitors (simples extensão do Simple)
    • Métodos novos podem estar vazios, mas devem existir
    • Métodos correspondentes a acções semelhantes às existentes devem ser modelados nos existentes (exemplo, do_program_node -> do_function_definition_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 GIT (igual ao Simple e apenas alterado, para ter um nome apropriado).
  4. A criação de novos nós não apresenta quaisquer dificuldades (são classes muito simples).
  5. Os métodos (na sua maioria, vazios) dos "visitors" são simples paralelos com as classes dos nós e os que não estão vazios são quase 100% reutilizáveis na nova linguagem.
  6. O compilador é obrigatoriamente desenvolvido em C++, fazendo-se uso do material de apoio.

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: 2 valores
  • 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): penalização máxima de 1 valor
  • Não utilização de qualquer material obrigatório ou não satisfação dos critérios mínimos: 2 valores e considera-se entrega não realizada (implica exclusão da avaliação)

Legenda

Os alunos são encorajados a compreender/verificar/corrigir os problemas reportados, especialmente nos casos em que exista anotação explícita na pauta.

Anotações da tabela
  • dups: cópia de código que já está disponível na CDK (não devem existir estas cópias: devem ser usadas as classes da CDK)
  • pointer: este nó não deve existir
  • cycle: problemas vários com o nó de iteração
  • lvals: más utilizações de left-values (um left-value é a designação de um endereço de escrita)
  • index: problemas com os nós de indexação (e.g. não são lvalues, faltam expressões)
  • decls: faltam nós correspondentes a declarações ou têm problemas (e.g. confundidas com expressões, problemas com tipos, etc.)
  • func decls: problemas com declarações de funções (não existem)
  • func defs: faltam nós correspondentes a definições de funções ou têm problemas: e.g. faltam tipos, têm relações com lvalues (não devem existir), ou não são expressões
  • vars: faltam nós correspondentes a declarações/definições de variáveis ou têm problemas: e.g. faltam tipos, têm relações com lvalues (não devem existir)
  • exprs: faltam expressões (tipicamente, faltam operadores, chamadas a funções)
  • file/public/use/qualifier: nós que não devem existir
  • print/write: problemas com o nó de escrita
  • read/input: o nó de leitura deve ser uma expressão e não uma instrução; ao contário do que acontece no Simple, não tem um left-value associado
  • call: este nó tem de ser uma expressão que tem como atributos uma função e uma sequência de argumentos
  • alloc: este nó tem de ser uma expressão
  • address: este nó é uma expressão aplicável a um left-value
  • types: não foram os usados os tipos da CDK (basic_type e subclasses) para representar os tipos de dados da linguagem
  • [outras anotações específicas]: contactar o professor responsável

Pauta

(ver Fénix)

Retrieved from "https://web.tecnico.ulisboa.pt/~david.matos/w/pt/index.php?title=Compiladores/Pautas_2022-2023/Pauta_do_Projecto:_Entrega_%22zero%22&oldid=15759"