IRC logs for #openrisc Friday, 2013-05-10

--- Log opened Fri May 10 00:00:52 2013
stekernheh, my first attempt on adding branch prediction to cappuccino was a complete failure, it got even slower than stalling on the l.sfxx; l.b(n)f condition07:55
stekernI did a bit silly though, I just restarted fetching from the branch instruction, i.e. the delay slot instruction is refetched as well...07:56
stekernnext I'll try to just flush the branch dest instruction in fetch and refetch that, that should be close to the same as stalling on mispredictions07:57
-!- Netsplit *.net <-> *.split quits: zhai365_, mboehnert08:46
stekernthe naive "use the old flag" strategy seems to be as slow as just stalling13:23
stekernbackwards branches taken, forward not gives much better result15:39
stekernotoh, I fixed some bugs when I implemented did that, got to go back and check so nothing of that improved the result15:39
stekernboth are crappy stategies, but the cool thing is, getting the branch prediction "framework" in place, changing algorithm should be transparent to the controlling of the pipeline15:41
stekernthe bug fixes had made some difference, but the bakwards-branches not taken is still better15:51
stekernall this is just according to dhrystone and coremark though15:51
stekernI should implement a branch misprediction counter in mor1kx monitor, that way it'd be easy to evaluate branch prediction algorithms15:52
stekernhere I was looking for some example scripts for running mibench on embedded targets, and what do I find in embecosms git repos ;)19:27
stekernthanks jeremybennett19:27
stekerna couple of small adjustments and the benchmarks runs perfectly on my atlys board19:42
hnoJust learnt that Allwinner A31 apparently have a OpenRISC companion core. Not yet sure what functions it provides.20:04
stekernhno: really? where did you get this information?20:09
hnofrom an engineer with close relation to Allwinner, and by looking at a firmware blob which looks very much OpenRISC instructions but with big endian data.20:12
stekernok, cool20:13
stekernhumm, openrisc is be (or at least all implementations I know of)20:14
hnoSo maybe it is big endian. Not 100% sure. Text data is like "32107654BA98FEDC"20:16
stekernbasicmath_small: 0m 46.78s, basicmath_large: 10m 28.25s (wall clock)20:17
stekernno idea if that is good or bad, but at least the tests doesn't crash ;)20:17
hnolittle endian I meant.20:19
hnowhich is odd.20:21
stekernthey could just have the data lines swapped to the cpu (I think that should work)20:22
stekernwhich would make sense if they want to share data with a le processor20:22
stekerneither way, cool info20:25
stekernnot so cool is that my branch prediction code doesn't seem to be completely bug-free, linux crashes on bootup on the atlys board with that20:27
hnoThe A31 is a quad core Cortex-A7. So it's all odd to see the data little endian.20:29
hnostekern, ouch.20:32
hnostekern, Hm. This endiandness is confusing me. Seems to be a mixture of lttle and big endian data in the code blob. But I think you are right. Would not make sense to byte-swap strings like this otherwise.20:54
hnoright, figured out the endianness confusion. It was objdump that played games on me. Everything indicates it's and big-endian OpenRISC core as we know them but byte-swapped at the memory interface to match the ARM little-endian cores. Code seems compiled for big-endian and then the resulting binary image is byte-swapped.22:14
--- Log closed Sat May 11 00:00:53 2013

Generated by 2.15.2 by Marius Gedminas - find it at!