IRC logs for #openrisc Thursday, 2012-12-27

juliusbolofk: (DV Club on Jan 14) I'd like to go but I'll still be down under so will probably attend remotely14:48
jeremybennettjuliusb: olofk Happy Christmas14:50
juliusbjeremybennett: thanks, you too14:50
juliusbmy christmas is warm and sunny again this year ;)14:50
juliusbi've maintained my southern migratory habit14:51
* stekern is jealous14:54
stekerncomplete crap weather both in sweden and finland14:55
juliusbso I've heard14:55
stekern~0 degrees and snow everywhere14:55
stekernit's the worst, I much rather have -10 than 014:56
jeremybennettwet and windy here14:56
juliusbah well, this may explain all of your fantastic progress with all things OpenRISC, and the opposite for me :)14:56
stekernheh, I've been busy stuffing myself with good food to comfort myself, so haven't got much done14:57
stekernspent 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 work14:58
stekerngood excercise after all the eating though ;)14:59
juliusbI bet14:59
stekernon 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 taken15:00
juliusbwhy is that?15:01
stekernthat's at least what it looks like the "emulation" of it in linux is doing15:01
juliusbI haven't thought any more about it15:01
juliusbdoes the kernel figure it out somehow?15:02
stekernhaven't really thought much more myself, just noticed that when I did some light reading up on MMUs during christmas15:03
juliusbwow it does this on all data page fault exceptions?!15:03
stekernbut isn't the tlb miss handlers that are the really hot ones?15:05
juliusbi think so15:06
stekernI 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
juliusboh, it's easy ;)15:06
stekernyeah, it doesn't seem to difficult to actually implement them15:07
stekernI'd like to have hardware walkers in the implementation I'm thinking of doing though15:08
stekern(optional obviously)15:08
juliusbcool :)15:08
juliusbthat kernel code for DSX-bit-enabled won't work by the way15:13
juliusbit bitwise ANDs the DSX bit of the SR (0x2000) but then checks it against 0x115:13
juliusbshould be l.sfeqi r6, SPR_SR_DSX15:14
stekernI bet it hasn't ever been tested ;)15:14
juliusbif 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 make15:15
juliusbthat makes it easier15:15
stekernbut for the other config option to work, we have to set EPCR to the jump15:16
juliusbEPCR is always set to the jump, right?15:16
juliusbyou'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
stekernyes, is it already like that?15:17
juliusbyeah, this is a good question actually, i'm not certain of the behaviour of all the models in that case15:17
juliusbie what is EPCR when exception is after if flag is 015:18
stekernexactly, iirc, that was the discussion we had earlier, but I might remember wrong15:19
juliusbsure but then it's another question what DSX is15:19
juliusbbecause, I argue delay-slot is the instruction after a taken-branch15:19
juliusbotherwise the next instruction is just the next instruction15:20
juliusbim off for the evening - might be worth mentioning that this should be cleared up in the architeture spec15:21
juliusbon the wiki page that is15:21
stekernhmm, 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
juliusbso 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 taken15:22
stekernyeah, I agree, this has to be clearified in the spec15:23
juliusbsure, it probably wouldn't work if EPCR is set to the instruction before the exception-causing instruction15:24
juliusbie it should be as simple as, if DSX is set, you do EPCR+4 for your guilty instruction15:24
juliusbso 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 set15:26
stekernyes, 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 always15:28
juliusbyes, 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 that15:28
juliusbyeah, stickto the current behaviour15:29
juliusbno point changing it15:29
juliusbso then we just put that into the arch spec15:29
juliusband do a test for it15:29
stekernI agree15:29
juliusb... and I go off to bed15:30
stekernexception free dreams15:32
blueCmdmajor parts of eglibc "compiles" now, but I'm debugging a linking error which is a bit nasty22:58
blueCmdwhat I'm seeing is: multiple definition of `__libc_multiple_libcs'23:00
blueCmdI'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 works23:00
blueCmdnm on the or1k files shows the same symbols as the reference x86_64 I compiled23:01
blueCmdI'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
blueCmdbut all my experience keeps telling me that it's never the compiler :P23:02
blueCmdmy problem:
olofkHow do I run or1200 against a good selection of test cases?23:42
olofkI 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 tests23:44

Generated by 2.15.2 by Marius Gedminas - find it at!