Re: [gem5-dev] Review Request 2861: sim: Refactor the serialization base class

> On July 4, 2015, 12:15 p.m., Steve Reinhardt wrote: > > src/sim/serialize.hh, line 337 > > > > > > Is there a plan in place to change the objects that use this? If not > > (i.e., if there's a legitimate need for some obje

Re: [gem5-dev] Review Request 2871: python: Remove redundant drain when changing memory modes

--- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2871/#review6712 --- Ship it! - Steve Reinhardt On June 8, 2015, 4:32 a.m., Andreas Sandber

Re: [gem5-dev] Review Request 2874: sim: Decouple draining from the SimObject hierarchy

> On July 4, 2015, 11:57 a.m., Steve Reinhardt wrote: > > So I think the Drainable class is a great idea, it's nice not to pollute > > random SimObjects with code that forces them to track what sub-objects of > > theirs need to be drained. > > > > I'm less convinced about the benefits of irrev

Re: [gem5-dev] Device endianness handling

Good points. I'm fine with deprecating the plain get()/set(); while their semantics is potentially useful, it shouldn't be the "default". getGE/setGE would be fine, though now that I think about it, we could also just switch to getLE/setLE, as the benefit of working with a big-endian architecture

[gem5-dev] changeset in gem5: stats: x86: update stats missed out on in pre...

changeset 8cfa8dac39fe in /z/repo/gem5 details: http://repo.gem5.org/gem5?cmd=changeset;node=8cfa8dac39fe description: stats: x86: update stats missed out on in preivous changeset diffstat: tests/long/fs/10.linux-boot/ref/x86/linux/pc-o3-timing/config.ini |92 +-

[gem5-dev] Cron /z/m5/regression/do-regression --scratch all

* build/X86/tests/opt/long/se/20.parser/x86/linux/o3-timing CHANGED! scons: *** Error 1 * build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA/tests/opt/long/fs/10.linux-boot/alpha/linux/tsunami-minor passed. * build/ALPHA/tests/opt/quick/se/50.vortex

Re: [gem5-dev] Device endianness handling

I my original proposal actually contained getGE()/setGE() that use the guest endianness. I decided to scrap them since we don¹t really have any devices using them. I can add them back into the patch I¹m intending to post tomorrow. Another option for devices that want to use the same endianness as

Re: [gem5-dev] Review Request 2874: sim: Decouple draining from the SimObject hierarchy

> On July 4, 2015, 7:57 p.m., Steve Reinhardt wrote: > > So I think the Drainable class is a great idea, it's nice not to pollute > > random SimObjects with code that forces them to track what sub-objects of > > theirs need to be drained. > > > > I'm less convinced about the benefits of irreve

Re: [gem5-dev] Device endianness handling

This was an annoyance for me many years ago as well. The thing is, memory doesn't have an endianness. It's just a bag of bytes. It's CPUs and devices that have endianness and they should be doing whatever swizzling is necessary when reading/writing from memory. I had always wanted devices to do

Re: [gem5-dev] Review Request 2861: sim: Refactor the serialization base class

> On July 4, 2015, 8:15 p.m., Steve Reinhardt wrote: > > src/sim/serialize.hh, line 337 > > > > > > Is there a plan in place to change the objects that use this? If not > > (i.e., if there's a legitimate need for some objec

Re: [gem5-dev] Review Request 2871: python: Remove redundant drain when changing memory modes

> On July 4, 2015, 6:32 p.m., Steve Reinhardt wrote: > > So is the assumption here that, if you're switching memory modes, you will > > always call switchCpus with do_drain=True? Other than that I don't see > > where the redundant drain is coming from. > > > > Also, if the system is already dr