| --- Log opened Mon Apr 22 00:00:26 2013 | ||
| stekern | juliusb: why are we setting spr_epcr to the last pc that had a branch on ibus errors? | 03:02 |
|---|---|---|
| stekern | I kind of agree that it makes sense to do that, because that's probably what you want to know in order to debug, but it's against what the arch spec defines | 03:03 |
| stekern | actually in espresso you set it to spr_ppc-4 | 03:10 |
| stekern | which in practice most likely is the same as the last branch pc | 03:16 |
| stekern | and or1k-insnfetcherror expects this behaviour | 03:19 |
| @juliusb | stekern: should EPCR be the address that we tried to access instad of the address of the jump to the bad address? | 12:00 |
| stekern | according to the arch spec, yes | 12:10 |
| stekern | it doesn't have to be a jump though | 12:13 |
| stekern | you can just run into the bad address linearily | 12:13 |
| @juliusb | fair enough | 12:17 |
| stekern | but looking at the instruction before the bad one, makes more sense, since you got the other info in eear | 12:23 |
| @juliusb | yes | 12:23 |
| @juliusb | EEAR is where that bad target address should go | 12:23 |
| @juliusb | reckon it's worth putting into the page proposing arch spec updates? | 12:24 |
| stekern | so basically the arch spec is the one that is wrong there | 12:24 |
| @juliusb | and leaving it as is on the mor1kx? or think we should be in line? | 12:24 |
| * juliusb agrees | 12:24 | |
| stekern | yup, probably | 12:24 |
| stekern | (put it up on the suggestion page) | 12:26 |
| mor1kx | [mor1kx] skristiansson pushed 2 new commits to master: https://github.com/openrisc/mor1kx/compare/14e0698dc9d9...d88fa67f8abf | 15:58 |
| mor1kx | mor1kx/master 7dc2885 Stefan Kristiansson: dcache: avoid read on write to same address... | 15:58 |
| mor1kx | mor1kx/master d88fa67 Stefan Kristiansson: icache: avoid read on write to same address... | 15:58 |
| stekern | that shaved off another ~100 LC, now down to 5053 | 15:59 |
| stekern | with 1-way cache, it's 4724, which means cappuccino is again smaller than or1200 in the same configuration | 16:00 |
| stekern | (or1200 is 4747 according to an old fit report) | 16:00 |
| @juliusb | very nice | 16:33 |
| stekern | ctrl is the module standing out as the largest, followed by the alu | 16:52 |
| stekern | then the fetcher is retty bloated | 16:52 |
| stekern | i should probably look at that next | 16:53 |
| -!- Netsplit *.net <-> *.split quits: simoncook, jeremybennett_ | 22:17 | |
| -!- Netsplit over, joins: jeremybennett_, simoncook | 22:18 | |
| -!- Netsplit *.net <-> *.split quits: jeremybennett_, simoncook | 23:12 | |
| -!- Netsplit over, joins: jeremybennett_, simoncook | 23:12 | |
| --- Log closed Tue Apr 23 00:00:27 2013 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!