# Resultados dos programas para Breno

## Programa data_transfer.asm

O programa em questão testa se as instruções de transferência e tal...

A explicação básica é colocar dados na pilha, salvar esses dados na memória em endereços específicos e colocar na pilha novamente a partir da memória em uma ordem diferente.


No final o resultado esperado são dados na pilha nessa ordem:

8 1 4 2

### Testbench

O testbench vai verificar o empilhamento, transferência da pilha para memória e desempilhamento. No final ele vai ler o ponteiro as primeiras 4 posições do ponteiro e criar um número decimal usando o seguitne critério:

$$
N = \sum_{i=0}^4 stack[i]\cdot10^i
$$

Dessa forma o número esperado ao final de todas as instruções é 2418. Esta foi a forma encontrada para apresentar o teste de todas as instruções, outros testes foram feitos (só pra ele nao xiar kkkk) mas foi escolhido apresentar o atendimento dessas instruções de transferencia de dados a partir deste programa


### Resultados


## Programa ula.asm

Breno é bom deixar claro que a ula foi testada antes.. e que a ideia aqui foi testar a execução correta do programa e não testar ostensivamente diferentes operações.

A ideia desse programa é básica: testar todas as instruções da seguinte forma: Insere os valores dos operandos através do PUSH_I (push imediato), executa a operação e faz um desempilhamento para esvaziar a pilha e não atrapalhar na próxima instrução

Como ele ficou fino.. da pra colocar o resultado dele do lado dele kkkk e já apresentar a saída do testbench

Segue o programa:


### Testbench


### Resultados


## Programa loop.asm

Este programa teve como finalidade testar a capacidade de se gerar desvios, o programa teve com objetivo criar um loop infinito para testar isoladamente a função GOTO assim como capacidade da arquitetura de mudar o contador de programa.


As instruções linhas 0:2 fazem uma soma de 1+1 e devolvem a saída na pilha. A instrução da linha 3 retorna para a linha 1, que vai adicionar um operando e a linha 2 volta a somar o resultado da ula com o operando 1. Espera-se que este programa nunca chege nas linhas 4, 5 e 6.

### Testbench

Para o testbench, será verificado se no estado do controlador de decodificação, qual o número da instrução que está sendo executada. (todas as instruções passam por esse estado, por isso a escolha)


### Resultados


De forma similar foi feito para testar a capacidade de se gerar desvios para todas as branches


A ideia foi gerar um test verdadeiro e um falso, o primeiro desvio através do branch é verdadeiro é pula pula para instrução 2 e o segundo desvio através dos branches é falso e não deve pular para instrução 0.

Nesta configuração a arquitetura deve ser capaz de se chegar na instrução 5 apenas se a instrução de branch estiver correta para casos de desvio ou não.

Foi testado para todas as instruções mudando os operandos para fazer estes testes e omitido mas tá lá zipado kkk todas as isntruções chegaram na instrução 5 colocando 20 na pilha.

## Programa routines.asm

Para testar a capacidade de rotina foi feito uma funçãoq ue soma 2 numeros que já estão na pilha e desempilha estes numeros para memória.


Neste programa, a rotina é iniciada no endereço de programa 6 e é executada as instrução 6,7, 8 quando a instrução de retorno RET é utilizada. Sendo assim é esperado que a função seja chamada 2 vezes, uma para executar 2+3 e outra para fazer 3+4

O testbench é esse ai.. ele verifica através do endereço de programa, qual instrução tá sendo executada e em que ordem


### Resultados


Como esperado a routina no endereço de programa 6 foi chamada 2x, uma vez logo após a instrução no endereço 2 e outra logo após a instrução no endereço 5, sendo essas duas instruções, uma CALL. É possível verificar também a capacidade da cpu de retornar para a instrução que estava sendo executada após o RET.

### Waveform

Aproveitando e mostrando o valor no testbench

Tá no telegram essas imagens, será que bate botar wave formw???? saindo aqui do café 21:57 fui kkk