| --- Log opened Thu Jan 23 00:00:06 2014 | ||
| stekern | blueCmd: one step closer to world domination =) | 03:18 |
|---|---|---|
| -!- Netsplit *.net <-> *.split quits: vxe | 09:06 | |
| -!- Netsplit over, joins: vxe | 09:11 | |
| -!- Netsplit *.net <-> *.split quits: vxe | 09: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: vxe | 09:44 | |
| stekern | reply to the e-mail | 09:49 |
| stekern | nice, my uclibc patch got accepted | 09: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 mail | 10:52 |
| stekern | olofk_: it's remotely openrisc related, http://lists.uclibc.org/pipermail/uclibc/2014-January/048184.html | 10:58 |
| olofk_ | ah yes. I remember hearing about that | 11:05 |
| stekern | it'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 uclibc | 11:05 |
| stekern | or, alternatively remove a set of patches to generic code we've been carrying in uclibc | 11:08 |
| olofk_ | that's nice | 11: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 that | 11:16 |
| olofk_ | forgot that there's work on eglibc too | 11:17 |
| stekern | we're still missing support for bionic | 11: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 ago | 11:25 |
| olofk_ | But really, when does one want to use uClibc? Trying to understand these things better | 11:29 |
| olofk_ | or is that the libc that we use to run binaries under linux? | 11:29 |
| stekern | yes | 11:30 |
| olofk_ | aha | 11:30 |
| 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 linux | 11:31 |
| stekern | yes, or more correctly the other way around, uClibc does approximately the same stuff as glibc | 11:31 |
| olofk_ | but both uClibc and eglibc is meant as lightweight alternatives for glibc? | 11:32 |
| stekern | yes | 11:32 |
| olofk_ | Makes sense now | 11:32 |
| stekern | but eglibc comes closer in portability | 11:32 |
| stekern | err, compatibility I mean | 11:33 |
| stekern | with glibc | 11: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 |
| stekern | I think officially, they are Linux only (and perhaps Hurd for glibc) | 11:36 |
| olofk_ | What does BSD use? | 11:37 |
| stekern | the BSD libc, the one bionic is based on | 11:37 |
| olofk_ | aha | 11:41 |
| olofk_ | Saw in the wikipedia article about glibc that MicroBlaze only gained support in the latest revision | 11:42 |
| olofk_ | hmm.. but newlib can actually use linux as a backend. Things are getting confusing again | 11: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 cloud | 11:48 |
| LoneTech | or we could all start writing all out software in Nimrod ;) | 11:50 |
| LoneTech | s/out/our/ | 11:50 |
| olofk_ | LoneTech: I will start to rewrite the linux kernel to Nimrod then :) | 11:55 |
| jonibo | eglibc is binary compatible with glibc, uclibc is API compatible... that's the fundamental differnece | 12:42 |
| jonibo | olofk_: don't forget klibc | 12:44 |
| jonibo | klibc would be the Linux libc, but Linux doesn't really provide a libc itself | 12:44 |
| jonibo | eglibc 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 features | 12: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 |
| jonibo | yeah, it seems that people working on libc implementations are... special | 12:47 |
| olofk_ | I remember jeremybennett saying something about someone working on a stripped-down newlib also, because that was apparently also too large | 12:47 |
| olofk_ | :) | 12:47 |
| jonibo | newlib is for bare metal so it has to implement functions that the OS kernel would normally handle via syscalls | 12:47 |
| jonibo | you could do a newlib frontend to Linux, but what would be the point? | 12:48 |
| jonibo | if you link to newlib statically you get "only what you use" so it can hardly be smaller than that | 12:48 |
| jonibo | and I can probably qualify that further: you _do_ link to newlib statically | 12:49 |
| jonibo | libc'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 |
| jonibo | but glibc has historically been deemed too big for "embedded"... I think that's not really the case anymore as "embedded" has gotten bigger | 12:50 |
| jonibo | the 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 so | 12:50 |
| olofk_ | I think the thing about newlib was that malloc or printf was pulled in unconditionally | 12:50 |
| jonibo | the glibc maintainers are quite sane nowadays | 12:51 |
| jonibo | malloc and printf are implemented in GCC so the libc implementation is really trivial | 12:51 |
| jonibo | #define malloc __builtin_malloc | 12:51 |
| jonibo | that's it | 12:51 |
| olofk_ | aha | 12:51 |
| jonibo | you'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 nothing | 12: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 case | 12:53 |
| jonibo | but 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 lib | 12:53 |
| jonibo | if the "other functions" don't use them, they don't get pulled in! :( | 12:53 |
| jonibo | it's about as optimal as it can get | 12:54 |
| jonibo | and like I said, they are GCC builtins anyway, so the really don't exist | 12:54 |
| jonibo | anyway, 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 |
| jonibo | they should be written as simple assmebly routines | 12:55 |
| olofk_ | directly in GCC? | 12:55 |
| jonibo | directly in gCC | 12:55 |
| jonibo | you should put that up on a TODO list on the openrisc wiki so newcomers looking for a project know where to start | 12:55 |
| olofk_ | good idea | 12:55 |
| jonibo | there 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 Linux | 12: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 too | 12:57 |
| olofk_ | Yeah, I just wondered that. Do we really need the same code in GCC and Linux? | 12:57 |
| jonibo | Linux 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 itself | 12:59 |
| jonibo | kind of like newlib | 13:00 |
| jonibo | as newlib is pretty much an OS in itself | 13:00 |
| olofk_ | Yeah. That's true | 13:00 |
| stekern | jonibo: (crappy versions in the kernel) are you speaking about __copy_to_from_user and friends? | 14:15 |
| stekern | which have .section __ex_table | 14: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 |
| stekern | ah, this explains it well: http://www.tldp.org/LDP/khg/HyperNews/get/devices/exceptions.html | 14:27 |
| stekern | or 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 |
| stekern | well, I have read the code, so I had some pre-context perhaps ;) | 14:37 |
| olofk_ | That might help | 14: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 http://bugzilla.opencores.org/bugzilla4/show_bug.cgi?id=84 maybe we should just remove that define and always use Wishbone B3. What would be the arguments against that? | 14:58 |
| LoneTech | iirc 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 defined | 15:02 |
| blueCmd | stekern: my irc box was being mean so I missed the praise that you probably gave me for my awesome work | 15:05 |
| _franck_web_ | blueCmd: if you want to see all stekern says about you when you're not here: http://juliusbaxter.net/openrisc-irc/latest.log.html | 15:08 |
| 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? https://www.dropbox.com/s/b8t2zx0kbhv9cl3/or1k%20stack.png | 15:16 |
| blueCmd | _franck_web_: thanks! | 15:18 |
| blueCmd | stekern: 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 installed | 15: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 |
| blueCmd | olofk_: ... yeah, so I have the guy who ported it to aarch64 to help me | 15:33 |
| blueCmd | my current plan of attack is to get qemu-user running and compiling it through that | 15: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 in | 15:36 |
| olofk_ | _franck_web_: Yeah, I thought about that too. It should really be elf->linux->elf somehow | 15:36 |
| olofk_ | What I really want to show beneath the "ELF file" row is that that's where the or1k software part ends | 15:37 |
| olofk_ | Maybe I should rename it to or1k executable, or OpenRISC machine code | 15:38 |
| jonibo | stekern: 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 run | 15:41 |
| jonibo | for many of these "memory" functions we use the C versions which don't turn out particularly efficient | 15:41 |
| jonibo | really these functions should take word size, data alignment, cache size, etc into account and perform accordingly | 15:42 |
| jonibo | I'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 them | 15:45 |
| jonibo | memcpy currently just copies byte-by-byte | 15:45 |
| jonibo | it should copy up to word alignment and do word copies from there as far as possible | 15:46 |
| jonibo | for example | 15:46 |
| jonibo | in 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 efficient | 15:47 |
| jonibo | considering how much these libc functions are used, the potential gains are huge | 15:48 |
| stekern | jonibo: I agree, but where is the assembly version in linux, I haven't seen that | 16:38 |
| stekern | ? | 16:38 |
| -!- Netsplit *.net <-> *.split quits: olofk_ | 20:31 | |
| --- Log closed Fri Jan 24 00:00:07 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!
