Embedded Files
O código do simulador (versão alfa) pode ser baixado aqui.
Um pequeno tutorial sobre como projetar uma arquitetura usando este simulador pode ser lido no link "Projetando uma Arquitetura" abaixo.
Para conseguir usar satisfatoriamente o simulador há um pré-requisito inapelável: conhecer programação orientada a objetos.
Apresentações (formado Open Document)
Assembly (Arquitetura)
add %<regA> %<regB> || RegB <- RegA + RegB
add <mem> %<regA> || RegA <- memória[mem] + RegA
add %<regA> <mem> || Memória[mem] <- RegA + memória[mem]
add imm %<regA> || RegA <- imm + RegA
sub <regA> <regB> || RegB <- RegA - RegB
sub <mem> %<regA> || RegA <- memória[mem] - RegA
sub %<regA> <mem> || memória[mem] <- RegA - memória[mem]
sub imm %<regA> || RegA <- imm - RegA
imul <mem> %<RegA> || RegA <- RegA x memória[mem] (produto de inteiros)
imul %<RegA> <mem> || memória[mem] <- RegA x memória[mem] (idem)
imul %<RegA> <RegB> || RegB <- RegA x RegB (idem)
move <mem> %<regA> || RegA <- memória[mem]
move %<regA> <mem> || memória[mem] <- RegA
move %<regA> %<regB> || RegB <- RegA
move imm %<regA> || RegA <- immediate
inc %<regA> || RegA ++
jmp <mem> || PC <- mem (desvio incondicional)
jn <mem> || se última operação<0 então PC <- mem (desvio condicional)
jz <mem> || se última operação=0 então PC <- mem (desvio condicional)
jeq %<regA> %<regB> <mem> || se RegA==RegB então PC <- mem (desvio condicional)
jneq %<regA> %<regB> <mem> || se RegA!=RegB então PC <- mem (desvio condiciona
jgt %<regA> %<regB> <mem> || se RegA>RegB então PC <- mem (desvio condicional)
jlw %<regA> %<regB> <mem> || se RegA<RegB então PC <- mem (desvio condicional)
NOTA: A ULA não possui operação de multiplicação. Com isso as operações imul deverão ser implementadas utilizando-se um trecho de memória (previamente reservada pela própria arquitetura), onde residirá um pequeno trecho de programa que executa um laço de execução e salva numa posição específica de memória. Lembrem de salvar os valores dos registradores antes de executar o imul, além do endereço para onde o programa deve voltar após sua execução, e de restaurá-los depois. Reserve posições de memória pra isso também.
Note que a posição de memória onde está o resultado deve ser usada para passar o valor da multiplicação para o destino correto (registrador ou memória).
Lembre que suas variáveis só podem ser alocadas na primeira posição livre após todos esses dados (e programas).
NOTA SOBRE A PILHA
Os registradores StackTop e StackBotton definem uma pilha que deve ser alocada a partir da primeira posição livre da memória, logo abaixo das variáveis. Note que a pilha é alocada em ordem "decrescente", ou seja, cada novo elemento é inserido na posição imediatamente anterior.
O registrador StackTop deve apontar para o topo da pilha e o registrador StackBotton deve apontar para o final da pilha (a posição imediatamente anterior à em que está alocada a última variável).
StackTop começa na mesma posição de StackBotton. A cada chamada Call se faz uma espécie de push(): o endereço de retorno deve ser inserido na posição indicada por StackTop. Em seguida, StackTop é "avançado" (mas, na memória, é recuado) uma posição. (você vai ter que manipular dados na ULA pra fazer este decremento. Seja criativo).
A cada chamada de um ret, se faz uma espécie de PC<-pop(): o registrador SackTop é "recuado" (mas, na memória, é avançado) uma posição e o conteúdo da posição apontada por ele deve ser enviado para PC.
Caso haja uma chamada ret em que StackTop e StackBotton estejam apontando para o mesmo endereço, então a pilha estará vazia. Você não precisa tratar esta condição (mas vai da merthiolate... só que a culpa é de quem fez o programa, não de seu hardware)
O projeto da disciplina consiste em projetar diferentes arquiteturas de computadores, considerando os aspectos de sua organização, conforme descrito no material da disciplina.
Cada equipe vai solicitar uma Organização diferente para projetar (Organização, A, B ou C - sim, a organização Referência está vetada. ), implementando a linguagem assembly (Arquiteturas) definida acima.
Note que, idealmente, cada escolha não se repetirá. Assim, quem solicitar primeiro terá preferência.
As equipes devem entregar o projeto funcionando plenamente: a linguagem assembly executando perfeitamente sobre a organização considerada descrita com exatidão. Elabore programas de exemplo que usem todos os comandos de cada assembly.
Exemplos de programas (escolha 3, pelo menos): cálculo de MDC usando algoritmo de Euclides. Cálculo de MMC usando algoritmo de Euclides. Geração do N-ésimo termo da sequência de Fibonacci. Somatório de todos os números menores que N. Somatório de todos os números entre M e N.
Obrigatório: implemente uma das soluções acima usando função (e veja sua pilha de execução funcionando!) utilizando registradores como parâmetros.
Bônus: Crie uma função recursiva!
Não se esqueça: no nível de Microinstruções, NÃO EXISTE FOR, IF, WHILE E MUITO MENOS CHAMADA A FUNÇÕES! Se alguma destas estruturas aparecerem nos microprogramas do seu projeto, você será penalizado!
Equipes de no mínimo UMA e no máximo QUATRO pessoas.
Equipes espontâneas: enviem email, (SUBJECT: EQUIPE OAC) com os nomes dos componentes para degas at uesc dot br até a meia-noite do dia 17/10/2025.
Equipes compulsórias: os nomes que não estiverem listados em alguma equipe espontânea até o instante limite serão colocados em equipes formadas compulsoriamente.
-----------------------------------------------------------------------------------------------------
"Degas! Minha equipe me abandonou! O que eu faço?"
Se isto acontecer, foi por um dos dois motivos: ou você escolheu mal seus colegas de equipe, espontaneamente, ou então você não quis escolher seus colegas de equipe.
Em qualquer desses casos culpa é sua, não minha.
❤️❤️❤️❤️❤️❤️
Page updated
Google Sites
Report abuse