| --- Log opened Sat Mar 08 00:00:11 2014 | ||
| blueCmd | jeremy_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 |
|---|---|---|
| blueCmd | deprecation* | 00:12 |
| -!- Netsplit *.net <-> *.split quits: rokka, unknown_lamer | 08:56 | |
| -!- Netsplit over, joins: unknown_lamer | 09:03 | |
| stekern | olofk_: I think we should break out some common verilator functionality in a verilator_tb_utils core, do you agree? | 09:49 |
| stekern | common verilator testbench functionality, that is | 09:49 |
| jeremy_bennett | blueCmd: 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_bennett | BTW - we should have some resource to commit to GCC development later this year. | 10:40 |
| stekern | jeremy_bennett: the question was, what to do with the or32 and openrisc stuff that's upstream | 10:46 |
| jeremy_bennett | stekern: Ah - should have read the back discussion properly. I agree - blow it away. or1k is the correct naming for the architecture. | 11:15 |
| blueCmd | jeremy_bennett: ack, thanks | 11:50 |
| blueCmd | 11300 deletions | 11:51 |
| blueCmd | stekern: or1knd isn't in config.guess / config.sub, that might be good to add | 11:52 |
| stekern | mmm | 12:07 |
| blueCmd | olofk_: http://openrisc.net/debian/patches/binutils-gdb/ - the removal patches are split up and tested | 12:30 |
| blueCmd | i haven't tested on 32 bit, but since they are removals I'm thinking it should matter much | 12:31 |
| blueCmd | stekern: or1knd, default to -linux or -elf? | 13:44 |
| blueCmd | -linux I would say | 13:44 |
| stekern | I think -elf, it's not really usable under linux (yet) | 14:22 |
| stekern | peter might have a better idea about it though | 14:23 |
| blueCmd | stekern: yeah, i defaulted it to elf | 14:51 |
| blueCmd | or1k was default elf | 14:51 |
| blueCmd | olofk_: http://openrisc.net/debian/patches/binutils-gdb/ tadaa | 16:16 |
| blueCmd | olofk_: I think we only need the names of all contributors and we're good to go | 16:28 |
| jeremy_bennett | blueCmd: 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 |
| blueCmd | jeremy_bennett: 'default' means if you do --target=or1k | 16:45 |
| jeremy_bennett | blueCmd: Eek - recipe for disater. | 16:45 |
| blueCmd | jeremy_bennett: yes, but I have to set a default for that | 16:46 |
| blueCmd | or, well - everybody else sets a default | 16:46 |
| jeremy_bennett | I'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_bennett | I 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_bennett | So our matches should be or1k-*-linux and or1k-*-elf | 16:49 |
| jeremy_bennett | (or if you prefer or1k-*-linux-uclibc to allow for the people working on glibc/eglibc). | 16:49 |
| blueCmd | jeremy_bennett: that default is already accepted for or1k, but I agree that it makes sense to make it explicit | 16:49 |
| blueCmd | jeremy_bennett: what about mapping it to or1k-unknown-none ? | 16:51 |
| blueCmd | some arch does that | 16:51 |
| blueCmd | bfin | 16:51 |
| blueCmd | jeremy_bennett: http://pastebin.com/h30uMwpx does that make sense? | 16:56 |
| jeremy_bennett | I recommend not mapping it. The earlier the user sees their error the better. | 16:56 |
| blueCmd | jeremy_bennett: not mapping it turns it into -none by default | 16:57 |
| blueCmd | jeremy_bennett: or32 has -coff as default, or1k has had -elf for around a year (but it should be safe to change) | 16:57 |
| blueCmd | jeremy_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 so | 16:58 |
| jeremy_bennett | blueCmd: 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_bennett | I think the or32-coff is really ancient - dates back to 1999. | 16:59 |
| jeremy_bennett | We've been ELF for a long time. | 16:59 |
| blueCmd | yes | 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 now | 18:28 |
| olofk_ | blueCmd: Awesome work. Sorry I've forgotten about the contributors. I'll dig up the list straight away | 18: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 about | 18:32 |
| blueCmd | olofk_: i was talking about maintaining the binutils port :P | 18:33 |
| blueCmd | olofk_: but I have actually been thinking about mentoring that GSoC thing as well | 18:33 |
| olofk_ | blueCmd: Oh... sorry. Well, I don't mind having you maintain the binutils port either | 18:34 |
| blueCmd | olofk_: btw, https://sourceware.org/ml/cgen-cvs/2001/msg00000.html | 18:42 |
| stekern | olofk_: yup, and I'll try to split out common parts from your or1200-generic testbench | 20:09 |
| olofk_ | stekern: Sounds good | 20:17 |
| -!- olofk_ is now known as olofk | 20:18 | |
| blueCmd | olofk_: assuming that jeremy_bennett and his employees are good on FSF, I'm good and now juliusb_ - we're soon there! | 20:18 |
| blueCmd | the hurdle would be to get stekern to do it | 20:18 |
| blueCmd | he never does anything | 20:18 |
| blueCmd | ;) | 20:18 |
| olofk | blueCmd: 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 trusted | 20:19 |
| blueCmd | clearly | 20:19 |
| stekern | haha | 20:20 |
| _franck_ | did I work on binutils ?? | 20:28 |
| _franck_ | olofk: pull request updated | 20:29 |
| olofk | _franck_: | 20:30 |
| 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 it | 20:32 |
| blueCmd | _franck_: gdb is part of this, but we're not submitting GDB this first round | 20:33 |
| _franck_ | ah ok that's it | 20:34 |
| olofk | _franck_: Which python version do you use? | 20:53 |
| _franck_ | 2.7 | 21:00 |
| olofk | I discovered another issue with python 3 | 21:04 |
| _franck_ | I'm installing it right now | 21:04 |
| olofk | The problem is the change in coremanager.py that I did in 1f2960b6071e7c13492756959239165ee13698d5 | 21:06 |
| olofk | It looks for a dictionary with the same name as the simulator in the Core file | 21:06 |
| olofk | Problem is that while icarus and modelsim are onÃly dictionaries, verilator is now a proper object | 21:07 |
| olofk | so core.modelsim['depend'] works fine, but not core.verilator['depend'] | 21:07 |
| olofk | I knew that my change in coremanager was a bit ugly, because it required depend to be a dictionary entry | 21:09 |
| olofk | So I say that the correct fix is to make real classes for modelsim and icarus as well, and let them contain a variable called depend | 21:10 |
| olofk | btw, I couldn't see that your new verilator.py looks for the depend option when it parses the .core file | 21: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 first | 21:13 |
| _franck_ | yeah sure. I think it doesn't have depend because it wasn't merge at that time | 21:13 |
| olofk | ah ok | 21:13 |
| stekern | did you guys test my add-on to that patch? did it brake your machines in subtle ways? | 21:14 |
| olofk | ? | 21:14 |
| _franck_ | no I stole it and put it in my patch and still work here | 21:14 |
| stekern | ok, great! | 21:15 |
| _franck_ | https://github.com/fjullien/fusesoc/blob/verilator_improvement/fusesoc/simulator/verilator.py#L58 | 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 first | 21:22 |
| olofk | _franck_: When I saw your patch I realized that I want to do some refactoring in the core section handling first | 21:22 |
| olofk | Every section will be a real class (like your new verilator.py), but they will all inherit from a Section base class so most of the code can be shared | 21:23 |
| olofk | We can probably even do Section -> ToolSection -> ModelsimSection, and add self.depend in ToolSection so that all tools automatically can use specific dependencies | 21:25 |
| olofk | And with multiple inheritance ModelsimSection could inherit from ToolSection, VerilogSection and VhdlSection | 21:25 |
| olofk | Man... this is some crazy object oriented shit going on here | 21:26 |
| _franck_ | hopefully I just read some Python doc (because I need to start learn it :)) | 21:26 |
| _franck_ | I kind of like Python now | 21:27 |
| olofk | Python is fun! | 21:28 |
| blueCmd | olofk: 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 not | 21:37 |
| olofk | blueCmd: I do miss proper interfaces from java | 21:38 |
| olofk | And making stuff private | 21:38 |
| blueCmd | we use _ as the first character to say 'its private' and have the linter complain if we access it from outside the class | 21:40 |
| blueCmd | but yes, interfaces are messy | 21:40 |
| olofk | Same here, except for the linter, so I don't know if anyone is fiddling with stuff they shouldn't touch :) | 21:40 |
| olofk | But 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 somewhere | 21:41 |
| olofk | I love python decorators. Like all other magic stuff, I don't really have a clue what it does or how it works | 21:42 |
| olofk | A bit like fax machines. That's some serious black magic | 21:42 |
| _franck_ | olofk: you have a pull request :) Sorry if I give you some work | 21:46 |
| blueCmd | olofk: 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 |
| blueCmd | olofk: 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 |
| olofk | Oh yeah... it's like a wrapper function | 21:48 |
| blueCmd | yes | 21:48 |
| olofk | I want to use that in fusesoc. It will make the code look really cool | 21:48 |
| stekern | olofk: yeah, that's the reason to use it, to make the code look cool | 22:20 |
| stekern | =) | 22:20 |
| olofk | stekern: Top priority :) | 22:24 |
| stekern | agree, I usually stand in front of the mirror, practicing writing cool code | 22:25 |
| olofk | lol | 22:25 |
| stekern | decorators doesn't sound that cool though, not like destructors! | 22:27 |
| olofk | yeah... I guess you're right | 22:28 |
| olofk | Hmm... are there any destructors at all in python? | 22:28 |
| olofk | Otherwise I might need to rewrite it in c++ or java | 22:28 |
| blueCmd | olofk: pgavin: http://openrisc.net/debian/patches/gcc/ | 22:32 |
| --- Log closed Sun Mar 09 00:00:12 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!