| @stekern | it's getting close, all tests pass except the last debug step one | 06:44 |
|---|---|---|
| @stekern | and there is something fishy with the uart test, only the line feeds show in the output | 06:45 |
| @stekern | this is a fun case: l.lwz r3, 0x2000(r0); l.divu r3, r3, r4 | 07:27 |
| @stekern | the load is in mem stage and the divu is in exec stage | 07:28 |
| @stekern | the result from the load is needed before the divu can 'start' | 07:28 |
| @stekern | currently the alu operations are 'held off' by the decode_valid signal, but I can't easily just cut that off whenever I notice notice that kind of condition | 07:32 |
| @stekern | perhaps squezing in a nop bubble in between the l.lwz and l.divu is the way to go | 07:33 |
| @stekern | juliusb: what do you think? | 07:33 |
| -!- Netsplit *.net <-> *.split quits: heroux, olofk | 08:10 | |
| @juliusb | stekern: what puts in the nop bubble? | 13:59 |
| @juliusb | the decode stage? | 13:59 |
| @stekern | juliusb: yes, I'm thinking that it could be detected there that there is a load or mfspr op in execute stage and an instruction in decode needing the register that that load/mfspr is going to write to | 14:57 |
| @stekern | so instead of outputting that instruction it outputs a nop and when the load/mfspr is done in mem stage the 'real' instruction is pushed out | 14:59 |
| @stekern | the other option I guess is to stall the decode_valid signal as long as memsatge is stalling | 15:00 |
| @stekern | *memstage | 15:00 |
| @stekern | but that will only help alu instructions, I need to postpone jumps to | 15:00 |
| @stekern | like: l.lwz r3, 0(r0); l.jr r3 | 15:01 |
| @stekern | connecting that stall signal directly to branch_occur works, but creates a naughty path | 15:02 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!