IRC logs for #openrisc Saturday, 2014-02-15

--- Log opened Sat Feb 15 00:00:36 2014
--- Day changed Sat Feb 15 2014
poke53281sorry, I mean libffi00:00
poke532812020 ..... force Intel to build an OpenRISC ASIC.00:01
stekernwonder if INtel sstill exists 2020...00:05
poke53281hehe. As long as they are building the fastest CPU of the world I don't see why not.00:07
poke53281Yes, 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
stekerneah, but is that a niche strong enough to be able to survive00:11
poke53281Yes, of course. I am talking about the whole community doing simulations. Think how many engineers doing simulations nowadays.00:13
stekernoh, I got that, it's probably a pretty large "niche"00:22
wkoszekQEMU is more mainstream, more people know it, and gives the project more exposure00:23
wkoszekIt's also more supported and must be as correct as or1ksim, since it must also get qualified somehow, e.g.: boot Linux.00:23
stekernbut, 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 areas00:24
stekernwkoszek: I agree on the first, it might be easier to attract outsiders to work on qemu00:25
stekernin the end, we'll want to have the support in both00:26
stekernif you ask me which one I trust more to be correct, or1ksim or qemu? or1ksim00:28
stekernbut poke53281's patches have made qemu better00:28
wkoszekIs there any suite of ISA unit tests which you can use for proving which one is more correct?00:29
stekernthere 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 or120000:30
poke53281Yes, 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
stekernthat's something we are working on, but it's making slow progress00:31
poke53281QEMU without my patches is less accurate then jor1k.00:36
poke53281But with accuracy problems in QEMU I mean bugs mainly.00:37
poke53281Those are my patches00:39
wkoszekblueCmd: So the OpenRISC thing you showed me yesterday  -- this is formal application?00:43
wkoszekNothing else has to be done?00:43
wkoszekpoke53281, stekern If you guys can edit Wiki, I'd add 64-bit idea00:44
wkoszekIf it's QEMU, I can co-mentor this stuff.00:44
wkoszekI'm not interested in or1ksim00:44
stekernI think anyone can edit the wiki00:44
wkoszekI didn't get 'password reset' e-mail from opencores yesterday and it's not arriving today00:46
olofkLots of good discussions08:03
rahhow different would a mobile version of or1k be to the current version?08:50
rahor, how much work would it take to create an or1k core intended for use in mobile devices?08:51
rahthat is, with ultra low power requirements?08:52
rahwould it require a completely new design?09:10
blueCmdpoke53281: cool, im doing a lot of patching for or1k support in debian packages. so it should become easier and easier10:53
-!- hno` is now known as hno18:57
olofkpgavin: Hi!19:43
pgavinback, stepped away for a bit19:57
pgavinso my core has a branch predictor and I'm thinking about whether there should be SPRs for invalidating entries in it19:59
olofkYou're most welcome back19:59
pgavinsimilar to the ICBIR register19:59
pgavin(I'm working on a core with no delay slot)19:59
pgavinalso I was wondering what happens if the CBIRI bits aren't set in the DCCFGR20:01
pgavinor ICCFGR20:01
pgavindoes that mean it uses hardware flush?20:01
pgavinis that a valid thing to do?20:01
pgavinone problem with the branch predictor is that there are 2 tables, the BPB and the BTB, but really only the BTB needs to be invalidated20:03
pgavinif the BPB isn't invalidated it will just generate random predictions initially20:03
olofkrah: 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 done20:47
olofkProbably a lot of micro optimizations to decrease the switching in unused parts of the CPU20:49
olofkstekern: 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 lm3220:57
ysionneaulm32 is in-order, fully bypassed, 6 stages pipeline, with write through caches only (caches optional and configurable)21:22
ysionneaummu is experimental and not software proven yet, and tlb is software assisted so very not efficient (no hardware page tree walker)21:23
ysionneaubut I don't have benchmark comparisons , sorry ^^21:24
raholofk: ok thanks23:43
--- Log closed Sun Feb 16 00:00:41 2014

Generated by 2.15.2 by Marius Gedminas - find it at!