| juliusb_ | jonibo_: hia | 07:42 |
|---|---|---|
| juliusb_ | hiya, even | 07:43 |
| juliusb_ | I am around, just on a different timezone this week | 07: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 unacceptable | 07: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 slot | 07:46 |
| juliusb_ | it's just DSX isn't getting set | 07:47 |
| juliusb_ | i'd be willing to wager that'd be trivial to fix | 07:47 |
| jonibo_ | juliusb_: yeah, the DSX bug was one of things I wanted to chat with you about... glad you saw my earlier post | 07: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 workarounds | 08: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, either | 08: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 wrong | 08: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 proper | 08:04 |
| juliusb_ | yeah fair enough | 08:37 |
| juliusb_ | i reckon we chould fix it | 08:38 |
| juliusb_ | should | 08:38 |
| juliusb_ | I could have a look at it tomorrow | 08:38 |
| juliusb_ | i'll see if there's anything on the bugzilla about this | 08:38 |
| juliusb_ | http://bugzilla.opencores.org/show_bug.cgi?id=85 | 08:46 |
| juliusb_ | now there is | 08:46 |
| jonibo_ | :) nice one | 09:02 |
| _franck_ | juliusb_: still here ? | 09:06 |
| stekern | jonibo: 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 head | 09:09 |
| stekern | https://github.com/skristiansson/llvm-or1k | 09:09 |
| jonibo_ | stekern: wow! | 09:09 |
| jonibo_ | nice work | 09:10 |
| stekern | thanks, mostly been copying over changes done to the other targets so far, so no real work | 09:11 |
| jonibo_ | did you rebase my work on current head? | 09:11 |
| stekern | but it helps while getting accustomed with the codebase | 09:11 |
| stekern | yes, rebased it | 09:11 |
| jonibo_ | cool... that's the way to do it | 09:11 |
| jonibo_ | i'd done that also, but never finished doing all the fixups for 3.0 | 09:11 |
| jonibo_ | i guess it's 3.1 now... | 09:11 |
| jonibo_ | it's a really nice codebase, eh? | 09:12 |
| stekern | yes | 09:12 |
| jonibo_ | much easier to work with than gcc | 09:12 |
| stekern | I've never really looked at the gcc code, it scares me :) | 09:12 |
| jonibo_ | :) | 09:12 |
| stekern | probably taking water over my head here too, but I'm doing it for "educational purposes" mostly | 09:13 |
| stekern | ;) | 09:13 |
| juliusb_ | pfft gcc isn't too bad on the surface, but I get epic lost deep down | 09:13 |
| juliusb_ | so is llvm good? | 09:13 |
| juliusb_ | _franck_: yeah I'm here | 09:13 |
| jonibo_ | llvm is modular | 09:13 |
| jonibo_ | that's the nice bit | 09:13 |
| jonibo_ | gcc is... murky | 09: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 though | 09:15 |
| juliusb_ | sorry maybe I should have mentioned this | 09:15 |
| juliusb_ | i wrote the OpenOCD port for OpenRISC targets with multiple debug interfaces in mind | 09:15 |
| juliusb_ | so am really happy you've done that work | 09:15 |
| juliusb_ | I just need to test it properly and can'ty really do that without the hw | 09:16 |
| _franck_ | ok :) I'll send him the patchs and instructions :) | 09:16 |
| _franck_ | juliusb_: I understand | 09:16 |
| stekern | juliusb_: the llvm port is at the stage that it compiles, not much more | 09:16 |
| jonibo_ | juliusb: can't you just put those patches in a separate branch of your repo? | 09:17 |
| juliusb_ | jonibo_: I guess I could | 09:17 |
| jonibo_ | if the issue is making them available for somebodye else | 09:17 |
| jonibo_ | just do a wip branch | 09:17 |
| juliusb_ | ya | 09:17 |
| jonibo_ | wip = "work in progress" | 09:17 |
| jonibo_ | (in case that wasn't clear) | 09:17 |
| juliusb_ | yeah good idea | 09: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 newlib | 09:18 |
| jonibo_ | llvm is a compiler... it's intended to compile everything that GCC does | 09:18 |
| jonibo_ | it's not quite a drop-in replacement yet... but getting pretty close | 09: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 only | 09:19 |
| stekern | yeah, I read somewhere that it compiles around 92% of a debian system for arm/x86 targets | 09:19 |
| jonibo_ | yeah, I think it may be intertwined with libgcc, but that should be about it | 09:19 |
| jonibo_ | nice thing with llvm is that you can build support for _all_ targets at once | 09: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 |
| stekern | or1k is one target, x86 is another | 09:20 |
| juliusb_ | ah right | 09:20 |
| jonibo_ | instead of building a toolchain for each target arch | 09: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 binutils | 09:21 |
| jonibo_ | there is no linker | 09:21 |
| juliusb_ | ok cool | 09:21 |
| jonibo_ | LLVM is the optimizing middle end and target backend | 09:21 |
| jonibo_ | clang is probably a better C compiler than GCC already... GCC still outperforms LLVM | 09:22 |
| juliusb_ | ok cool | 09:22 |
| jonibo_ | and LLVM is BSD licensed so it will be perfect when somebody wants to do their proprietary openrisc fork :p | 09:22 |
| jonibo_ | I'm thinking iRISC | 09:22 |
| stekern | :) | 09:22 |
| juliusb_ | :) | 09:22 |
| juliusb_ | they'll need the non-GPL RTL first | 09:24 |
| juliusb_ | :) | 09:24 |
| jonibo_ | yeah, I know who's sitting on that one ;) | 09:24 |
| juliusb_ | haha | 09:24 |
| juliusb_ | yeah i really need to get that tout | 09:24 |
| juliusb_ | out | 09:24 |
| juliusb_ | brb | 09:24 |
| jonibo_ | sure, I gotta run now anyway | 09: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 binutils | 09:25 |
| jonibo_ | ...bit convoluted I guess | 09:25 |
| stekern | ..but you can use them | 09:25 |
| jonibo_ | I suppose the plan longterm is to get rid of binutils completely | 09:25 |
| _franck_ | got to drop my son to the nurse and go to work :), see you later | 09:26 |
| jonibo_ | stekern: yes, you can still use them | 09:26 |
| jonibo_ | ...by not enabling the MC module, right? | 09:26 |
| jonibo_ | something like that | 09:26 |
| stekern | I'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 now | 09:27 |
| stekern | see you | 09: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 newlib | 09:49 |
| juliusb_ | it's my hacking on pgavin's work which was based on giuseppe's or1k gcc work | 09:49 |
| juliusb_ | http://opencores.org/or1k/Newlib_tool_chain_test_results#GCC_4.8.0 | 09:50 |
| juliusb_ | that's also using binutils which is tracking mainline | 09:50 |
| juliusb_ | and is based on the CGEN port | 09:51 |
| juliusb_ | so quite a nice little tool chain I reckon | 09:51 |
| stekern | that's really nice | 09: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 serious | 09:55 |
| juliusb_ | just testing oddities | 09:55 |
| juliusb_ | or missing features from newlib | 09:55 |
| stekern | you can almost count all of them with your hands :) | 09:59 |
| jeremybennett | Hi stekern - well done on the LLVM port | 10:14 |
| jeremybennett | juliusb_: And well done on the GCC progress. | 10:15 |
| stekern | jeremybennett: 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 useful | 10:19 |
| jeremybennett | Stefan Wallentowitz had a student working on LLVM last year. | 10:19 |
| stekern | yes, I asked him about it, the student didn't accept that work | 10:20 |
| jeremybennett | Too 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 |
| jeremybennett | I'm surprised no one else has picked it up. You would think it would be a good student project. | 10:21 |
| jeremybennett | LLVM 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 |
| jeremybennett | ARM/Qualcomm/Apple seem to completely dominate the work. | 10:22 |
| jeremybennett | The use of BSD has changed the culture. Much more big corporations trying to wrest control I sense. Less of a community spirit. | 10:23 |
| jeremybennett | I 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 |
| stekern | hmm, interesting looking up that 24-hour compiler bring-up shows that it's held by Anton Korobeynikov | 10:29 |
| stekern | and googling a bit more I ended up here: https://github.com/asl/llvm-openrisc | 10:29 |
| stekern | so the 24 hour compiler bring-up will be about openrisc(?) | 10:31 |
| jeremybennett | Interesting. I'm supposed to be attending, but pressure of work may stop me going. | 10:33 |
| jonibo | you can bring up a frontend for LLVM in 24 hours... not a backend | 10:33 |
| jonibo | yeah, so it is... openrisc llvm already exists | 10:36 |
| jeremybennett | stekern: I haven't seen the details - where did you find the link about Anton's talk? | 10:37 |
| jeremybennett | jonibo: The talk is actually about bringing up a backend "Building a backend in 24 hours" | 10:37 |
| stekern | http://llvm.org/devmtg/2012-04-12/ | 10:38 |
| jonibo | his work looks really good | 10:38 |
| jonibo | looks pretty complete | 10:38 |
| jonibo | yeah, I forget, you can bring up a frontend in 30 minutes... that was it | 10:40 |
| jeremybennett | I 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 |
| stekern | I googled the name and found his github account | 10:46 |
| stekern | the connection between the openrisc port and his talk was just a guess from me | 10:50 |
| stekern | regardless, it's nice to have a guy like him doing work with openrisc | 10:50 |
| jeremybennett | Good 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 | +be | 10:51 |
| jeremybennett | Well - he'll know more about the compiler and less about the architecture. The two of you combined would produce something awsome! | 10:52 |
| jeremybennett | awesome even | 10:52 |
| stekern | yeah, it's of course not an either or situation | 10:59 |
| jeremybennett | I see his OpenRISC stuff doesn't include CLANG. | 10:59 |
| jonibo | clang is an independent front end... | 10:59 |
| stekern | from what I have understood the target specific changes to clang is minimal | 10:59 |
| jonibo | we don't have any intrinsics today anyway | 11:00 |
| jeremybennett | Yes - 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 |
| stekern | I wouldn't have put it in the repo anyways | 11:03 |
| jeremybennett | Yes - you are right. It is a separate repo, so shouldn't be there. | 11:09 |
| jeremybennett | He 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 |
| jeremybennett | If 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!