IRC logs for #openrisc Tuesday, 2012-03-06

jonibo_derRichard: or1k has no (complex) "atomic" operations... this is the biggest missing feature, in my opinion08:18
jonibo_entry.S has an "atomic_swap" syscall that can be used to get just enough atomicity to make things useful, though08:18
jonibo_stekern: I find l.andi much clearer than l.movhi... the fact that l.movhi also clears the low 16 bits is not obvious at first glance08:22
stekernjonibo_: I agree with l.andi, I've used it over l.movhi too, but others seems to have created a de facto "standard" with l.movhi :)08:26
derRichardjonibo_: hm, ok. something like cmpxchg would be really nice to have a fast futex implementation.10:50
joniboyes, it sure would...10:52
derRichardjonibo_: btw: you asked why clearing r0 in _switch. we have to clear r0 also when swichting tasks. if the kernel switches from taskA to taskB we have to make sure that r0 is clean. is _switch the wrong place?11:06
jonibohow could r0 be "incorrect" at that point?11:06
derRichardif taskA changes r0 to 1 and a task switch happens11:08
jonibor0 isn't stored for taskA11:08
jonibor0 can only be corrupted in userspace before kernel entry... it should be fixed up on kernel entry only, not elsewhere11:09
derRichardso, r0 is cleared on each task swtich?11:09
joniboyou don't get a task switch without an exception11:09
derRichardah ok. then it's fine11:09
joniboI might have missed something, so let me know if you disagree11:09
jonibobut I think i'm right :)11:10
derRichardyou know _much_ more about openrisc than me. so i'll trust you11:11
-!- Netsplit *.net <-> *.split quits: olofk14:20
-!- Netsplit over, joins: olofk14:23
jessica1Hello. Is there any answer on this,OpenRISC,0,4661 question?20:27
jeremybennettI thought it was solved. The end of the last comment is "build successful, thank you!"20:30
derRichardis there a working openrisc target for qemu?20:36
jeremybennettderRichard: Not that I know of. There is no pressing requirement for one. It would be an interesting exercise, but it isn't blocking progress elsewhere.20:37
jeremybennettIf we were starting today, we would probably use QEMU rather than Or1ksim, with CGEN for tool chain development.20:37
juliusbi tend to agree on that actually - I was interested in a QEMU port a while back, but really, it's nothing we need urgently20:39
juliusbthe tool chain would be better helped by the sort of work Pete Gavin is doing20:39
juliusbor1ksim is pretty good20:40
juliusbalthough the benefit of qemu for OpenRISC Linux userspace development would be pretty big20:40
juliusbthat'd make the Linux userspace C library a whole lot easier to test20:41
jeremybennettI'm not sure that is true. The problem with testing the C library was that (at the time), Linux was not stable enough, so we had to build an infrastructure with a huge amount of redundancy and restart.20:46
jeremybennettIt would reduce the compute time though.20:46
juliusbwell if you're testing the kernel port too, sure you need to test in the full simulator20:50
juliusbbut I would argue you'd cut a lot of time and effort by running in that emulated user mode20:51
derRichardbinutils as of today does not build :(20:51
derRichardis this a known problem?20:51
jeremybennettderRichard: New one on me20:51
jeremybennettjuliusb: I'm not convinced by tool chain verification against high level simulators. I worry that you have abstracted so far, you miss some subtleties.20:52
jeremybennettBut if we were starting again, we'd go that way for sure.20:52
juliusbderRichard: yeah I've not seen that either20:53
derRichardmy buildenv is rather new. gcc 4.6.220:53
jeremybennettderRichard: It is flex blowing up - do you have all the prerequisites for the tool chain build?20:53
jeremybennettWell, GCC does get ever stricter about headers, so it is possible 4.6.2 has broken something.20:54
jeremybennettIdeally file a bug and a fix! It is quite likely it is an upstream issue, and there will be a patch shortly.20:54
derRichardbah, flex was not installed20:55
derRichardlet's see20:55
derRichardjeremybennett: hmm, flex and bison are installed but i get still this error21:03
jeremybennettI don't know what the problem is. In my build, it appears in the include directories of the target.21:07
jeremybennettBut this is the host compiler that is complaining.21:07
jeremybennettDo you have sysinfo.h on your host compiler's libraries?21:08
derRichardsysinfo.h is a local include21:08
jeremybennettSorry - I don't understand. sysinfo.h is a system header. On my Ubuntu laptop it is in /usr/include/i386-linux-gnu/sys/sysinfo.h21:09
jeremybennettHas it gone from 4.6.2?21:10
derRichardjeremybennett: sysflex.c does #include "sysinfo.h"21:15
derRichard" " vs. < >21:15
derRichardand yes, i have sys/sysinfo.h21:16
derRichardit comes from glibc-devel21:16
derRichard 21:28
derRichardsolved it. a -I../../binutils was missing21:35
derRicharddonno whether this is an upstream bug or not21:36
jeremybennettderRichard: Thanks for find that. Would you file a bug?22:06
derRichardjeremybennett: sure. where?22:08
jeremybennettJulius Baxter and I both track all submissions. If you have a patch, we can roll it in quite quickly.22:10
derRichardi took the code from git://
derRicharddoes this matter?22:14
jeremybennettJonas maintains his own git repository. I don't know how up to date it is. The official repository is the OpenCores SVN, that is where all the latest patches have been rolled in.22:16
jeremybennettYou might like to just checkout a copy and see if you still have the same problem.22:16
jeremybennettOne of the strengths of open source - anyone can run their own fork if they wish to.22:17

Generated by 2.15.2 by Marius Gedminas - find it at!