IRC logs for #openrisc Saturday, 2014-03-08

--- Log opened Sat Mar 08 00:00:11 2014
blueCmdjeremy_bennett: so, currently the openrisc-*-* and or32-*-* targets are removed in our or1k-src, are you OK that we are going to upstream that depcrecation?00:12
-!- Netsplit *.net <-> *.split quits: rokka, unknown_lamer08:56
-!- Netsplit over, joins: unknown_lamer09:03
stekernolofk_: I think we should break out some common verilator functionality in a verilator_tb_utils core, do you agree?09:49
stekerncommon verilator testbench functionality, that is09:49
jeremy_bennettblueCmd: It makes a lot of sense just to upstream or1k. I suggest however we keep a legacy branch with or32 still supported. Given the version used by NASA was or32, we might perhaps want to leave that around.10:39
jeremy_bennettBTW - we should have some resource to commit to GCC development later this year.10:40
stekernjeremy_bennett: the question was, what to do with the or32 and openrisc stuff that's upstream10:46
jeremy_bennettstekern: Ah - should have read the back discussion properly. I agree - blow it away. or1k is the correct naming for the architecture.11:15
blueCmdjeremy_bennett: ack, thanks11:50
blueCmd11300 deletions11:51
blueCmdstekern: or1knd isn't in config.guess / config.sub, that might be good to add11:52
blueCmdolofk_: - the removal patches are split up and tested12:30
blueCmdi haven't tested on 32 bit, but since they are removals I'm thinking it should matter much12:31
blueCmdstekern: or1knd, default to -linux or -elf?13:44
blueCmd-linux I would say13:44
stekernI think -elf, it's not really usable under linux (yet)14:22
stekernpeter might have a better idea about it though14:23
blueCmdstekern: yeah, i defaulted it to elf14:51
blueCmdor1k was default elf14:51
blueCmdolofk_: tadaa16:16
blueCmdolofk_: I think we only need the names of all contributors and we're good to go16:28
jeremy_bennettblueCmd: stekern: How do you mean "default to -elf"? Surely these are two different tool chains, one for bare metal, one for Linux applications.16:42
blueCmdjeremy_bennett: 'default' means if you do --target=or1k16:45
jeremy_bennettblueCmd: Eek - recipe for disater.16:45
blueCmdjeremy_bennett: yes, but I have to set a default for that16:46
blueCmdor, well - everybody else sets a default16:46
jeremy_bennettI'm not sure it would even be accepted upstream. It's OK for AVR (since there is only one tool chain). The user really ought to know and decide what they are using.16:46
jeremy_bennettI don't think it is true for many architectures. Although the architecture may be named generically, the later matches generally insist on at least an OS when there is a choice.16:48
jeremy_bennettSo our matches should be or1k-*-linux and or1k-*-elf16:49
jeremy_bennett(or if you prefer or1k-*-linux-uclibc to allow for the people working on glibc/eglibc).16:49
blueCmdjeremy_bennett: that default is already accepted for or1k, but I agree that it makes sense to make it explicit16:49
blueCmdjeremy_bennett: what about mapping it to or1k-unknown-none ?16:51
blueCmdsome arch does that16:51
blueCmdjeremy_bennett: does that make sense?16:56
jeremy_bennettI recommend not mapping it. The earlier the user sees their error the better.16:56
blueCmdjeremy_bennett: not mapping it turns it into -none by default16:57
blueCmdjeremy_bennett: or32 has -coff as default, or1k has had -elf for around a year (but it should be safe to change)16:57
blueCmdjeremy_bennett: I would have to add exit 1 in config.sub for that, it's probably OK to do that but that would make or1k the first to do so16:58
jeremy_bennettblueCmd: In that case I guess or1k-unknown-none is best. That way things will break if the user doesn't specify things.16:59
jeremy_bennettI think the or32-coff is really ancient - dates back to 1999.16:59
jeremy_bennettWe've been ELF for a long time.16:59
olofk_stekern: Yes, we should absolutely try to share much of the verilator helper stuff between cores. With _franck_'s excellent patch we can start working on that now18:28
olofk_blueCmd: Awesome work. Sorry I've forgotten about the contributors. I'll dig up the list straight away18:31
olofk_blueCmd: And I don't think anyone would mind if you were mentoring the GSoC project, and feel free to ask for help if there are hw-related stuff you're not certain about18:32
blueCmdolofk_: i was talking about maintaining the binutils port :P18:33
blueCmdolofk_: but I have actually been thinking about mentoring that GSoC thing as well18:33
olofk_blueCmd: Oh... sorry. Well, I don't mind having you maintain the binutils port either18:34
blueCmdolofk_: btw,
stekernolofk_: yup, and I'll try to split out common parts from your or1200-generic testbench20:09
olofk_stekern: Sounds good20:17
-!- olofk_ is now known as olofk20:18
blueCmdolofk_: assuming that jeremy_bennett and his employees are good on FSF, I'm good and now juliusb_ - we're soon there!20:18
blueCmdthe hurdle would be to get stekern to do it20:18
blueCmdhe never does anything20:18
olofkblueCmd: Yeah I know. Last thing I heard, he tried to steal code from my testbench and put it somewhere else. That guy can't be trusted20:19
_franck_did I work on binutils ??20:28
_franck_olofk: pull request updated20:29
olofk_franck_: Could it have been when you did the gdb updates?20:31
_franck_don't know. I'll try to find my name in it20:32
blueCmd_franck_: gdb is part of this, but we're not submitting GDB this first round20:33
_franck_ah ok that's it20:34
olofk_franck_: Which python version do you use?20:53
olofkI discovered another issue with python 321:04
_franck_I'm installing it right now21:04
olofkThe problem is the change in that I did in 1f2960b6071e7c13492756959239165ee13698d521:06
olofkIt looks for a dictionary with the same name as the simulator in the Core file21:06
olofkProblem is that while icarus and modelsim are onÃly dictionaries, verilator is now a proper object21:07
olofkso core.modelsim['depend'] works fine, but not core.verilator['depend']21:07
olofkI knew that my change in coremanager was a bit ugly, because it required depend to be a dictionary entry21:09
olofkSo I say that the correct fix is to make real classes for modelsim and icarus as well, and let them contain a variable called depend21:10
olofkbtw, I couldn't see that your new looks for the depend option when it parses the .core file21:11
olofk_franck_: I'm starting to think that we should split up your patch anyway. Adding the capi documentation and the improved handling of LDFLAGS and lib grouping for verilator would be nice to have first21:13
_franck_yeah sure. I think it doesn't have depend because it wasn't merge at that time21:13
olofkah ok21:13
stekerndid you guys test my add-on to that patch? did it brake your machines in subtle ways?21:14
_franck_no I stole it and put it in my patch and still work here21:14
stekernok, great!21:15
_franck_olofk: you want to update the CAPI doc before update the code ?21:18
olofk_franck_: Yeah, I think that's ok.21:20
_franck_I think I'll add features without introduce a new verilator class first21:22
olofk_franck_: When I saw your patch I realized that I want to do some refactoring in the core section handling first21:22
olofkEvery section will be a real class (like your new, but they will all inherit from a Section base class so most of the code can be shared21:23
olofkWe can probably even do Section -> ToolSection -> ModelsimSection, and add self.depend in ToolSection so that all tools automatically can use specific dependencies21:25
olofkAnd with multiple inheritance ModelsimSection could inherit from ToolSection, VerilogSection and VhdlSection21:25
olofkMan... this is some crazy object oriented shit going on here21:26
_franck_hopefully I just read some Python doc (because I need to start learn it :))21:26
_franck_I kind of like Python now21:27
olofkPython is fun!21:28
blueCmdolofk: OOP in python isn't the best though. it's hard to create sensible interfaces and make it clear what is virtual and what is not21:37
olofkblueCmd: I do miss proper interfaces from java21:38
olofkAnd making stuff private21:38
blueCmdwe use _ as the first character to say 'its private' and have the linter complain if we access it from outside the class21:40
blueCmdbut yes, interfaces are messy21:40
olofkSame here, except for the linter, so I don't know if anyone is fiddling with stuff they shouldn't touch :)21:40
olofkBut you can get reasonable support for both private stuff and interfaces with @decorators, right? Haven't really figured out how that works, but I think I have read it somewhere21:41
olofkI love python decorators. Like all other magic stuff, I don't really have a clue what it does or how it works21:42
olofkA bit like fax machines. That's some serious black magic21:42
_franck_olofk: you have a pull request :) Sorry if I give you some work21:46
blueCmdolofk: sure, but it's an afterthought and a hack :(21:46
olofk_franck_: Hurray! I love pull requests. It makes fusesoc feel like a real project :)21:47
blueCmdolofk: decorators are very simple actually. when you add a decorator you actually call a function that takes the function as an argument and returns the new function.21:47
olofkOh yeah... it's like a wrapper function21:48
blueCmd yes21:48
olofkI want to use that in fusesoc. It will make the code look really cool21:48
stekernolofk: yeah, that's the reason to use it, to make the code look cool22:20
olofkstekern: Top priority :)22:24
stekernagree, I usually stand in front of the mirror, practicing writing cool code22:25
stekerndecorators doesn't sound that cool though, not like destructors!22:27
olofkyeah... I guess you're right22:28
olofkHmm... are there any destructors at all in python?22:28
olofkOtherwise I might need to rewrite it in c++ or java22:28
blueCmdolofk: pgavin:
--- Log closed Sun Mar 09 00:00:12 2014

Generated by 2.15.2 by Marius Gedminas - find it at!