**PROJECT TITLE: mir
**GROUP: 5F
NAME1: Ana Margarida Cardoso Carraca, NR1: ei10001, GRADE1: 18, CONTRIBUTION: 33
NAME2: Bruno Miguel Mendonça Maia, NR2: ei09095, GRADE2: 18, CONTRIBUTION: 33
NAME3: Francisco Paulo Alves Ferreira, NR3: ei09075, GRADE3: 18, CONTRIBUTION: 33
** SUMMARY: Elaboramos uma ferramenta gráfica que interpreta um programa (i.e. um conjunto de funções) escrito com recurso a 3-address-code no formato MIR, para depois o analisar. O resultado final é a geração e visualização de vários elementos:
- Árvore de Sintaxe Abstracta
- Control Flow Graph, devidamente anotado e com possibilidade de ser exportado para dotty
- Grafo de interferências
- Alocação de registos, com recurso a graph coloring, sendo que o número de registos disponíveis está devidamente parametrizado
- Relatório sobre lifeness das variáveis:
- Onde começa
- Onde acaba
- Que registo lhe está atribuído
**DEALING WITH SYNTACTIC ERRORS: Depois do utilizador carregar o código de um programa e o compilar, o primeiro passo é a análise sintática. Nesta fase, caso sejam detectados erros, é feito o seguinte:
- A análise pára.
- Na área de logging, aparece uma mensagem indicativa da causa do erro e linha onde este ocorreu.
- A linha é realçada a vermelho no visualizador de código
**SEMANTIC ANALYSIS: As verificações semânticas realizadas são as seguintes:
- Verificação da integridade dos saltos: Cada "goto" tem de levar a uma label válida.
- Verificação da integridade das chamadas de funções: Cada instrução "call" (chamada de função) tem de ter um destino válido (i.e. a função de destino existe) e o número de parâmetros correcto.
- Verificação da declaração das variáveis: Para uma variável poder ser lida, primeiro tem de ter sido escrita.
- Verificação de existência de um entry point: Tem de existir uma função chamada "main".
- Verificação de inexistência de funções anónimas Todas as funções devem ser precedidas por uma label que denota o nome destas. No caso de violação das regras de semântica, o procedimento utilizado é o mesmo que para erros sintácticos:
- Parar a análise.
**INTERMEDIATE REPRESENTATIONS (IRs): A geração de uma AST "prática" de utilizar, juntamente com as características da linguagem permite que a representação intermédia utilizada não seja mais do que a AST anotada com atributos relevantes (p.ex., se o nó for uma variável, interessa saber se o acesso à variável é de leitura ou escrita).
**CODE GENERATION:
**OVERVIEW:
**TESTSUITE AND TEST INFRASTRUCTURE: Os testes não foram automatizados; Para o nosso caso, a automatização teria poucas vantagens quando comparada com o tempo dispendido a implementá-la. Temos alguns programas exemplo que implementam algoritmos simples e que abrangem grande parte da especificação da linguagem. Estes exemplos sofriam uma introdução de erros deliberados quando era necessário verificar o correcto funcionamento dos mecanismos de detecção de erros. Os nossos visualizadores gráficos, em conjunto com o logger, tornavam o processo de verificação de funcionamento de acordo com o esperado simples e rápido.
**TASK DISTRIBUTION: Torna-se complicado apontar quem fez o que, visto que todos os elementos participaram em todas as fases do projecto e 90% do trabalho foi realizado e conjunto. A distribuição da carga de trabalho foi equilibrada.
**PROS: (Identify the most positive aspects of your tool)
**CONS: (Identify the most negative aspects of your tool)