| --- Log opened Fri May 10 00:00:52 2013 | ||
| stekern | heh, 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 condition | 07:55 |
|---|---|---|
| stekern | I 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 |
| stekern | next 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 mispredictions | 07:57 |
| -!- Netsplit *.net <-> *.split quits: zhai365_, mboehnert | 08:46 | |
| stekern | the naive "use the old flag" strategy seems to be as slow as just stalling | 13:23 |
| stekern | backwards branches taken, forward not gives much better result | 15:39 |
| stekern | otoh, I fixed some bugs when I implemented did that, got to go back and check so nothing of that improved the result | 15:39 |
| stekern | both 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 pipeline | 15:41 |
| stekern | the bug fixes had made some difference, but the bakwards-branches not taken is still better | 15:51 |
| stekern | all this is just according to dhrystone and coremark though | 15:51 |
| stekern | I should implement a branch misprediction counter in mor1kx monitor, that way it'd be easy to evaluate branch prediction algorithms | 15:52 |
| stekern | here I was looking for some example scripts for running mibench on embedded targets, and what do I find in embecosms git repos ;) | 19:27 |
| stekern | thanks jeremybennett | 19:27 |
| stekern | a couple of small adjustments and the benchmarks runs perfectly on my atlys board | 19:42 |
| hno | Just learnt that Allwinner A31 apparently have a OpenRISC companion core. Not yet sure what functions it provides. | 20:04 |
| stekern | hno: really? where did you get this information? | 20:09 |
| hno | from 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 |
| stekern | ok, cool | 20:13 |
| stekern | humm, openrisc is be (or at least all implementations I know of) | 20:14 |
| hno | So maybe it is big endian. Not 100% sure. Text data is like "32107654BA98FEDC" | 20:16 |
| stekern | basicmath_small: 0m 46.78s, basicmath_large: 10m 28.25s (wall clock) | 20:17 |
| stekern | no idea if that is good or bad, but at least the tests doesn't crash ;) | 20:17 |
| hno | little endian I meant. | 20:19 |
| hno | which is odd. | 20:21 |
| stekern | they could just have the data lines swapped to the cpu (I think that should work) | 20:22 |
| stekern | which would make sense if they want to share data with a le processor | 20:22 |
| stekern | either way, cool info | 20:25 |
| stekern | not 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 that | 20:27 |
| hno | The A31 is a quad core Cortex-A7. So it's all odd to see the data little endian. | 20:29 |
| hno | stekern, ouch. | 20:32 |
| hno | stekern, 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 |
| hno | right, 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 irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!