moroso / cpu

The CPU for the Moroso project.

cpu

The CPU for the Moroso project.

cpu's Issues

cpu_sim: signed jumps aren't handled correctly.

For example, it decodes 0xd9ffffff as

- Instruction (d9ffffff):
  * [ P3] <BRANCH_OP> - B
  * offset = 33554431 (1ffffff)

but the offset should be -1.

cpu_sim: it would be nice to have a magic break to print the value in r0.

It would be nice to have an easy way to print the value in r0 (say, with a BREAK with a certain magic value). Ideally this would be printed somewhere other than the rest of the output (such as to stderr).

This way, I could test the existing compiler tests pretty easily on the cpu_sim, and verify that the output is what it should be.

cpu_sim: Instructions in a packet are executed sequentially

Example:

{ r0 <- 0 }
{ r0 <- 1; r1 <- r0 }

(encodes as 0xc0002000, 0xe0000000, 0xe0000000, 0xe0000000, 0xc0042000, 0xd4002020, 0xe0000000, 0xe0000000)
should leave r1 with the value 0, but will leave it with the value 1.

cpu_sim: MOV instructions use wrong shift amount?

The value of r1 definitely doesn't seem right after executing this instruction. I assume it's using the wrong shift amount? (There also seems to be a bug in printing the hex value of the shift amount!)

cpu.regs.r = { 1d, a0, 5, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, }
Packet is d4004000 / d4002020 / c0041042 / e0000000
Packet looks like:
- Instruction (d4004000):
  * [ P3] <ALU_OP> - ADD
  * rs = 0
  * rd = 0
  * rt = 1
  * shiftamt = 0 (81a268)
  * stype = 0
- Instruction (d4002020):
  * [ P3] <ALU_OP> - MOV
  * rs = 0
  * rd = 1
  * rt = 0
  * shiftamt = 0 (81a268)
  * stype = 0
- Instruction (c0041042):
  * [ P3] <ALU_OP> - SUB
  * constant = 1 (1)
  * rs = 2
  * rd = 2
- Instruction (e0000000): NOP
Executing packet...
...done.
cpu.regs.pc is now 0x20
cpu.regs.r = { bd, a0000000, 4, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, }

cpu_sim: would be nice to be able to read programs from a file.

Pasting into the c++ source and recompiling is nice and all, but... :)

ltc: solve, don't evade, race conditions

33b7f40 has a case of "evade, don't solve": resp_wr_1a is added to delay a cycle, where it shouldn't really be necessary. Either determine why it's microarchitecturally necessary, or fix the condition that leads to its necessity.