Re: [gem5-dev] Review Request: Cache: Remove redundant check for uncacheable snoops

> On May 20, 2012, 7:54 a.m., Ali Saidi wrote: > > src/mem/cache/cache_impl.hh, line 1267 > > > > > > Seems fine for the normal case, but if you hookde two caches up > > directly, would this break? > > > > > > Andrea

Re: [gem5-dev] Review Request: DMA: Split the DMA device and IO device into seperate files

> On May 20, 2012, 7:58 a.m., Ali Saidi wrote: > > src/dev/Device.py, line 45 > > > > > > This doesn't seem like it adds any value > > Andreas Hansson wrote: > I am a bit unsure what "this" refers to. The DmaDevice is mo

Re: [gem5-dev] Review Request: Config: Exit with fatal if a port is already connected

> On May 20, 2012, 7:57 a.m., Ali Saidi wrote: > > hmm.. do we want to do it this way, or fix the issue? It seems like there > > may be value in allowing the configuration to change before it's > > instantiated (e.g create a perfectly workable system with only l1s and the > > later on decide y

Re: [gem5-dev] Review Request: CPU: Merge the predecoder and decoder.

On Mon, May 21, 2012 at 3:48 AM, Gabe Black wrote: > I'll move over to email since this is turning into a discussion more than > review feedback. It's not the first thing on my agenda, but fairly high up > is going to be simplifying this interface at least a little bit. I did some > grepping, an

Re: [gem5-dev] Review Request: Packet: Cleaning up packet command and attribute

I'd prefer to leave it in there since we know we should be using it. If you'd like, feel free to add a comment that it's currently unused but should be put to use for this purpose. I think that's better than having no documentation that this needs to be fixed. Steve On Mon, May 21, 2012 at 10:1

Re: [gem5-dev] Review Request: regression tester: Fix some bugs in simple-timing-mp-ruby.py.

On Mon, 21 May 2012, Marc Orr wrote: Your suggestion is orthogonal to this patch - right? Yes. -- Nilay ___ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request: Config: Make disk-image option support mutiple disks

I know that accessing the host file system which will preserve determinism is difficult. With GEMS (I should say simics), all the files were copied to the local FS, then all the stats were reset and all the experiments were run. Because of it, even though the copy from host FS to local FS was r

Re: [gem5-dev] Review Request: Packet: Cleaning up packet command and attribute

> On May 8, 2012, 9:06 a.m., Ali Saidi wrote: > > src/mem/packet.hh, line 94 > > > > > > hrm.. I think we probably want to do full block writes with > > writeinvrequest. > > Andreas Hansson wrote: > I am perfectly fine

Re: [gem5-dev] Review Request: CPU: Merge the predecoder and decoder.

I'll move over to email since this is turning into a discussion more than review feedback. It's not the first thing on my agenda, but fairly high up is going to be simplifying this interface at least a little bit. I did some grepping, and I think the only place getExtMachInst is used is in the chec

Re: [gem5-dev] Review Request: Cache: Remove redundant check for uncacheable snoops

> On May 20, 2012, 7:54 a.m., Ali Saidi wrote: > > src/mem/cache/cache_impl.hh, line 1267 > > > > > > Seems fine for the normal case, but if you hookde two caches up > > directly, would this break? > > > > Very valid

Re: [gem5-dev] Review Request: DMA: Split the DMA device and IO device into seperate files

> On May 20, 2012, 7:58 a.m., Ali Saidi wrote: > > src/dev/Device.py, line 45 > > > > > > This doesn't seem like it adds any value I am a bit unsure what "this" refers to. The DmaDevice is moved to DmaDevice.py - Andreas

[gem5-dev] Cron /z/m5/regression/do-regression quick

* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing FAILED! * build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp FAILED! * build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic FAILED! * build/ALPHA/tests/opt/quick/se/30.eio-mp/alp

Re: [gem5-dev] Review Request: Config: Exit with fatal if a port is already connected

> On May 20, 2012, 7:57 a.m., Ali Saidi wrote: > > hmm.. do we want to do it this way, or fix the issue? It seems like there > > may be value in allowing the configuration to change before it's > > instantiated (e.g create a perfectly workable system with only l1s and the > > later on decide y