IRC logs for #openrisc Wednesday, 2012-04-11

juliusb_jonibo_: hia07:42
juliusb_hiya, even07:43
juliusb_I am around, just on a different timezone this week07:43
juliusb_jonibo_: by DSX bug do you mean the fact that DSX doesn't work?07:44
juliusb_it sure does suck :(07:44
juliusb_and I would say it's unacceptable07:45
juliusb_how have we lived with it so far?07:45
juliusb_ah, because EPCR gets set to the jump/branch instruction before if there's an exception in a delay slot07:46
juliusb_it's just DSX isn't getting set07:47
juliusb_i'd be willing to wager that'd be trivial to fix07:47
jonibo_juliusb_: yeah, the DSX bug was one of things I wanted to chat with you about... glad you saw my earlier post07:59
jonibo_i spent a fair amount of time mulling that bug yesterday, and I think it's real bug that deserves fixing instead of workarounds08:00
jonibo_I guess that question was:  how trivial to fix is it?  (especially given that it's been there for 5 years, at least, without anybody being able to do so)08:01
jonibo_i did recall us having a discussion about this earlier where we came to the conclusion that that bit was optional... I can't remember why and I can't find any documentation about it, either08:02
jonibo_however, there was cases where there aren't even any heuristics that would allow you to guess whether you are in a delay slot or not... so having that bit as optional is just wrong08:03
jonibo_if you trap in a delay slot, for example, you can't know whether you trapped in the jump/branch or the delay slot proper08:04
juliusb_yeah fair enough08:37
juliusb_i reckon we chould fix it08:38
juliusb_should08:38
juliusb_I could have a look at it tomorrow08:38
juliusb_i'll see if there's anything on the bugzilla about this08:38
juliusb_http://bugzilla.opencores.org/show_bug.cgi?id=8508:46
juliusb_now there is08:46
jonibo_:) nice one09:02
_franck_juliusb_: still here ?09:06
stekernjonibo: I've been humouring myself with your WIP-llvm backend for or1k over the easter, I've got it to the point that it compiles against the current head09:09
stekernhttps://github.com/skristiansson/llvm-or1k09:09
jonibo_stekern: wow!09:09
jonibo_nice work09:10
stekernthanks, mostly been copying over changes done to the other targets so far, so no real work09:11
jonibo_did you rebase my work on current head?09:11
stekernbut it helps while getting accustomed with the codebase09:11
stekernyes, rebased it09:11
jonibo_cool... that's the way to do it09:11
jonibo_i'd done that also, but never finished doing all the fixups for 3.009:11
jonibo_i guess it's 3.1 now...09:11
jonibo_it's a really nice codebase, eh?09:12
stekernyes09:12
jonibo_much easier to work with than gcc09:12
stekernI've never really looked at the gcc code, it scares me :)09:12
jonibo_:)09:12
stekernprobably taking water over my head here too, but I'm doing it for "educational purposes" mostly09:13
stekern;)09:13
juliusb_pfft gcc isn't too bad on the surface, but I get epic lost deep down09:13
juliusb_so is llvm good?09:13
juliusb__franck_: yeah I'm here09:13
jonibo_llvm is modular09:13
jonibo_that's the nice bit09:13
jonibo_gcc is... murky09:13
juliusb_so can you compile stuff like u-boot and baremetal apps with llvm yet stekern ?09:14
juliusb_are there any embedded libraries for llvm like newlib for gcc?09:14
_franck_juliusb_: are you going to apply my patches to your tree ? I guy on the forum want to give it a try but it would be easier if the patch was already applied....09:14
juliusb__franck_: yes, I would like to but I haven't had time to test it yet, plus I don't have hardware here to test against unfortunately :( I left it in Cambridge. It's on the top of my todo list when I get back though09:15
juliusb_sorry maybe I should have mentioned this09:15
juliusb_i wrote the OpenOCD port for OpenRISC targets with multiple debug interfaces in mind09:15
juliusb_so am really happy you've done that work09:15
juliusb_I just need to test it properly and can'ty really do that without the hw09:16
_franck_ok :) I'll send him the patchs and instructions :)09:16
_franck_juliusb_: I understand09:16
stekernjuliusb_: the llvm port is at the stage that it compiles, not much more09:16
jonibo_juliusb: can't you just put those patches in a separate branch of your repo?09:17
juliusb_jonibo_: I guess I could09:17
jonibo_if the issue is making them available for somebodye else09:17
jonibo_just do a wip branch09:17
juliusb_ya09:17
jonibo_wip = "work in progress"09:17
jonibo_(in case that wasn't clear)09:17
juliusb_yeah good idea09:17
jonibo_i've got a bunch of those in all my repos! ;)09:17
juliusb_:)09:18
juliusb_it looks like llvm is intended to compile newlib09:18
jonibo_llvm is a compiler... it's intended to compile everything that  GCC does09:18
jonibo_it's not quite a drop-in replacement yet... but getting pretty close09:18
juliusb_cool, I always assumed GCC had some magical interweaving with newlib, although now that I think about it it must be the build system only09:19
stekernyeah, I read somewhere that it compiles around 92% of a debian system for arm/x86 targets09:19
jonibo_yeah, I think it may be intertwined with libgcc, but that should be about it09:19
jonibo_nice thing with llvm is that you can build support for _all_ targets at once09:19
juliusb_?!?!09:20
juliusb_what do you mean by targets?09:20
jonibo_so you can have a single cross-compiler that allows you to target arm, or1k, x86, etc...09:20
juliusb_different toolchain targets of a particular architecture or multiple architectures?09:20
stekernor1k is one target, x86 is another09:20
juliusb_ah right09:20
jonibo_instead of building a toolchain for each target arch09:20
juliusb_so it's a C compiler, do oyu need a linker and all tha ttoo?09:21
jonibo_actually the C compiler is called "clang"09:21
juliusb_ie. do you still need binutils?09:21
jonibo_you need binutils09:21
jonibo_there is no linker09:21
juliusb_ok cool09:21
jonibo_LLVM is the optimizing middle end and target backend09:21
jonibo_clang is probably a better C compiler than GCC already... GCC still outperforms LLVM09:22
juliusb_ok cool09:22
jonibo_and LLVM is BSD licensed so it will be perfect when somebody wants to do their proprietary openrisc fork :p09:22
jonibo_I'm thinking iRISC09:22
stekern:)09:22
juliusb_:)09:22
juliusb_they'll need the non-GPL RTL first09:24
juliusb_:)09:24
jonibo_yeah, I know who's sitting on that one ;)09:24
juliusb_haha09:24
juliusb_yeah i really need to get that tout09:24
juliusb_out09:24
juliusb_brb09:24
jonibo_sure, I gotta run now anyway09:25
jonibo_just to qualify my binutils statement above: you need the linker, but LLVM has it's own assembler and opcode lists so you don't need those bits from binutils09:25
jonibo_...bit convoluted I guess09:25
stekern..but you can use them09:25
jonibo_I suppose the plan longterm is to get rid of binutils completely09:25
_franck_got to drop my son to the nurse and go to work :), see you later09:26
jonibo_stekern: yes, you can still use them09:26
jonibo_...by not enabling the MC module, right?09:26
jonibo_something like that09:26
stekernI'm to fresh in the game to go into details ;)09:26
jonibo_sure, all good... anyway, nice work there... now I've got to run, too... bye for now09:27
stekernsee you09:27
juliusb_well, LLVM may be getting close, but our gcc-4.8 port is looking good, down to just a handful of failures in the regression test for newlib09:49
juliusb_it's my hacking on pgavin's work which was based on giuseppe's or1k gcc work09:49
juliusb_http://opencores.org/or1k/Newlib_tool_chain_test_results#GCC_4.8.009:50
juliusb_that's also using binutils which is tracking mainline09:50
juliusb_and is based on the CGEN port09:51
juliusb_so quite a nice little tool chain I reckon09:51
stekernthat's really nice09:51
juliusb_(regression test for the newlib-based tool chain I mean)09:52
juliusb_and in my opinion you could waive most of those failures, they don't seem serious09:55
juliusb_just testing oddities09:55
juliusb_or missing features from newlib09:55
stekernyou can almost count all of them with your hands :)09:59
jeremybennettHi stekern - well done on the LLVM port10:14
jeremybennettjuliusb_: And well done on the GCC progress.10:15
stekernjeremybennett: thanks, i want to stress though, at this point it's only bringing up Jonas work towards LLVM head, it's far from doing anything useful10:19
jeremybennettStefan Wallentowitz had a student working on LLVM last year.10:19
stekernyes, I asked him about it, the student didn't accept that work10:20
jeremybennettToo bad you are not at this week's LLVM conference in London. It finishes with a session on bringing up a compiler in 24 hours.10:20
stekern(or something in line with that, it never happened anyways)10:20
jeremybennettI'm surprised no one else has picked it up. You would think it would be a good student project.10:21
jeremybennettLLVM is very curious. The last conference had ever company under the sun there. Everyone seems to have a skunk-works project going on, but only ARM and Intel seem to have seriously maintained compilers.10:21
jeremybennettARM/Qualcomm/Apple seem to completely dominate the work.10:22
jeremybennettThe use of BSD has changed the culture. Much more big corporations trying to wrest control I sense. Less of a community spirit.10:23
jeremybennettI sense everyone is investing today in GCC, but watching LLVM in case it becomes important. A lot of the research seems to be in the GPGPU space - LLVMs role in OpenCL is significant.10:25
stekernhmm, interesting looking up that 24-hour compiler bring-up shows that it's held by Anton Korobeynikov10:29
stekernand googling a bit more I ended up here: https://github.com/asl/llvm-openrisc10:29
stekernso the 24 hour compiler bring-up will be about openrisc(?)10:31
jeremybennettInteresting. I'm supposed to be attending, but pressure of work may stop me going.10:33
joniboyou can bring up a frontend for LLVM in 24 hours... not a backend10:33
joniboyeah, so it is... openrisc llvm already exists10:36
jeremybennettstekern: I haven't seen the details - where did you find the link about Anton's talk?10:37
jeremybennettjonibo: The talk is actually about bringing up a backend "Building a backend in 24 hours"10:37
stekernhttp://llvm.org/devmtg/2012-04-12/10:38
jonibohis work looks really good10:38
jonibolooks pretty complete10:38
joniboyeah, I forget, you can bring up a frontend in 30 minutes... that was it10:40
jeremybennettI couldn't find the google connection to OpenRISC. However it is a subject he has talked on before (e.g. llvm.org/devmtg/2009-10/Korobeynikov_BackendTutorial.pdf). Last autumn he was talking about ARM status.10:45
stekernI googled the name and found his github account10:46
stekernthe connection between the openrisc port and his talk was just a guess from me10:50
stekernregardless, it's nice to have a guy like him doing work with openrisc10:50
jeremybennettGood guess. I'm just cloning the repository, so I can take a look in more detail.10:51
stekern(and his stuff will most likely a lot better than anything I'd be able to churn out :))10:51
stekern+be10:51
jeremybennettWell - he'll know more about the compiler and less about the architecture. The two of you combined would produce something awsome!10:52
jeremybennettawesome even10:52
stekernyeah, it's of course not an either or situation10:59
jeremybennettI see his OpenRISC stuff doesn't include CLANG.10:59
joniboclang is an independent front end...10:59
stekernfrom what I have understood the target specific changes to clang is minimal10:59
jonibowe don't have any intrinsics today anyway11:00
jeremybennettYes - but it implies he may not have yet built the front-end in with his backend (it is usually placed within the tools directory to facilitate this).11:00
stekernI wouldn't have put it in the repo anyways11:03
jeremybennettYes - you are right. It is a separate repo, so shouldn't be there.11:09
jeremybennettHe seems to have done quite a lot of work on OpenRISC over 5/6 April. I guess it was a preparation for his talk on Friday. There is a target directory.11:11
jeremybennettIf I attend, I'll talk to Anton and see if we can get him involved with the community here.11:11

Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!