IRC logs for #openrisc Thursday, 2014-01-30

--- Log opened Thu Jan 30 00:00:16 2014
blueCmdams: sorry, they didn't have anything :(02:17
jonibostekern: yes... it's like this... i've rewritten the syscall handling for Linux to be more efficient, and as a result its possible to follow the regular function call ABI for all syscalls... this means that the arg registers (r3-r8) are clobbered by the call06:45
jonibo...but the sad thing is that it still doesn't work... things only work if r3-r8 are restored upon return to userspace06:45
joniboanyway, like I mentioned before, it may also be that we are missing the "memory" clobber on the syscall06:45
joniboI haven't been able to nail down exactly what is happening06:46
stekernjonibo: ok, thanks for the explanation.06:48
jonibosure, hope it helps somehow... i'll try to push the syscall rewrite to somewhere public and let you know so you can see it for yourself06:49
stekernI thought I was seeing something similar yesterday on the eco32 port I'm working on, but it had a much more natural explanation. I had forgot to add the incoming registers to the outgoing list in the inline asm that does the syscall instruction.06:50
joniboaha... yeah, that bit is a bit tricky on GCC since you can't have the same regs in both lists (params and clobbers)06:51
stekernyeah, I don't get why that restriction exists, but there is probably a good technical explanation.06:52
stekernit would feel a lot more natural to mark them as clobbered than as set registers06:54
stekernbut if it's in fact the call-site that clobbers r3-r8 in your case, it should be "easy" to find it. especially if you know which syscall cause it.06:57
olofk_blueCmd: The first commit by pgavin in the or1k-src is really a copy of the changes that juliusb did in his or1k-binutils repo. juliusb has probably taken some of that stuff from OpenCores SVN, which is why the ChangeLog entries doesn't show the full story07:16
olofk_Luckily, the history is all fine after pgavin's initial commit, so the tricky part is just to identify where all the changes in that commit come from07:19
jonibostekern: I think you _do_ want to mark them as clobbered... it allows the optimizer to work better than if it needs to treat the contents of those regs as important on return07:24
jonibothere's some macro trickery done in most other arches to do just this07:25
stekernjonibo: but you can't mark them as clobbered, (as you said earlier) since they are in the incoming parm list07:31
jonibostekern: no, that's the trick... see the macros that are set up in uClibc where the param regs are adds to the input list and teh unused param regs are added to the clobbered list08:16
jonibothe thing that, I think, is missing is the "memory" clobber... other arches seem to need that so I'm sure we do to08:16
stekernjonibo: yes, I know about the macro trickery, I'm using that in the eco32 too:
joniboyeah, looks good... then I don't understand why you need the input regs in the ouput reg list, too...???08:23
stekernbut I think we are just saying the same thing, I was just commenting on that it feels odd that you can't add incoming registers to the clobber list, but have to add them to the outgoing list to achieve that08:23
joniboah, no... input regs are always clobbered...08:24
stekernat least gcc disagrees with that statement, it happily used r5 (and incoming reg) after the trap instruction.08:25
stekernand from what I read yesterday from the gcc inline asm documentation, that's expected behaviour08:26
jonibointeresting... i may have misunderstood that... I don't think openrisc uClibc does this properly then08:26
stekerns/and incoming reg/and incoming reg08:26
joniboand that could explain the "bug" I described earlier08:26
stekernit does, the incoming regs are in the out list08:27
joniboi'll peek at the docs now08:27
joniboon openrisc08:27
joniboreally... ok08:27
jonibohmm... ok, well at least its correct then... I guess it's just my head that's confused :)08:27
stekernas I said, it's IMO counter-inuitive ;)08:28
jonibocorrect you are: "There is no way for you to specify that an input operand is modified without also specifying it as an output operand."08:30
joniboand I agree, it's not very intuitive08:30
amsblueCmd: thanks!08:56
-!- jts_ is now known as jtdesousa11:32
blueCmdjonibo: I think I have memory clobber set on the syscalls in glibc13:17
joniboblueCmd: good...13:33
joniboi'll let you know if I push the patches and you can see if thigns work there13:33
jonibowon't be before next week, though, as I won't have time to look into anything before then13:33
blueCmdthat is how it's done in glibc currently13:40
blueCmdjonibo: cool, i'll be happy to test it13:40
blueCmdthe this code is used to generate the ASM_ things:
blueCmdthen this*13:42
jonibolooks good14:02
maxpalnOk, making good progress - but coming unstuck on understanding how the cache between the Wishbone and DDR2 module is used.14:06
maxpalnFor example, the simulation starts by pulling data from the SPI Flash and loading it into memory14:06
maxpalnwhen the first byte arrives from the SPI Flash the cache controller decides to read from the DDR2 memory and as far as I can see it doesn't write the byte (from SPI Flash) into the cache for writeback!14:07
maxpalnNot being familiar with how cache's work I am diving into this to try and get a better understanding -14:07
maxpalnbut wondered if anyone has any experience of this part of the design - maybe give me a top level view of how the mechanism should work14:08
stekernblueCmd: that's exactly how it's done in uclibc as well14:09
stekernminus the memory clobber14:09
stekernmaxpaln: are you speaking about the CPU cache or some other cache?14:10
maxpalnNot the CPU cache - the cache that is part of the DDR2 wishbone interface14:11
maxpalnthere is a 4Kbyte cache that sits between the wishbone and the ddr2 controller.14:11
stekernif you are speaking about the cache that I put in the SVN version of the atlys board, you probably will be better of doing something like I did here instead:
maxpalnok, that's interesting - a different implementation14:14
maxpalnThe version I am currently looking at is here:
stekernyes, I first did the cache one for atlys, which was inspired by an implementation done by juliusb. But when I hooked up a framebuffer to that, there was this issue with the cache constantly being invalidated, which made the performance unacceptable.14:16
maxpalnah, ok14:16
maxpalnso you think the version you just pointed out is the way to go?14:16
stekernand, I think the non-cache version is slightly simpler, but the xilinx interfaces makes it look complicated14:16
stekern(+ it could probably be improved, it was one of the first things I ever wrote in verilog)14:18
maxpalnI'm just looking at it now - see if I can see a sensible way to map it to our memory controller (which happens to be very similar to the version used in Julius' implementation (and as such the Atyls board version))14:19
stekernI think the main reason for juliusb to doing the whole cache thing was that he had to map 128-bit of DDR2 data on the virtex5 board he had onto the 32-bit bus14:19
stekernand then he just copied that for the s3adsp board14:20
maxpalnhmmm, yep - I have a similar situation with our board14:20
maxpalnthe DDR3 data is 64-bit but could easily be 128-bit if a wider memory interface is used14:20
blueCmdstekern: yes I used a lot of code from uclibc for certain parts, so that might be the case14:20
stekernbut, you should be able to adapt that to my "improved" version too14:21
blueCmdstekern: the memory clobber part I think I reasoned that syscalls can take a pointer and modify the value it points to, so clearly it clobbers the memory as well14:21
maxpalnI'm taking a look now - seeing if I can see a neat way to do it without changing the code too much!14:21
stekernblueCmd: yes, and from what I understand, the memory clobber prevents gcc from moving the instruction around too, which I guess is something we want14:22
stekernanyway, last minute of work before 1 month of vacation, bbl ;)14:22
maxpalnaw, and I was hoping to pick your brains as I work through this! grrr :-)14:25
maxpalnoff anywhere particularly jealousy inducing?14:26
jonibostekern: enjoy your vacation!14:27
amsi hate france ...14:35
omocwhats the status of the llvm openrisc port?14:38
joniboI think you just missed LLVM-stekern... he'll be back in a month :)14:39
omocI just found some github repos but those have not been touched in quite a while14:39
joniboI think it all worked...14:39
jonibohaven't tried it myself, though14:39
omochmm okay, I guess I just have to try myself then14:40
joniboi think you'll find it works14:40
blueCmdomoc: what do you need?14:40
omocjust curious, we may want to use it in a university project and if you touch the backend, gcc is not very pleasent to work with :)14:42
blueCmdwell, then missing feature suddently is a good thing! :)14:44
blueCmdomoc: it apparently supports dynamic linking acording to a forum post by stekern, so there's that14:47
simoncookomoc: the status of the llvm port is I haven't pulled in the latest upstream changes for the last 4 months or so but it was up to date as of then14:48
omocnice, thanks14:49
omocchanges of the past 4 month? the github repo I found shows the last change was a year ago14:50
simoncooktry I seemingly haven't been pushing my changes to the openrisc/ repository that often14:52
stekernmaxpaln: Thailand, but don't worry I'll be around ;)14:56
maxpalnstekern: definitely jealous! As I drown in the wettest January on record in the UK......14:56
stekernsimoncook: don't be afraid of pushing them there ;)15:05
simoncooki will do, ill try and merge in the last 4 months of changes first and then push a nice up to date llvm/clang15:08
_franck_web_ams: what's up with france ?15:19
blueCmdjonibo: did you receive my patches btw?15:34
joniboreally superficially... haven't had any real time to do openrisc stuff for a while15:34
jonibothey looked good, though15:34
joniboi intend to throw them onto master next week15:34
jonibosorry, read "review" where you wrote "receive" :)15:35
stekernomoc: to elaborate on what simoncook said, the port as I left it a year ago was pretty much complete, I could compile a working linux, uclibc and busybox with it15:35
joniboyes, I received them... even looked at them... superficially :)15:35
joniboLinux doesn't build with llvm :p15:36
stekernopenrisc linux does ;)15:36
blueCmdjonibo: great! I just wanted to know if I sent them to the correct place. couldn't find them by googling, which I usually can15:37
stekernwe're superior than the others15:37
joniboblueCmd: yeah, sorry, my fault for not being responsive15:37
ams_franck_web_: people don't have places for me to stay at ... :-)15:37
jonibostekern: I knew that already ;)15:37
blueCmdjonibo: np :)15:37
blueCmdstekern: does it have TLS and DWARF2 support!?15:38
blueCmdthat is the single most important question15:38
stekernblueCmd: no, that's actually missing15:39
blueCmdpff, how can you even call it a compiler then?15:40
blueCmdbasically useless...15:40
stekernbut we didn't have tls support when I worked on it ;)15:40
amsanyone used airbnb here?15:41
blueCmdyeah I have actually been meaning to implement it in LLVM, but it's quite far down on my list15:41
stekernI thought it'd be your responsibility to add the support across the tools, so patches welcome =)15:41
stekernheh, it's too slow writing on this phone, you beat me15:42
jonibowho's going to fosdem this weekend?15:42
stekernI would have if it didn't clash with my thailand trip15:43
amsjonibo: some gnu hackers are going .15:43
joniboi meant from this group, of course :p15:44
joniboi kind of figured I'd run into a GNU hacker or two down there15:44
joniboi'll be around in any case... i'll be wearing my "South Pole" attire, if somebody feels like saying "hi"15:44
jonibothere'll be a couple of others from South Pole, but I'm easy to recognize... the stunning good looks and all15:45
blueCmdthat's a south pole attire15:45
joniboblueCmd: something along those lines, yeah :)15:45
amsjonibo: you at south pole? coolies...15:45
blueCmdyeah, south pool is pretty cool15:45
joniboblueCmd: it mostly scares me how quickly you dug up that photo...15:45
amsjonibo: know giuseppe scrivano?15:45
blueCmdjonibo: haha15:46
joniboams: yes I do... I employed him for a while15:46
blueCmdams: apparently -48C there now15:46
* blueCmd is hillarious15:46
amsjonibo: ah!15:46
amsblueCmd: some regions had -90 .. though i think that was north pole ..15:46
amsjonibo: you guys looking for people?15:46
joniboyes we are15:47
joniboalways on the lookout for the right people15:47
jonibogood experience with embedded Linux15:47
joniboor good sysadmins15:47
joniboor the mythical "good salesman who likes to get his hands dirty building servers"15:47
amsnifty ... will make a note in my notebook .. will be looking for work after august ..15:47
amsjonibo: you looking for contracters, or full time people? onsite, or off-site15:48
jonibofull time, mainly15:48
joniboonsite/offsite depends on the role we determine for the employee... it's a mixed bag, currently15:48
amsfair enough ...15:48
blueCmdjonibo: you have a sarskrivning on the "Rymdprotokol" section, - my eyes are bleeding15:48
amsjonibo: i'm planning on moving to uppsala/stockholm region after a small stint in paris .. currently in gothenburg ...15:49
joniboyeah, I think our web guy's not a grammar nazi15:49
joniboams: aha.. cool15:49
omoc00:27 here, happy new year ;)16:27
amsomoc: you are ... 30 days late ..16:33
omocnope, chinese new year16:35
omocwe are going from the year of the snake to the year of the horse16:35
olofkHappy new horse! ...or what is one supposed to say?18:34
olofkams: I've used airbnb a few times. Have been great18:41
blueCmdnever liked that snake anyway20:55
stekernThe year of the snake sounds so much cooler than the year of the horse22:54
stekernand apparently it's a wooden horse22:56
--- Log closed Fri Jan 31 00:00:18 2014

Generated by 2.15.2 by Marius Gedminas - find it at!