IRC logs for #openrisc Monday, 2014-06-02

--- Log opened Mon Jun 02 00:00:16 2014
daliaspoke53281, the most obvious might be actually being maintained :)01:08
daliasor see:
poke53281dalias: Thanks for the list01:52
stekernpoke53281: then there's of course aspects I guess dalias is to modest to express, like codebase cleanliness04:38
stekerncompare vs
stekernfor example04:38
stekernyou'll find most of what's in crt1.S in a generic C implementation here:
stekernhaving that as a C implementation also have the added benefit that it get all those #ifdef __PIC__ automagically right04: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
daliasyeah, #musl does have ~2x the users of #openrisc :)04:48
stekerndalias: 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 enter04:56
stekerndo you recall that?04:57
daliaswhat gcc version?05:07
daliasfrom your issue description i'm not clear which issue you might be referring to05:07
daliasthe 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 stdout05: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 files05:09
stekernI see, I did use 4.9.0 (not the release version but one from 20140308)05:12
daliasin musl 1.1.1 and 1.0.2, configure auto-detects broken gcc and suggests a workaround05:13
daliasit's not ideal because that turns off a fair bit of useful optimization05:14
stekernok, let's try that first, and if that doesn't help, I'll backport some of our latest gcc stuff to 4.8.x05:14
daliasbut it was the only way i could get 4.9.0 not to break by changing CFLAGS short of passing -O0 :-p05:14
daliasor you can get the fix patch for 4.9.005:14
daliasit's on the bug report, #6114405:15
stekernah, ok05:15
daliasthey may end up wanting to do a different fix05:15
daliasbut this one works at least05: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
stekernfun times, eh? =)05:17
stekernand your fix proves the theorem that the harder a bug is to fix, the fewer lines are required to fix it ;)05:25
daliasalmost all of my patches to gcc and glibc are either + 1 line, or all -'s :)05:28
stekernhmm, -fno-toplevel-reorder didn't change things05:29
daliashmm 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 work05:30
stekernok, is the patch expected to "always" work?05:31
daliasit actually fixes the problem (wrongly treating weak aliases as candidates for constant folding)05:32
daliaswhereas -fno-toplevel-reorder just turned off some of the constant folding (not sure why)05:32
stekernok, 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) though05:53
daliasreally need to get this fixed upstream in gcc before it propagates more06:08
stekerndalias: with fix applied the problem goes away06:39
stekernso, 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
blueCmdthat with OpenRISC <308:57
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-cores09:41
olofk_bentley`: Yes, the EDA scene is awful. So many proprietary tools that are incompatible with each other09:41
sb0blueCmd, where is openrisc used? seems to me it's a custom cpu core?11:32
blueCmdsb0: yeah, but openrisc is a GPCPU, that is a GPGPU, so the latter could offload the first11:47
sb0stekern, TM->getMCAsmInfo() returns NULL12:32
sb0with llvm-or1k 3.412:33
sb0is that something you fixed later, in 3.5 (that is incompatible with llvmpy)?12:33
sb0stekern, the fix is simply to call initAsmInfo() in OR1KTargetMachine::OR1KTargetMachine13:02
sb0it puzzles me why it's not called by default, but this starts to become a pattern with LLVM13:03
sb0I can generate OR binaries from llvmpy now :)13:19
stekernor it's not doing that in the version you are working with?13:48
sb0no, I had to use an older version for llvmpy compatibility13:49
sb0I added this statement to get it to work13:49
stekernyou have to have bear with me too, it was nearly two years ago I seriously looked this code ;)13:49
stekernand anything related to the integrated asm, simoncook is the guy you want to ask13:50
stekernah, I missed your last line about generating OR binaries from llvmpy, nice!14:03
stekernblueCmd: nice conflicts, eh?
stekernaka, let's skip the rebase next time ;)14:18
stekernsorry... had to pick on you about that one last time14:18
blueCmdstekern: haha14:25
stekernnow, let's see how much mismerges I got in that14:26
blueCmdI did some reading about how merges and rebases are best used and I think I got how it's supposed to work now14:26
stekernalready found one ;)14:26
stekernno, I think you already knew, and you did that just to screw me over :(14:26
blueCmdrebase works wonders if all your commits are at the top, and merges are if they are not14:26
blueCmd"merges are if they are not" - wonderful sentence14:27
blueCmdI'm not even going to correct it14:27
stekernyup, and *if* you rebase, you rebase *your* stuff upon the upstream, not the other way around ;)14:40
sb0stekern, 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
stekernsb0: agreed ;)14:50
stekernright now, my greatest itch to scratch is getting SMP Linux running14:51
stekernwell, it is running, but running reliably14:52
sb0how good is the MMU, by the way?14:54
stekernwhat do you mean by 'good'?14:55
sb0fast, not bloated, bug-free14:55
stekernyes ;)14:58
stekernit's just a set of RAMs, it's pretty straight forward14:59
stekernthe current implementation is up to 128 entries, 1-way, but the architecture allows for more ways15:00
stekernthere'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 cache15:07
stekern...and it of course eats resources, something I know you especially dislike ;)15:09
stekernblueCmd: I fixed the mismerges and re-pushed the or1k-4.9.0 branch with a better merge messages15:25
stekern(at least I think I fixed all the mismerges, but anything after this gets to be incremental)15:27
stekernafter some rudimentary testing, I'm planning on pushing this to the or1k branch and apply the patch from this:
stekernsounds like a plan?15:29
blueCmdstekern: push away!15:32
blueCmddon't break anything ;)15:32
blueCmdstekern: - if you're doing stuff, mind taking a look if those patches are pushed?15:32
blueCmdI don't recall how many of those are pending merge15:33
stekernblueCmd: after a quick glance I think all except this is there:
blueCmdstekern: 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 more15:45
stekernsure, I think you are the greatest (and only?) user of them atm anyway ;)15:45
blueCmdhaha :)15:51
stekernwhich reminds me... I was in the middle of debugging why init crashes when I boot on hw/or1ksim15:57
stekerndid you ever get around to test running it in or1ksim?15:58
blueCmdstekern: no, I didn't16:10
stekernok, I pushed to or1k branch now. I'll be away travelling the rest of the week, hopefully nothing broke ;)18:43
daliasstekern, do you have stuff you want me to review for the musl port?18:46
stekerndalias: not in a neat package, but if you want to take a peak at the current work:
stekernldso stuff is still missing18:49
stekernI think I've got everything else covered, but I can have missed something18:49
daliasldso stuff is probably easy :)18:49
stekernyeah, but lazy implementing style, just do the stuff you immediately need ;)18:50
daliasthe per-arch ldso stuff is insanely minimal and i might eventually make it even moreso18:51
daliasby just having a table that maps the arch-specific reloc types to generic relocation types rather than duplicating the code18:51
stekernyou mean what's in reloc.h? that part I actually have done18:55
daliasthere's also a small asm file similar to crt118:55
stekernyup, that's what I'm missing18:56
daliasyeah that's a bit of a pain18:56
daliasi might eventually see if there's a way to make it simpler like the crt1.c stuff18:56
stekernI liked that, although I got confused for a second by most archs doing the .s implementation of them18:58
daliasyeah the crt_arch.h stuff was added later18:59
daliasand some ppl are like "don't remove the old asm because it's 10 bytes smaller and perfectly working" :-p18:59
daliasoh btw for pthread_arch.h __pthread_self, i think it can be optimized; see the powerpc version (using register + __asm__("r10"))19:04
daliasthen 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
daliasalso is or1k using TLS variant I or II ?19:05
daliashistorically most risc archs used the ugly variant (iirc it's called variant I) but microblaze uses the nicer one i386 and others use19:06
daliasanother question: is there a reason setjmp/longjmp are saving/restoring all registers? only the call-preserved registers should be needed; the rest contain junk19:12
stekernyeah, I just did what's done in uclibc there, that needs revising19:15
stekernblueCmd is our TLS expert, he can probably answer about TLS19:16
blueCmdI'm an expert!19:16
blueCmddalias: we use the nice one (if nice == TP at end of TCB)19:17
blueCmddalias: as for the code, it can most likely be optimized. the code is at:
daliasthat's the one i don't like, i think, but really either is fine19:20
blueCmdthe pro with that one is that you don't have to align relocations (IIRC)19:21
blueCmd has a nice ascii art of what we do19:21
daliasthe alignment logic is perhaps somewhat less ugly with this model, yes19:21
daliasanyway 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 it19:22
daliasbluecmd, am i right that you don't have an arbitrary offset tho?19:23
daliasmips 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 offsets19:23
blueCmddalias: not sure what you mean with arbitrary offset19:23
blueCmddalias: right, that's quite clever19:24
daliasit only helps if you have huge local-exec TLS19:24
daliasfor 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-time19:25
blueCmdI'm not sure that's needed though19:25
blueCmdit might shave off an addition19: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
blueCmdthat's how it's done currently19:26
daliasimo the 32k offset hack is not useful in practice because >32k of local-exec TLS is crazy19:28
blueCmdwhich means that boost and qt4 are using it everywhere19:29
daliasthey're not local-exec unless you static link19:30
blueCmd(compiling those beasts have unearthed a lot of bugs in our gcc)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
stekernas I said, not a neat package (yet) ;)19:35
daliasnot a complaint, just patch review19:42
stekernyup, I appreciate it19:44
blueCmdstekern: you didn't write the code!?20:02
blueCmdhow dare you!20:02
* blueCmd runs to replace microblaze/aarch64/mips/powerpc in or1k-glibc20:03
olofk_blueCmd: (yosys) Nice link. I always felt that an open source synthesis tool would make sense even if the backends are still closed20:29
stekernolofk_: it was sb0 that pasted that link, but yeah20:44
sb0yosys actually kinda works20:46
sb0it can build a suboptimal lm3220:46
stekernyeah, that's what I remember seeing something about in #m-labs some while back20:46
blueCmdstekern: that might be something you should apt-get install and try out :)21:02
olofk_Ah sorry sb0. Awesome to hear that it actually works. Does it generate EDIF files?21:11
olofk_(didn't read too carefully)21:11
sb0it has migen/mibuild integration too ;)21:12
olofk_blueCmd: Cute little board21:13
blueCmdno ethernet :( and small ram21:13
olofk_sb0: I really really should take a closer look at migen/mibuild soon21:13
blueCmdbut might be cool to have some demo on21:13
olofk_blueCmd: Yeah, it's cheap and with the USB port it could be used as a small computer21:20
olofk_Like for playing games or something21:20
olofk_Jesus christ. The free modelsim really is slow when they start throttle the speed21:21
sb0olofk_, are you doing a mixed-language simulation? otherwise there are decent free alternatives21:23
sb0verilator is actually faster than non-throttled modelsim21:23
olofk_sb0: Need to run against vendor models of SDRAM components, so verilator is out of the question for this case21:34
olofk_And I haven't figured out how/if icarus can use Altera's verilog libs21:35
olofk_I'm planning to replace the Altera components with some generic HDL when running Icarus, but I wanted to get this running first21: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 that21:36
olofk_I'm eagerly waiting for the day when mixed-language aren't a pain in the ass21:37
olofk_Oh well. Time to sleep now. Got most of the de0_nano testbench implemented in orpsoc-cores21:37
sb0I'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
blueCmdwe need better languages for HDL21:45
--- Log closed Tue Jun 03 00:00:17 2014

Generated by 2.15.2 by Marius Gedminas - find it at!