IRC logs for #openrisc Friday, 2012-10-05

juliusbalright, schedule posted02:58
stekernjuliusb: is that a bug or a feature?05:36
stekernIMO it's a feature, makes a lot more sense to write the offset you want to jump than the shifted value05:37
stekernbut it's of course a bit worrying that the behaviour is different from the old05:39
stekernwell, the old and new disassembler at least agrees and call it "l.j 8"05:46
stekernso I'd call it a fixed bug, but it's good to make a note of it so people are aware when they switch over05:47
olofkBut until someone has ported gdb we still need both toolchains, right?09:57
jeremybennettstekern: I wouldn't introduce arbitrary changes to assembler notation. You really don't want everyone rewriting their assembler in order to use the new compiler.10:22
jeremybennettIt's not about what is right or wrong (I have some sympathy for your case), just continuity.10:23
jeremybennettBut it is a bug in the old disassembler!10:24
stekernjeremybennett: well, we have users of the new notion as well11:09
stekernperhaps we can support the old behaviour with some flag of some sort11:10
jeremybennettstekern: We were astonished when we made the change to drop leading underscores from the GCC compiler how much hand-written assembler was out there. I guess we had emails and forum submissions (lots of them privately to me for good measure) about this for around a year afterwards, and we still occasionally get them.11:24
jeremybennettI really would urge you to keep the default behaviour as it always was and provide a flag for the new behaviour.11:25
jeremybennettBTW, I'm not sure if you saw a recent forum post complaining about a change in how the compiler worked. With a bit of digging, it turned out the user was running the 2002 GCC implementation.11:27
stekerndon't urgue to me, I haven't introduced the change11:41
stekerns/urgue/urge11:42
stekernand I stand by your point to some extent11:45
juliusbok, some advertising done: http://foss-sthlm.haxx.se/mail/foss-sthlm-archive-2012-10/0033.shtml11:49
stekernI still argue that the default should be the current behaviour though12:04
jeremybennettstekern: This isn12:17
jeremybennettThis isn't about technical correctness. It's about managing change in a large community. Break what everyone has already and people will not use your new tool.12:17
stekernjeremybennett: hence my: "and I stand by your point to some extent"12:18
jeremybennettThat's why so many Linux tools have really weird features. By the time someone realized it was wrong (like giving TAB and SPACE different meanings in make files) it was too late to change.12:18
jeremybennettstekern: Oh you meant I should have read *all* the messages, not just the last one :)12:19
jeremybennettwho do I have to urge?12:19
stekernand if someone was suggesting to put the change in now, I would even more stand by your point12:19
stekernI'm not sure, julius or peter are the usual suspects ;)12:20
jeremybennettjuliusb: Do you have any influence on this?12:21
jeremybennettI guess it's too early for Peter12:21
jeremybennettback shortly12:21
stekernthe point is, the change have already been deployed, suddenly flipping the default for or1k goes against your own logic12:26
stekernalthough I admit that there are more potential users for the or32 toolchain12:26
jeremybennettstekern: the rule in this case is always to change things as early as possible. I agree, once there are a significant number of users it gets harder. However the or1k tool chain is still the development tool chain, so it is not too late.12:29
stekernLet's hear what others have to say, at least we agree on the flag.12:35
stekernI can look into that12:35
jeremybennettthanks12:42
jeremybennettjuliusb: Just looking at your schedule, which is a great sequence, but looks too crammed for comfort. Part of the value of meetings like this is to talk, so I think you need more break space.12:43
juliusbhi12:44
juliusbsorry, just considering the last discussion about the jump/branch immediates in the new tool chain....12:44
jeremybennettIt might be an idea to push the tool chain talks into Sunday morning.12:44
jeremybennettThen you could have intro/boards/newbies, followed by 30 min break, then eCos/ORPSoCv3/mor1kx followed by 30 min break, then Open Source processes.12:46
jeremybennettParticularly if you want to run from noon to 6:30pm, we'll all need the breathing space.12:47
juliusbmmm, i'd be inclined, actually, to maybe run a little later then12:47
juliusbrun until 7/7:30 and get to dinner at 812:48
jeremybennettIt's getting a very long afternoon. People will tire, and you don't want them too tired for the last session.12:48
juliusbthere are breaks in there alredy, though12:48
juliusbalready12:49
jeremybennettYes - but the first one is just 10 minutes, and the second just 20 minutes.12:49
juliusbtrue12:49
juliusbwell, if Sunday is going to be a bigger session, we can reconvene at the RTE offices and make a proper session of it12:50
juliusbI believe they offerred the room to us for the whole weekend12:50
jeremybennettI think that is good. If people are spending on air fares and hotels, they want to get the most out of it. Run 60-90 minutes of talks on the tool chain first thing on Sunday, then OR1K architectural revision and OR2K discussion, then lunch, then bug-squashing until people have to leave.12:51
jeremybennettI think the LLVM will need more time with two speakers.12:52
juliusbstekern: this is mainly your talks being shifted, is that Ok with you?12:52
juliusbhmm, actually yeah, I forgot that that LLVM is two speaker12:52
jeremybennettYou also want to allow enough time for questions.12:52
juliusbalright, I'm happy to do that12:52
jeremybennettBTW - are you chairing the technical talks. If you run a tight schedule, you'll need to keep people to time (another reason generous breaks are useful).12:53
juliusbyep, I was planning to keep things on track because I also think a very important session is the final one12:53
juliusbso we need all the time we can get for that12:54
stekernI will probably not spend the whole 30 min on the dynamic linking12:54
juliusbdo you want to do the LLVM stuff on Sunday and keep the linking presentation on Saturday?12:55
juliusband make the linking presentation 20 minutes?12:55
juliusbalthough, I'm also inclined to make the mor1kx presentation a bit longer, too, so we can run some demos12:57
juliusbi'd like to get it running on a board to bring along12:57
stekernI'd rather move the linking to sunday than the LLVM12:59
juliusbhmm OK12:59
stekern(I'd prefer to not keep any presentations hangover to hangover people though ;))13:01
juliusbhehe13:01
juliusbbut I take jeremy's point that it will be a bit crammed13:01
stekernbut do what is necessary13:01
jeremybennettjuliusb: stekern: Running stuff is a really good idea. It keeps people interested.13:03
juliusbjeremybennett: do you mean on the Sunday?13:04
stekernI think he means in general13:04
jeremybennettSlightly off the wall idea. Would it make sense to split the processes discussion. Initial discussion on Saturday. A night to think things over/talk informally, then a follow up session on Sunday morning?13:04
jeremybennettjuliusb: It was a general principle. Boards are more interesting than powerpoint.13:04
jeremybennettBack in a bit...13:04
juliusbI think a two stage processes discussion could be good13:05
stekernjeremybennett: that sounds like an idea to me13:05
juliusbit would give people time to ruminate the ideas over dinner13:05
stekern...and over beer13:05
juliusbso keep the discussion to an hour on Saturday13:05
stekernregardning the branch immediates, I had a feeling all this sounded familiar, I dug up this: http://sourceware.org/ml/cgen/2012-q1/msg00001.html13:20
jeremybennettjuliusb: Your memory is considerably better than mine! Now you point it out, I remember this as well.13:30
juliusbno, that's stekern who pointed that out, I had completely forgotten this! :) but it's coming back to me now hehe13:31
juliusbI just think it's the incorrect behaviour I was attempting to emulate13:32
stekernyes, sounds like that13:33
juliusband now I recall I looked into what was suggested in the response I got, but never got it working13:34
juliusbbut really I don't think we should13:34
juliusbi think we should just keep the or1k-elf- (new) tool chain behaviour and make sure people are aware of this13:34
jeremybennettWell, if we do, we still ought to provide a flag for backwards compatibility.13:38
juliusbthe problem is, though, that we can't emulate this broken behaviour without a big hack on the CGEN stuff I think13:45
jeremybennettI've booked a hotel for next weekend. The Best Western Kom Hotel on Doebelnsgatan at £74/night.16:45
juliusbGreat, nice and close.16:51
juliusbjeremybennett: I see Adapteva made the Silicon 6017:31
jeremybennettExcellent. Do you have a link?17:35
juliusbhttp://eetimes.com/electronics-news/4397402/EE-Times-lists-60-startups-to-watch17:35
jeremybennettThx17:36
jeremybennettNow all they need is to complete their kickstarter. Looking at http://kck.st/PtAZ9O they are 25% there with 25% of the time gone.17:36
jeremybennettIt's a big target, but hopefully they'll reach it. I see there is an option now to ask for the 64-core board for $199.17:37
stekernah, they are the ones behind epiphany that you (as in your company) did the toolchain work for, right?18:24
jeremybennettstekern: That's right. Now they want to turn it into a $99 board.18:27
jeremybennettTrying to raise $750k in 30 days on Kickstarter18:27
jeremybennettI've backed them18:28
stekernsounds interesting, I'll have to take a closer look18:33
olofkOh well, I'm off for the weekend. Goodbye chat bots19:51
jeremybennettBye20:08
juliusbolofk: later mate20:24

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