| --- Log opened Mon Jun 02 00:00:16 2014 | ||
| dalias | poke53281, the most obvious might be actually being maintained :) | 01:08 |
|---|---|---|
| dalias | or see: http://www.etalabs.net/compare_libcs.html | 01:09 |
| poke53281 | dalias: Thanks for the list | 01:52 |
| stekern | poke53281: then there's of course aspects I guess dalias is to modest to express, like codebase cleanliness | 04:38 |
| stekern | compare https://github.com/openrisc/uClibc-or1k/blob/master/libc/sysdeps/linux/or1k/crt1.S vs https://github.com/skristiansson/musl-or1k/blob/master/arch/or1k/crt_arch.h | 04:38 |
| stekern | for example | 04:38 |
| stekern | you'll find most of what's in crt1.S in a generic C implementation here: https://github.com/skristiansson/musl-or1k/blob/master/crt/crt1.c | 04:39 |
| stekern | having that as a C implementation also have the added benefit that it get all those #ifdef __PIC__ automagically right | 04:41 |
| stekern | + if you by 'we' mean the openrisc community, and not the world population as a whole, if nothing else, it's a way of spreading the OpenRISC gospel =) | 04:46 |
| dalias | yeah, #musl does have ~2x the users of #openrisc :) | 04:48 |
| stekern | ;) | 04:54 |
| stekern | dalias: I'm actually seeing one odd issue, and grepping through the #musl irc-logs I found what I recalled seeing, another guy having problems with not seeing anything on console until you press enter | 04:56 |
| stekern | do you recall that? | 04:57 |
| dalias | what gcc version? | 05:07 |
| dalias | from your issue description i'm not clear which issue you might be referring to | 05:07 |
| dalias | the related ones that come to mind are: | 05:07 |
| dalias | (1) a bug in gcc 4.9.0 that wrongly constant-folds non-constant expressions and thereby optimizes out flushing of stdout | 05:08 |
| dalias | (2) musl lacks the "flush all output streams whenever you read from an input stream" behavior other libcs have, and this omission is intentional because that behavior is not required by the standard and interacts very badly with threads and scales very poorly with large numbers of open files | 05:09 |
| stekern | I see, I did use 4.9.0 (not the release version but one from 20140308) | 05:12 |
| dalias | in musl 1.1.1 and 1.0.2, configure auto-detects broken gcc and suggests a workaround | 05:13 |
| stekern | CFLAGS=-fno-toplevel-reorder | 05:14 |
| stekern | right? | 05:14 |
| dalias | yeah | 05:14 |
| dalias | it's not ideal because that turns off a fair bit of useful optimization | 05:14 |
| stekern | ok, let's try that first, and if that doesn't help, I'll backport some of our latest gcc stuff to 4.8.x | 05:14 |
| dalias | but it was the only way i could get 4.9.0 not to break by changing CFLAGS short of passing -O0 :-p | 05:14 |
| dalias | or you can get the fix patch for 4.9.0 | 05:14 |
| dalias | it's on the bug report, #61144 | 05:15 |
| stekern | ah, ok | 05:15 |
| dalias | they may end up wanting to do a different fix | 05:15 |
| dalias | but this one works at least | 05:15 |
| dalias | (and i spent something like a weak bisecting, digging thru gcc sources, and finding the point of breakage and this fix...) | 05:16 |
| stekern | fun times, eh? =) | 05:17 |
| stekern | and your fix proves the theorem that the harder a bug is to fix, the fewer lines are required to fix it ;) | 05:25 |
| dalias | :) | 05:27 |
| dalias | almost all of my patches to gcc and glibc are either + 1 line, or all -'s :) | 05:28 |
| stekern | hmm, -fno-toplevel-reorder didn't change things | 05:29 |
| dalias | hmm i heard some reports that it didn't do the job. that's why configure just suggests you add it, and makes you re-run configure to check it again, rather than simply adding it and assuming it will work | 05:30 |
| stekern | ok, is the patch expected to "always" work? | 05:31 |
| dalias | yes | 05:32 |
| dalias | it actually fixes the problem (wrongly treating weak aliases as candidates for constant folding) | 05:32 |
| dalias | whereas -fno-toplevel-reorder just turned off some of the constant folding (not sure why) | 05:32 |
| stekern | ok, I'm compiling gcc with the fix now, the configure script didn't complain when I had -fno-toplevel-reorder without the fix (it did complain when I didn't have -fno-toplevel-reorder) though | 05:53 |
| dalias | :/ | 06:08 |
| dalias | really need to get this fixed upstream in gcc before it propagates more | 06:08 |
| stekern | dalias: with fix applied the problem goes away | 06:39 |
| stekern | so, 2 pieces of info from my experiments: 1) confirmed that -fno-toplevel-reorder is not enough 2) the test in the config script isn't perfect (but at least it seems to work as a 'broken version' indicator) | 06:41 |
| dalias | thanks | 06:43 |
| blueCmd | https://github.com/jbush001/GPGPU | 08:57 |
| blueCmd | that with OpenRISC <3 | 08:57 |
| dalias | :) | 09:14 |
| bentley` | yes, but when will we have an alternative to quartus/xilinx :( | 09:40 |
| olofk_ | blueCmd: Interesting. We should try it out and add it to orpsoc-cores | 09:41 |
| olofk_ | bentley`: Yes, the EDA scene is awful. So many proprietary tools that are incompatible with each other | 09:41 |
| sb0 | bentley`, https://github.com/cliffordwolf/yosys | 11:29 |
| sb0 | blueCmd, where is openrisc used? seems to me it's a custom cpu core? | 11:32 |
| blueCmd | sb0: yeah, but openrisc is a GPCPU, that is a GPGPU, so the latter could offload the first | 11:47 |
| sb0 | stekern, TM->getMCAsmInfo() returns NULL | 12:32 |
| sb0 | with llvm-or1k 3.4 | 12:33 |
| sb0 | is that something you fixed later, in 3.5 (that is incompatible with llvmpy)? | 12:33 |
| sb0 | stekern, the fix is simply to call initAsmInfo() in OR1KTargetMachine::OR1KTargetMachine | 13:02 |
| sb0 | it puzzles me why it's not called by default, but this starts to become a pattern with LLVM | 13:03 |
| sb0 | I can generate OR binaries from llvmpy now :) | 13:19 |
| stekern | sb0: https://github.com/openrisc/llvm-or1k/blob/master/lib/Target/OR1K/OR1KTargetMachine.cpp#L44 | 13:48 |
| stekern | or it's not doing that in the version you are working with? | 13:48 |
| sb0 | no, I had to use an older version for llvmpy compatibility | 13:49 |
| sb0 | I added this statement to get it to work | 13:49 |
| stekern | you have to have bear with me too, it was nearly two years ago I seriously looked this code ;) | 13:49 |
| stekern | and anything related to the integrated asm, simoncook is the guy you want to ask | 13:50 |
| stekern | +at | 13:50 |
| stekern | ah, I missed your last line about generating OR binaries from llvmpy, nice! | 14:03 |
| sb0 | :) | 14:05 |
| stekern | blueCmd: nice conflicts, eh? https://github.com/openrisc/or1k-gcc/commit/4f12499b2c6f271339b17a2a5142c573b05cbb79 | 14:18 |
| stekern | aka, let's skip the rebase next time ;) | 14:18 |
| stekern | sorry... had to pick on you about that one last time | 14:18 |
| blueCmd | stekern: haha | 14:25 |
| stekern | now, let's see how much mismerges I got in that | 14:26 |
| blueCmd | I did some reading about how merges and rebases are best used and I think I got how it's supposed to work now | 14:26 |
| stekern | already found one ;) | 14:26 |
| stekern | no, I think you already knew, and you did that just to screw me over :( | 14:26 |
| blueCmd | rebase works wonders if all your commits are at the top, and merges are if they are not | 14:26 |
| blueCmd | haha | 14:26 |
| blueCmd | "merges are if they are not" - wonderful sentence | 14:27 |
| blueCmd | I'm not even going to correct it | 14:27 |
| stekern | yup, and *if* you rebase, you rebase *your* stuff upon the upstream, not the other way around ;) | 14:40 |
| sb0 | stekern, so, after those extra 1.6k LUTs are removed, llvmpy works with llvm 3.5, the llvm assembler can build the crt etc., and llvm and gcc are upstream, mor1kx would be a great platform :-) | 14:42 |
| stekern | sb0: agreed ;) | 14:50 |
| stekern | right now, my greatest itch to scratch is getting SMP Linux running | 14:51 |
| stekern | well, it is running, but running reliably | 14:52 |
| sb0 | how good is the MMU, by the way? | 14:54 |
| stekern | what do you mean by 'good'? | 14:55 |
| sb0 | fast, not bloated, bug-free | 14:55 |
| stekern | yes ;) | 14:58 |
| stekern | it's just a set of RAMs, it's pretty straight forward | 14:59 |
| stekern | the current implementation is up to 128 entries, 1-way, but the architecture allows for more ways | 15:00 |
| stekern | there's optional hardware TLB refill, but the advantage of the current implementation is questionable, since the hw refiller doesn't go through the caches (although it could), and the pagetables and sw tlb refill routine most likely is in cache | 15:07 |
| stekern | ...and it of course eats resources, something I know you especially dislike ;) | 15:09 |
| stekern | blueCmd: I fixed the mismerges and re-pushed the or1k-4.9.0 branch with a better merge messages | 15:25 |
| stekern | *message | 15:25 |
| stekern | (at least I think I fixed all the mismerges, but anything after this gets to be incremental) | 15:27 |
| stekern | after some rudimentary testing, I'm planning on pushing this to the or1k branch and apply the patch from this: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 | 15:28 |
| stekern | sounds like a plan? | 15:29 |
| blueCmd | stekern: push away! | 15:32 |
| blueCmd | don't break anything ;) | 15:32 |
| blueCmd | stekern: https://github.com/bluecmd/or1k-gcc/commits/master - if you're doing stuff, mind taking a look if those patches are pushed? | 15:32 |
| blueCmd | I don't recall how many of those are pending merge | 15:33 |
| stekern | blueCmd: after a quick glance I think all except this is there: https://github.com/bluecmd/or1k-gcc/commit/3e3c9dcd128bbef9b2d38ca984251ddd83223ddf | 15:43 |
| blueCmd | stekern: good. maybe hold off on the atomics one if you don't want to add it now, I think I want to test it a bit more | 15:45 |
| stekern | sure, I think you are the greatest (and only?) user of them atm anyway ;) | 15:45 |
| blueCmd | haha :) | 15:51 |
| stekern | which reminds me... I was in the middle of debugging why init crashes when I boot on hw/or1ksim | 15:57 |
| stekern | did you ever get around to test running it in or1ksim? | 15:58 |
| blueCmd | stekern: no, I didn't | 16:10 |
| stekern | ok, I pushed to or1k branch now. I'll be away travelling the rest of the week, hopefully nothing broke ;) | 18:43 |
| dalias | stekern, do you have stuff you want me to review for the musl port? | 18:46 |
| stekern | dalias: not in a neat package, but if you want to take a peak at the current work: https://github.com/skristiansson/musl-or1k/commits/master | 18:48 |
| stekern | ldso stuff is still missing | 18:49 |
| stekern | I think I've got everything else covered, but I can have missed something | 18:49 |
| dalias | ldso stuff is probably easy :) | 18:49 |
| stekern | yeah, but lazy implementing style, just do the stuff you immediately need ;) | 18:50 |
| dalias | *nod* | 18:50 |
| dalias | the per-arch ldso stuff is insanely minimal and i might eventually make it even moreso | 18:51 |
| dalias | by just having a table that maps the arch-specific reloc types to generic relocation types rather than duplicating the code | 18:51 |
| stekern | you mean what's in reloc.h? that part I actually have done | 18:55 |
| dalias | yeah | 18:55 |
| dalias | there's also a small asm file similar to crt1 | 18:55 |
| stekern | yup, that's what I'm missing | 18:56 |
| dalias | ah | 18:56 |
| dalias | yeah that's a bit of a pain | 18:56 |
| dalias | i might eventually see if there's a way to make it simpler like the crt1.c stuff | 18:56 |
| stekern | I liked that, although I got confused for a second by most archs doing the .s implementation of them | 18:58 |
| dalias | yeah the crt_arch.h stuff was added later | 18:59 |
| dalias | and some ppl are like "don't remove the old asm because it's 10 bytes smaller and perfectly working" :-p | 18:59 |
| stekern | heh | 18:59 |
| dalias | oh btw for pthread_arch.h __pthread_self, i think it can be optimized; see the powerpc version (using register + __asm__("r10")) | 19:04 |
| dalias | then gcc can use the register directly in expressions rather than having to move it. | 19:04 |
| dalias | (this is broken on clang tho so we have a fallback for it) | 19:05 |
| dalias | also is or1k using TLS variant I or II ? | 19:05 |
| dalias | historically most risc archs used the ugly variant (iirc it's called variant I) but microblaze uses the nicer one i386 and others use | 19:06 |
| dalias | another question: is there a reason setjmp/longjmp are saving/restoring all registers? only the call-preserved registers should be needed; the rest contain junk | 19:12 |
| stekern | yeah, I just did what's done in uclibc there, that needs revising | 19:15 |
| stekern | blueCmd is our TLS expert, he can probably answer about TLS | 19:16 |
| blueCmd | I'm an expert! | 19:16 |
| blueCmd | dalias: we use the nice one (if nice == TP at end of TCB) | 19:17 |
| blueCmd | dalias: as for the code, it can most likely be optimized. the code is at: https://github.com/bluecmd/or1k-glibc/blob/1688660582f50a123d38fb2298a23c5cfa4505d8/ports/sysdeps/or1k/nptl/tls.h | 19:20 |
| dalias | that's the one i don't like, i think, but really either is fine | 19:20 |
| blueCmd | the pro with that one is that you don't have to align relocations (IIRC) | 19:21 |
| blueCmd | https://github.com/bluecmd/or1k-glibc/blob/1688660582f50a123d38fb2298a23c5cfa4505d8/ports/sysdeps/or1k/nptl/tls.h#L60 has a nice ascii art of what we do | 19:21 |
| dalias | the alignment logic is perhaps somewhat less ugly with this model, yes | 19:21 |
| dalias | anyway stekern's port needs a few changes then; right now pthread_arch.h is written assuming the thread pointer points to the beginning of the pthread structure rather than the end of it | 19:22 |
| dalias | bluecmd, am i right that you don't have an arbitrary offset tho? | 19:23 |
| dalias | mips and ppc and some other risc archs point the thread pointer 32k past the end of the TCB to maximize the amount of TLS you can access with signed 16-bit offsets | 19:23 |
| blueCmd | dalias: not sure what you mean with arbitrary offset | 19:23 |
| blueCmd | dalias: right, that's quite clever | 19:24 |
| dalias | well | 19:24 |
| dalias | it only helps if you have huge local-exec TLS | 19:24 |
| dalias | for everything else, there's no way to take advantage of the 16-bit signed offsets anyway because it's not known to fit at link-time | 19:25 |
| blueCmd | I'm not sure that's needed though | 19:25 |
| blueCmd | it might shave off an addition | 19:25 |
| blueCmd | emit_insn (gen_movsi_tpoffhi (hi, sym)); | 19:26 |
| blueCmd | emit_insn (gen_movsi_tpofflo (addr, hi, sym)); | 19:26 |
| blueCmd | emit_insn (gen_add3_insn (result, addr, tp)); | 19:26 |
| blueCmd | that's how it's done currently | 19:26 |
| dalias | imo the 32k offset hack is not useful in practice because >32k of local-exec TLS is crazy | 19:28 |
| blueCmd | yeah | 19:28 |
| blueCmd | which means that boost and qt4 are using it everywhere | 19:29 |
| dalias | they're not local-exec unless you static link | 19:30 |
| blueCmd | (compiling those beasts have unearthed a lot of bugs in our gcc) | 19:30 |
| dalias | :) | 19:30 |
| stekern | (pthread_arch.h) yes, you're right, that needs fixing. I just copied that from microblaze and made it compile on or1k. | 19:35 |
| stekern | as I said, not a neat package (yet) ;) | 19:35 |
| dalias | *nod* | 19:42 |
| dalias | not a complaint, just patch review | 19:42 |
| stekern | yup, I appreciate it | 19:44 |
| blueCmd | stekern: you didn't write the code!? | 20:02 |
| blueCmd | how dare you! | 20:02 |
| * blueCmd runs to replace microblaze/aarch64/mips/powerpc in or1k-glibc | 20:03 | |
| stekern | haha | 20:03 |
| dalias | :) | 20:07 |
| olofk_ | blueCmd: (yosys) Nice link. I always felt that an open source synthesis tool would make sense even if the backends are still closed | 20:29 |
| stekern | olofk_: it was sb0 that pasted that link, but yeah | 20:44 |
| sb0 | yosys actually kinda works | 20:46 |
| sb0 | it can build a suboptimal lm32 | 20:46 |
| stekern | yeah, that's what I remember seeing something about in #m-labs some while back | 20:46 |
| blueCmd | stekern: http://flarerpg.org/ that might be something you should apt-get install and try out :) | 21:02 |
| blueCmd | olofk_: http://www.cnx-software.com/2014/06/02/69-minispartan6-board-with-xilinx-spartan-6-fpga-features-an-hdmi-port-crowdfunding/ | 21:04 |
| olofk_ | Ah sorry sb0. Awesome to hear that it actually works. Does it generate EDIF files? | 21:11 |
| sb0 | yes | 21:11 |
| olofk_ | (didn't read too carefully) | 21:11 |
| sb0 | it has migen/mibuild integration too ;) | 21:12 |
| olofk_ | blueCmd: Cute little board | 21:13 |
| blueCmd | no ethernet :( and small ram | 21:13 |
| olofk_ | sb0: I really really should take a closer look at migen/mibuild soon | 21:13 |
| blueCmd | but might be cool to have some demo on | 21:13 |
| olofk_ | blueCmd: Yeah, it's cheap and with the USB port it could be used as a small computer | 21:20 |
| olofk_ | Like for playing games or something | 21:20 |
| olofk_ | Jesus christ. The free modelsim really is slow when they start throttle the speed | 21:21 |
| sb0 | olofk_, are you doing a mixed-language simulation? otherwise there are decent free alternatives | 21:23 |
| sb0 | verilator is actually faster than non-throttled modelsim | 21:23 |
| olofk_ | sb0: Need to run against vendor models of SDRAM components, so verilator is out of the question for this case | 21:34 |
| olofk_ | And I haven't figured out how/if icarus can use Altera's verilog libs | 21:35 |
| olofk_ | I'm planning to replace the Altera components with some generic HDL when running Icarus, but I wanted to get this running first | 21:36 |
| olofk_ | The ohwr guys have dedicated some resources to improve the VHDL parsing in icarus btw. I filed a few bug reports and sent in some patches for that | 21:36 |
| olofk_ | I'm eagerly waiting for the day when mixed-language aren't a pain in the ass | 21:37 |
| olofk_ | Oh well. Time to sleep now. Got most of the de0_nano testbench implemented in orpsoc-cores | 21:37 |
| sb0 | I'm eagerly waiting for the day when Verilog and VHDL are not used more than COBOL :-) | 21:41 |
| sb0 | (and same for SystemVerilog) | 21:41 |
| blueCmd | yeah | 21:45 |
| blueCmd | we need better languages for HDL | 21:45 |
| --- Log closed Tue Jun 03 00:00:17 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!