| --- Log opened Sat Feb 15 00:00:36 2014 | ||
| --- Day changed Sat Feb 15 2014 | ||
| poke53281 | sorry, I mean libffi | 00:00 |
|---|---|---|
| poke53281 | 2020 ..... force Intel to build an OpenRISC ASIC. | 00:01 |
| stekern | wonder if INtel sstill exists 2020... | 00:05 |
| poke53281 | hehe. As long as they are building the fastest CPU of the world I don't see why not. | 00:07 |
| poke53281 | Yes, the mobile market will be strong and Intel might have no market share in this segment. But I won't accept to do my Quantum mechanics simulations in future on my mobile. | 00:09 |
| stekern | eah, but is that a niche strong enough to be able to survive | 00:11 |
| stekern | +y | 00:12 |
| poke53281 | Yes, of course. I am talking about the whole community doing simulations. Think how many engineers doing simulations nowadays. | 00:13 |
| stekern | oh, I got that, it's probably a pretty large "niche" | 00:22 |
| wkoszek | QEMU is more mainstream, more people know it, and gives the project more exposure | 00:23 |
| wkoszek | It's also more supported and must be as correct as or1ksim, since it must also get qualified somehow, e.g.: boot Linux. | 00:23 |
| stekern | but, regardless a "niche", intels popularity there is because they are fast *and* cheap, and they have been able to be cheap because they have a large market share in other areas | 00:24 |
| stekern | wkoszek: I agree on the first, it might be easier to attract outsiders to work on qemu | 00:25 |
| stekern | in the end, we'll want to have the support in both | 00:26 |
| stekern | if you ask me which one I trust more to be correct, or1ksim or qemu? or1ksim | 00:28 |
| wkoszek | OK. | 00:28 |
| stekern | but poke53281's patches have made qemu better | 00:28 |
| wkoszek | Is there any suite of ISA unit tests which you can use for proving which one is more correct? | 00:29 |
| stekern | there is a suite of tests in or1ksim, a suite of tests in qemu, and then we have a set of tests in mor1kx and a (similar, but smaller) set for or1200 | 00:30 |
| poke53281 | Yes, or1ksim is more accurate at the moment. jor1k is completely speed optimized and is not fully compliant, but enough to run Linux. QEMU with patches should be good as well. | 00:30 |
| stekern | ...there's another gsoc project, consolidate our ISA tests ;) | 00:30 |
| stekern | that's something we are working on, but it's making slow progress | 00:31 |
| poke53281 | QEMU without my patches is less accurate then jor1k. | 00:36 |
| poke53281 | But with accuracy problems in QEMU I mean bugs mainly. | 00:37 |
| poke53281 | https://github.com/s-macke/qemu/commits/or32-optimize | 00:39 |
| poke53281 | Those are my patches | 00:39 |
| wkoszek | blueCmd: So the OpenRISC thing you showed me yesterday -- this is formal application? | 00:43 |
| wkoszek | Nothing else has to be done? | 00:43 |
| wkoszek | poke53281, stekern If you guys can edit Wiki, I'd add 64-bit idea | 00:44 |
| wkoszek | If it's QEMU, I can co-mentor this stuff. | 00:44 |
| wkoszek | I'm not interested in or1ksim | 00:44 |
| stekern | I think anyone can edit the wiki | 00:44 |
| wkoszek | I didn't get 'password reset' e-mail from opencores yesterday and it's not arriving today | 00:46 |
| olofk | Lots of good discussions | 08:03 |
| rah | how different would a mobile version of or1k be to the current version? | 08:50 |
| rah | or, how much work would it take to create an or1k core intended for use in mobile devices? | 08:51 |
| rah | that is, with ultra low power requirements? | 08:52 |
| rah | would it require a completely new design? | 09:10 |
| blueCmd | poke53281: cool, im doing a lot of patching for or1k support in debian packages. so it should become easier and easier | 10:53 |
| -!- hno` is now known as hno | 18:57 | |
| pgavin | hello | 19:38 |
| olofk | pgavin: Hi! | 19:43 |
| pgavin | back, stepped away for a bit | 19:57 |
| pgavin | so my core has a branch predictor and I'm thinking about whether there should be SPRs for invalidating entries in it | 19:59 |
| olofk | You're most welcome back | 19:59 |
| pgavin | similar to the ICBIR register | 19:59 |
| pgavin | (I'm working on a core with no delay slot) | 19:59 |
| pgavin | also I was wondering what happens if the CBIRI bits aren't set in the DCCFGR | 20:01 |
| pgavin | or ICCFGR | 20:01 |
| pgavin | does that mean it uses hardware flush? | 20:01 |
| pgavin | is that a valid thing to do? | 20:01 |
| pgavin | one problem with the branch predictor is that there are 2 tables, the BPB and the BTB, but really only the BTB needs to be invalidated | 20:03 |
| pgavin | if the BPB isn't invalidated it will just generate random predictions initially | 20:03 |
| olofk | rah: Good question. I would guess that a mobile version would need at least a proper power management unit, but I don't know what else that needs to be done | 20:47 |
| olofk | Probably a lot of micro optimizations to decrease the switching in unused parts of the CPU | 20:49 |
| olofk | stekern: You have played a bit with lm32, right? In the light of Sebastien's comment on the ML, I'm curious to know how mor1kx compares to lm32 | 20:57 |
| ysionneau | lm32 is in-order, fully bypassed, 6 stages pipeline, with write through caches only (caches optional and configurable) | 21:22 |
| ysionneau | mmu is experimental and not software proven yet, and tlb is software assisted so very not efficient (no hardware page tree walker) | 21:23 |
| ysionneau | but I don't have benchmark comparisons , sorry ^^ | 21:24 |
| rah | olofk: ok thanks | 23:43 |
| --- Log closed Sun Feb 16 00:00:41 2014 | ||
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!