| juliusb | olofk: (DV Club on Jan 14) I'd like to go but I'll still be down under so will probably attend remotely | 14:48 |
|---|---|---|
| jeremybennett | juliusb: olofk Happy Christmas | 14:50 |
| juliusb | jeremybennett: thanks, you too | 14:50 |
| juliusb | my christmas is warm and sunny again this year ;) | 14:50 |
| juliusb | i've maintained my southern migratory habit | 14:51 |
| * stekern is jealous | 14:54 | |
| stekern | complete crap weather both in sweden and finland | 14:55 |
| juliusb | so I've heard | 14:55 |
| stekern | ~0 degrees and snow everywhere | 14:55 |
| stekern | it's the worst, I much rather have -10 than 0 | 14:56 |
| jeremybennett | wet and windy here | 14:56 |
| juliusb | ah well, this may explain all of your fantastic progress with all things OpenRISC, and the opposite for me :) | 14:56 |
| stekern | heh, I've been busy stuffing myself with good food to comfort myself, so haven't got much done | 14:57 |
| juliusb | :) | 14:57 |
| stekern | spent the christmas in sweden, so we've got the garden full of wet and heavy snow... will be a lot of fun to shuffle that away when I get home from work | 14:58 |
| stekern | good excercise after all the eating though ;) | 14:59 |
| juliusb | I bet | 14:59 |
| stekern | on another note, juliusb, I'm getting more and more convinced we should set SR[DSX] when hitting exceptions after a b[n]f, even if the jump isn't taken | 15:00 |
| juliusb | why is that? | 15:01 |
| stekern | that's at least what it looks like the "emulation" of it in linux is doing | 15:01 |
| juliusb | I haven't thought any more about it | 15:01 |
| juliusb | does the kernel figure it out somehow? | 15:02 |
| stekern | http://git.openrisc.net/cgit.cgi/linux/tree/arch/openrisc/kernel/entry.S#n217 | 15:02 |
| stekern | haven't really thought much more myself, just noticed that when I did some light reading up on MMUs during christmas | 15:03 |
| juliusb | wow it does this on all data page fault exceptions?! | 15:03 |
| stekern | obviously | 15:05 |
| stekern | but isn't the tlb miss handlers that are the really hot ones? | 15:05 |
| juliusb | ya | 15:05 |
| juliusb | i think so | 15:06 |
| stekern | I must confess that I have/had little to no understanding of how the or1k mmus (or mmus in general) worked, I'm getting there though... | 15:06 |
| juliusb | oh, it's easy ;) | 15:06 |
| stekern | yeah, it doesn't seem to difficult to actually implement them | 15:07 |
| stekern | I'd like to have hardware walkers in the implementation I'm thinking of doing though | 15:08 |
| stekern | (optional obviously) | 15:08 |
| juliusb | cool :) | 15:08 |
| juliusb | that kernel code for DSX-bit-enabled won't work by the way | 15:13 |
| juliusb | it bitwise ANDs the DSX bit of the SR (0x2000) but then checks it against 0x1 | 15:13 |
| juliusb | should be l.sfeqi r6, SPR_SR_DSX | 15:14 |
| juliusb | anyway.... | 15:14 |
| stekern | I bet it hasn't ever been tested ;) | 15:14 |
| juliusb | if you reckon we should set DSX for exceptions caused by the delay slot, whether the branch was taken or not, then put it up on the architecture spec page for an ammendment we can make | 15:15 |
| juliusb | that makes it easier | 15:15 |
| juliusb | probably | 15:15 |
| stekern | but for the other config option to work, we have to set EPCR to the jump | 15:16 |
| juliusb | huh? | 15:16 |
| juliusb | EPCR is always set to the jump, right? | 15:16 |
| juliusb | you're saying if we're in the delay slot (taken or not) we should always set the EPCR to the branch/jump instruction? | 15:16 |
| stekern | yes, is it already like that? | 15:17 |
| juliusb | yeah, this is a good question actually, i'm not certain of the behaviour of all the models in that case | 15:17 |
| juliusb | ie what is EPCR when exception is after l.bf if flag is 0 | 15:18 |
| stekern | exactly, iirc, that was the discussion we had earlier, but I might remember wrong | 15:19 |
| juliusb | sure but then it's another question what DSX is | 15:19 |
| juliusb | because, I argue delay-slot is the instruction after a taken-branch | 15:19 |
| juliusb | otherwise the next instruction is just the next instruction | 15:20 |
| juliusb | im off for the evening - might be worth mentioning that this should be cleared up in the architeture spec | 15:21 |
| juliusb | on the wiki page that is | 15:21 |
| stekern | hmm, yeah, but if we look at the DSX-enabled code (pretending the bug isn't there) how would that work if DSX isn't set and EPCR is set to b[n]f? | 15:22 |
| juliusb | so something talking about adding a section which defines this behaviour, ie the value of EPCR and DSX when exception is the instruction subsequent to a conditional branch which wasn't taken | 15:22 |
| stekern | yeah, I agree, this has to be clearified in the spec | 15:23 |
| juliusb | sure, it probably wouldn't work if EPCR is set to the instruction before the exception-causing instruction | 15:24 |
| juliusb | ie it should be as simple as, if DSX is set, you do EPCR+4 for your guilty instruction | 15:24 |
| stekern | mmm | 15:26 |
| juliusb | so you either only set DSX on taken-branches and EPCR is the branching instruction, and every other case (including instructions after non-taken-branches) EPCR points to that instruction and DSX is never set | 15:26 |
| stekern | yes, but that will break the no-dsx code (which of course can be argued as wrong) | 15:27 |
| juliusb | ... or for any jump instruction, conditionally taken or not, an exception in the following instruction (on implementations with delay-slot) then the EPCR always points to the branching instruction and DSX is set always | 15:28 |
| juliusb | yes, so if the assumption is that you always treat instructions after conditional jumps as delay slot whether it was a taken branch or not, then I guess we stick to that | 15:28 |
| juliusb | yeah, stickto the current behaviour | 15:29 |
| juliusb | no point changing it | 15:29 |
| juliusb | so then we just put that into the arch spec | 15:29 |
| juliusb | and do a test for it | 15:29 |
| stekern | I agree | 15:29 |
| juliusb | :) | 15:29 |
| stekern | ;) | 15:30 |
| juliusb | ... and I go off to bed | 15:30 |
| stekern | exception free dreams | 15:32 |
| blueCmd | major parts of eglibc "compiles" now, but I'm debugging a linking error which is a bit nasty | 22:58 |
| blueCmd | what I'm seeing is: multiple definition of `__libc_multiple_libcs' | 23:00 |
| blueCmd | I'm looking and comparing the linking inputs and there are two __libc_multiple_libcs, but the situation is the same on x86_64 and that works | 23:00 |
| blueCmd | nm on the or1k files shows the same symbols as the reference x86_64 I compiled | 23:01 |
| blueCmd | I'm starting to think it might be an or1k gcc bug (compiling eglibc x86_64 with the same gcc but compiled for x86_64) | 23:02 |
| blueCmd | but all my experience keeps telling me that it's never the compiler :P | 23:02 |
| blueCmd | my problem: http://pastie.org/5585813 | 23:08 |
| olofk | How do I run or1200 against a good selection of test cases? | 23:42 |
| olofk | I remember that juliusb said that mor1kx could be run against the gcc torture tests with some script. I'd like to do something like that with the or1ksim test cases and all (relevant) gcc/toolchain tests | 23:44 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!