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

--- Log opened Thu Jan 23 00:00:06 2014
stekernblueCmd: one step closer to world domination =)03:18
-!- Netsplit *.net <-> *.split quits: vxe09:06
-!- Netsplit over, joins: vxe09:11
-!- Netsplit *.net <-> *.split quits: vxe09:13
olofk_ahh.. an interesting discussion related the the latest pull request for orpsoc-cores. That's fun!09:39
olofk_ehhmm.. how do I quote and reply on github comments?09:42
-!- Netsplit over, joins: vxe09:44
stekernreply to the e-mail09:49
stekernnice, my uclibc patch got accepted09:56
olofk_stekern: what uclibc patch? openrisc-related?10:45
_franck_web_olofk_: when you are in github GUI, select the part of the text you want to quote and press 'r'10:51
olofk__franck_web_: Yeah, I saw that. Very handy. I did that instead of answering the mail10:52
stekernolofk_: it's remotely openrisc related,
olofk_ah yes. I remember hearing about that11:05
stekernit's the last piece of a puzzle to remove an out-of-tree patch jonas have in his master tree to make our linux work with uclibc11:05
stekernor, alternatively remove a set of patches to generic code we've been carrying in uclibc11:08
olofk_that's nice11:11
olofk_How many C libraries does one need btw? We have newlib, glibc, uClibc now right? And linux provides a libc somehow too? And apparently one can use eCos in addition to that11:16
olofk_forgot that there's work on eglibc too11:17
stekernwe're still missing support for bionic11:19
olofk_haha. Yes, you're right, and that would actually be useful :)11:25
olofk_IIRC, jonibo took a look at that some time ago11:25
olofk_But really, when does one want to use uClibc? Trying to understand these things better11:29
olofk_or is that the libc that we use to run binaries under linux?11:29
olofk_So glibc is a prequisite for eglibc, which in turn does approximately the same stuff as uClibc?11:30
olofk_e.g. provides a libc for binaries under linux11:31
stekernyes, or more correctly the other way around, uClibc does approximately the same stuff as glibc11:31
olofk_but both uClibc and eglibc is meant as lightweight alternatives for glibc?11:32
olofk_Makes sense now11:32
stekernbut eglibc comes closer in portability11:32
stekernerr, compatibility I mean11:33
stekernwith glibc11:33
olofk_Do glibc, eglibc and uClibc only run under Linux, or do they have some sort of backends so they can run under other OSs or baremetal?11:33
olofk_Or perhaps they run against posix?11:34
stekernI think officially, they are Linux only (and perhaps Hurd for glibc)11:36
olofk_What does BSD use?11:37
stekernthe BSD libc, the one bionic is based on11:37
olofk_Saw in the wikipedia article about glibc that MicroBlaze only gained support in the latest revision11:42
olofk_hmm.. but newlib can actually use linux as a backend. Things are getting confusing again11:44
olofk_This madness has to end. I will now write a new libc implementation to replace all existing ones. It will run on the cloud11:48
LoneTechor we could all start writing all out software in Nimrod ;)11:50
olofk_LoneTech: I will start to rewrite the linux kernel to Nimrod then :)11:55
joniboeglibc is binary compatible with glibc, uclibc is API compatible... that's the fundamental differnece12:42
joniboolofk_: don't forget klibc12:44
joniboklibc would be the Linux libc, but Linux doesn't really provide a libc itself12:44
joniboeglibc is a fork of glibc, making it modular so you can make the binary a bit smaller if you don't use all the features... the big feature that's traditionally removed is localization as embedded systems don't need the massive load of language support features12:45
olofk_jonibo: I read the glibc wikipedia article. Understand a little more now and realizes that C libraries are a sensitive issue :)12:46
joniboyeah, it seems that people working on libc implementations are... special12:47
olofk_I remember jeremybennett saying something about someone working on a stripped-down newlib also, because that was apparently also too large12:47
jonibonewlib is for bare metal so it has to implement functions that the OS kernel would normally handle via syscalls12:47
joniboyou could do a newlib frontend to Linux, but what would be the point?12:48
joniboif you link to newlib statically you get "only what you use" so it can hardly be smaller than that12:48
joniboand I can probably qualify that further: you _do_ link to newlib statically12:49
jonibolibc's not really that big when you consider that the size is amortized over _every_ application that's running on the system (assuming it's dynamically linked)12:49
jonibobut glibc has historically been deemed too big for "embedded"... I think that's not really the case anymore as "embedded" has gotten bigger12:50
jonibothe long term goal,though, was for eglibc and glibc to merge and become one... I think that will happen within the next four years or so12:50
olofk_I think the thing about newlib was that malloc or printf was pulled in unconditionally12:50
jonibothe glibc maintainers are quite sane nowadays12:51
jonibomalloc and printf are implemented in GCC so the libc implementation is really trivial12:51
jonibo#define malloc __builtin_malloc12:51
jonibothat's it12:51
joniboyou'd be surprised how much stuff is actually implemented in GCC nowadays... make sense, since the compiler can then optimize much further, often down to essentially nothing12:52
olofk_But if you don't need them, I guess it makes sense not to pull in those functions at all. Talking about the deep-shit-embedded case12:53
jonibobut if you don't use them, they dont' get "pulled in"...12:53
olofk_via other functions perhaps?12:53
jonibo...that would be the case for any function from a statically linked lib12:53
joniboif the "other functions" don't use them, they don't get pulled in! :(12:53
joniboit's about as optimal as it can get12:54
joniboand like I said, they are GCC builtins anyway, so the really don't exist12:54
joniboanyway, this is one of the BIG pieces missing pieces of openrisc GCC... optimized versions of the builtin functions... strcpy, memcpy, et cetera, et cetera...12:54
jonibothey should be written as simple assmebly routines12:55
olofk_directly in GCC?12:55
jonibodirectly in gCC12:55
joniboyou should put that up on a TODO list on the openrisc wiki so newcomers looking for a project know where to start12:55
olofk_good idea12:55
jonibothere are some crappy versions in the Linux kernel... they need to be optimmized there too... but it should be exactly the same code copied between GCC and Linux12:56
jonibo(I wonder why Linux can't use the builtins... need to look into that)12:56
olofk_Every year I'm thinking about submitting stuff like this to GSoC, but I guess it would need a backing company/foundation as well as a few mentors too12:57
olofk_Yeah, I just wondered that. Do we really need the same code in GCC and Linux?12:57
joniboLinux is built standalone and freestanding, i.e. without a libc and without libgcc, so it needs to implement a lot of the libc/GCC stuff itself12:59
jonibokind of like newlib13:00
joniboas newlib is pretty much an OS in itself13:00
olofk_Yeah. That's true13:00
stekernjonibo: (crappy versions in the kernel) are you speaking about __copy_to_from_user and friends?14:15
stekernwhich have .section __ex_table14:16
stekern(which I have to admit I don't really understand how it works) but could it be related to that, that the builtins can't be used?14:19
stekernah, this explains it well:
stekernor did you just mean that we are using generic versions of memcpy et al?14:36
olofk_explains it well? :)14:36
olofk_I have seen xml files that are more readable than that article :)14:37
stekernwell, I have read the code, so I had some pre-context perhaps ;)14:37
olofk_That might help14:38
olofk_another thing... how does compiling for eCos work? If I have understood things correctly it uses it's own C library, so which toolchain is used for that?14:39
olofk_A third thing. Regarding maybe we should just remove that define and always use Wishbone B3. What would be the arguments against that?14:58
LoneTechiirc it should be fully compatible anyway, so I think your suggestion is sound. relatedly I think we should fix a formal table somewhere of namings for the common wishbone setups, as I don't think what B3 really means is defined15:02
blueCmdstekern: my irc box was being mean so I missed the praise that you probably gave me for my awesome work15:05
_franck_web_blueCmd: if you want to see all stekern says about you when you're not here:
olofk_LoneTech: I agree. The wishbone versioning is a bit messy.15:09
olofk_I'm considering writing an article about how the different components work together in the or1k ecosystem. Does this look correct as a simple overview or am I missing something fundamental?
blueCmd_franck_web_: thanks!15:18
blueCmdstekern: So I can actually use debootstrap to bootstrap myself an initramfs with busybox now. I still need to fix perl, but that should be the last thing until I have a basic debian installed15:24
olofk_blueCmd: You're going to fix perl? Well, good luck with that. I thought it was beyond saving ;)15:25
olofk_Also, famous last words :)15:25
blueCmdolofk_: ... yeah, so I have the guy who ported it to aarch64 to help me15:33
blueCmdmy current plan of attack is to get qemu-user running and compiling it through that15:33
_franck_web_olofk_: don't you think you should put "linux" under "Elf File" ?15:34
_franck_web_and split "ELF File"15:35
olofk_blueCmd: Yeah, the qemu approach is interesting. I should probably add that to my picture when I figure out where to plug it in15:36
olofk__franck_web_: Yeah, I thought about that too. It should really be elf->linux->elf somehow15:36
olofk_What I really want to show beneath the "ELF file" row is that that's where the or1k software part ends15:37
olofk_Maybe I should rename it to or1k executable, or OpenRISC machine code15:38
jonibostekern: I meant that the functions memcpy, strchr, memset, et al are either not optmized or poorly optimized... memcpy has an assembly version, but it's really quite poor (and I think GCC has the same poor version)15:39
olofk_Got to run15:41
jonibofor many of these "memory" functions we use the C versions which don't turn out particularly efficient15:41
joniboreally these functions should take word size, data alignment, cache size, etc into account and perform accordingly15:42
joniboI'm not saying they need to be written in assembly, they could possibly be done in C... but a bit more thought needs to be put into them15:45
jonibomemcpy currently just copies byte-by-byte15:45
joniboit should copy up to word alignment and do word copies from there as far as possible15:46
jonibofor example15:46
joniboin any case, these "optimal" versions are what the GCC builtins should map to, as well, and thus the code needs to be there, as well... so fixing GCC and Linux at the same time would certainly be most time efficient15:47
joniboconsidering how much these libc functions are used, the potential gains are huge15:48
stekernjonibo: I agree, but where is the assembly version in linux, I haven't seen that16:38
-!- Netsplit *.net <-> *.split quits: olofk_20:31
--- Log closed Fri Jan 24 00:00:07 2014

Generated by 2.15.2 by Marius Gedminas - find it at!