Re: [m5-dev] Review Request: ARM: Mark prefetches as such and allow timing CPU to handle them.

[Ali Saidi]

On Oct 19, 2010, at 11:14 PM, Ali Saidi wrote:

> 
> 
>> On 2010-10-09 13:38:40, Gabe Black wrote:
>>> src/cpu/simple/timing.cc, line 765
>>> 
>>> 
>>>Prefetch faults should ideally be surpressed at their source, not here. 
>>> At the source we already implicitly know the instruction shouldn't fault. 
>>> Here, we have to rediscover that all the time.
>> 
>> Ali Saidi wrote:
>>I don't agree. If you suppress this at the source the CPU model doesn't 
>> know if it should actually try and issue the instruction, so that would have 
>> to be checked some how. Additionally, in most cases there is one or two 
>> place in the TLB that a correct translation is returned and as many places 
>> where a fault is returned. Checking there would complication all of the code 
>> paths.
>> 
>> Steve Reinhardt wrote:
>>I don't follow your argument... shouldn't the prefetch get issued 
>> unconditionally?  If it doesn't have a valid translation then you don't want 
>> to send it to the cache, but the instruction itself still gets executed.
>> 
>>As far as implementing this, seems like there could be just one or two 
>> places after the TLB translation is returned where we override the fault if 
>> it's a prefetch, rather than pushing the override into the TLB itself.
>> 
> 
> I think the prefetch should be sent the the TLB unconditionally, and then if 
> the prefetch faults the CPU should toss the instruction rather than the TLB 
> returning no fault and the CPU i guess checking if the PA is set? 
> 
> I agree that we should override the fault in the CPU. Are we violently 
> agreeing?


bump... bump...
Ali

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] delayed translation in O3

[Ali Saidi]

On Oct 21, 2010, at 9:11 AM, nathan binkert wrote:

>> FS... I'm not really up for rebasing much, so we need to get the prefetch 
>> stuff handled and then I can get the latest set in and next on the list is 
>> the o3 stuff.
> 
> You can of course commit separately and then flip a coin to see who merges.

Yes, but I would also like to not waste time solving the exact same problem 
someone else is going to solve... coordination is key.

Ali

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

[Brad Beckmann]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/#review399
---


I think Steve covered most of the main points.  Please see my detailed comment 
below about when I think line numbers and function names are useful.

Brad


src/mem/protocol/RubySlicc_MemControl.sm


I'll beat Nate to this.  :)  Try to avoid inserting and deleting random 
lines in files.  It cluters the diff and unecessarily makes merging harder.



src/mem/ruby/common/DataBlock.hh


Spacing is off.  Are you using mistakingly using tabs?



src/mem/ruby/common/Debug.hh


I agree with Steve's point that adding "__PRETTY_FUNCTION__, __FILE__, 
__LINE__" to every Ruby DPRINTF call is too cumbersome and we either need to 
remove it or define a macro that does it automatically.  Nilay, I think I might 
have confused you during our previous email conversations.  We definitely want 
to automatically include the function name, file, and line number for the 
SLICC/.sm debug statements...I've found that feature very useful in the past.  
However, I'm not sure we need it for the debug statements on the Ruby side.  
Nilay, if I understand your changes to SLICC correctly and recall from our 
previous conversations on this topic, these old ruby DEBUG macros relied on the 
ostream operator<< overloading, correct? That is why you now have the 
conditional statements in the SLICC that generate the correct DPRINTF line 
depending on the type.  Am I understanding the issues correctly?  If so, I 
think your solution for the SLICC generation of DPRINTF statements looks g
 ood.  I just think that we need to clean up the Ruby DPRINTF statements.




src/mem/ruby/common/NetDest.hh


Spacing again.



src/mem/slicc/ast/FuncCallExprAST.py


See long comment above.


- Brad


On 2010-10-19 17:30:48, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/277/
> ---
> 
> (Updated 2010-10-19 17:30:48)
> 
> 
> Review request for Default and Ruby Reviewers.
> 
> 
> Summary
> ---
> 
> Ruby currently uses GEMS debug support with the enum character string map to 
> enable certain debug messages.  Meanwhile, M5 has debug print support that 
> works with scons. Compiling the m5.fast binary, the M5 debug statements are 
> removed, but the Ruby ones are not unless RUBY_DEBUG is not defined. This 
> patch moves Ruby to M5's debug print support.
> 
> 
> Diffs
> -
> 
>   src/cpu/testers/rubytest/CheckTable.cc 956ac83b0a58 
>   src/mem/SConscript 956ac83b0a58 
>   src/mem/protocol/MESI_CMP_directory-L1cache.sm 956ac83b0a58 
>   src/mem/protocol/MESI_CMP_directory-L2cache.sm 956ac83b0a58 
>   src/mem/protocol/MESI_CMP_directory-dir.sm 956ac83b0a58 
>   src/mem/protocol/MI_example-cache.sm 956ac83b0a58 
>   src/mem/protocol/MI_example-dir.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_directory-L1cache.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_directory-L2cache.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_directory-dir.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_directory-perfectDir.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_token-L1cache.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_token-L2cache.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_token-dir.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_hammer-cache.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_hammer-dir.sm 956ac83b0a58 
>   src/mem/protocol/RubySlicc_Exports.sm 956ac83b0a58 
>   src/mem/protocol/RubySlicc_MemControl.sm 956ac83b0a58 
>   src/mem/protocol/RubySlicc_Types.sm 956ac83b0a58 
>   src/mem/ruby/SConsopts 956ac83b0a58 
>   src/mem/ruby/buffers/MessageBuffer.cc 956ac83b0a58 
>   src/mem/ruby/common/Address.hh 956ac83b0a58 
>   src/mem/ruby/common/DataBlock.hh 956ac83b0a58 
>   src/mem/ruby/common/Debug.hh 956ac83b0a58 
>   src/mem/ruby/common/Debug.cc 956ac83b0a58 
>   src/mem/ruby/common/NetDest.hh 956ac83b0a58 
>   src/mem/ruby/common/NetDest.cc 956ac83b0a58 
>   src/mem/ruby/network/garnet/fixed-pipeline/NetworkInterface_d.cc 
> 956ac83b0a58 
>   src/mem/ruby/network/garnet/fixed-pipeline/Switch_d.cc 956ac83b0a58 
>   src/mem/ruby/network/garnet/flexible-pipeline/NetworkInterface.cc 
> 956ac83b0a58 
>   src/mem/ruby/network/garnet/flexible-pipeline/Router.cc 956ac83b0a58 
>   src/mem/ruby/network/simple/PerfectSwitch.cc 956ac83b0a58 
>   src/mem/ruby/network/simple/Throttle.cc 956ac83b0a58 
>   src/mem/ruby/network/simple/Topology.cc 956ac83b0a58 
>   src/mem/ruby/slicc_interface/Message.hh 956ac83b0a58 
>   src/mem/rub

Re: [m5-dev] Review Request: Moving Ruby to M5's debug print support

[Steve Reinhardt]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/277/#review398
---



src/cpu/testers/rubytest/CheckTable.cc


These adjacent DPRINTFs should be consolidated into one.  It's more 
efficient (since it's a single check of the trace flag and a single call to 
cprintf), and in this case (and many others) we don't really need the function 
name, file name, and line number printed redundantly.

Also you don't need to use c_str(), cprintf() handles std::string just fine 
(and anything else that supports the '<<' operator, I believe).



src/mem/SConscript


Do we want to define a whole new disjoint set of trace flags just for Ruby? 
 For example, why have RubyCache and Cache both?



src/mem/protocol/MESI_CMP_directory-L1cache.sm


This DPRINTF is broken (and several others like it)... it needs a trace 
flag as the first arg, and "%str" probably isn't the format string you want 
(basically it's just like printf, so you probably mean "%s").



src/mem/protocol/MESI_CMP_directory-L1cache.sm


We should get rid of these commented-out lines, either deleting them if 
they're not needed or just using a trace flag that keeps them turned off unless 
wanted.  That's the point of the trace flags, is so that you don't have to 
comment out debug printfs, but can just turn them on and off dynamically at the 
granularity you want.



src/mem/ruby/buffers/MessageBuffer.cc


Note that DPRINTF automatically prepends the value of name(), so we should 
make sure that works for Ruby so we don't need to explicitly pass 
m_name.c_str() (which I assume is the same or similar).



src/mem/ruby/common/Address.hh


Indentation looks funky on this line.  Are you using tabs?



src/mem/ruby/common/Address.hh


Nate can correct me if I'm wrong, but the cprintf library eventually uses 
'<<' at the bottom, so if we need to define a type-specific output (here and 
with DataBlock below) we should just overload that operator.  In this specific 
case, much of this formatting can be handled in the format string itself as 
"[0x%x, line 0x%x]" and then calling with addr and blockAlign(addr) as 
arguments.




src/mem/ruby/common/Debug.hh


We need to decide how valuable it is to automatically include the function 
name, file, and line number.  If there's a consensus that we should keep it, we 
should add DPRINTF variants to M5 that have this.  If not, we should eliminate 
this info from the Ruby debug messages.  But we shouldn't take a bunch of 
boilerplate that used to be nicely encapsulated in a macro and reproduce it N 
times all over the code.



src/mem/ruby/common/Debug.cc


Code should never just be commented out... if we don't need it any more, 
just delete it.


- Steve


On 2010-10-19 17:30:48, Nilay Vaish wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/277/
> ---
> 
> (Updated 2010-10-19 17:30:48)
> 
> 
> Review request for Default and Ruby Reviewers.
> 
> 
> Summary
> ---
> 
> Ruby currently uses GEMS debug support with the enum character string map to 
> enable certain debug messages.  Meanwhile, M5 has debug print support that 
> works with scons. Compiling the m5.fast binary, the M5 debug statements are 
> removed, but the Ruby ones are not unless RUBY_DEBUG is not defined. This 
> patch moves Ruby to M5's debug print support.
> 
> 
> Diffs
> -
> 
>   src/cpu/testers/rubytest/CheckTable.cc 956ac83b0a58 
>   src/mem/SConscript 956ac83b0a58 
>   src/mem/protocol/MESI_CMP_directory-L1cache.sm 956ac83b0a58 
>   src/mem/protocol/MESI_CMP_directory-L2cache.sm 956ac83b0a58 
>   src/mem/protocol/MESI_CMP_directory-dir.sm 956ac83b0a58 
>   src/mem/protocol/MI_example-cache.sm 956ac83b0a58 
>   src/mem/protocol/MI_example-dir.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_directory-L1cache.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_directory-L2cache.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_directory-dir.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_directory-perfectDir.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_token-L1cache.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_token-L2cache.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_CMP_token-dir.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_hammer-cache.sm 956ac83b0a58 
>   src/mem/protocol/MOESI_hammer-dir.sm 956ac8

Re: [m5-dev] please mark reviews for committed patches as such

[Steve Reinhardt]

When you go to the page for a particular entry you've submitted
there's a dropdown menu that lets you close the entry and mark it
either as submitted or discarded.  I can't be more specific since I
don't have any outstanding reviews to look at myself.

Steve

On Thu, Oct 21, 2010 at 12:55 PM, Gabriel Michael Black
 wrote:
> Yeah, I'd noticed that too but I wasn't sure what to do about it. I'll take
> care of mine tonight.
>
> Gabe
>
> Quoting Steve Reinhardt :
>
>> Hi folks,
>>
>> Just a reminder that once you've committed a patch to the repo, you
>> should go back to reviewboard and mark the corresponding review
>> submission as "submitted".  The review request list is getting pretty
>> long, and I know there are some patches in there that have been
>> committed and so don't really need reviewing anymore.
>>
>> Thanks,
>>
>> Steve
>> ___
>> m5-dev mailing list
>> m5-dev@m5sim.org
>> http://m5sim.org/mailman/listinfo/m5-dev
>>
>
>
>
>
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] please mark reviews for committed patches as such

[Gabriel Michael Black]

Yeah, I'd noticed that too but I wasn't sure what to do about it. I'll  
take care of mine tonight.


Gabe

Quoting Steve Reinhardt :


Hi folks,

Just a reminder that once you've committed a patch to the repo, you
should go back to reviewboard and mark the corresponding review
submission as "submitted".  The review request list is getting pretty
long, and I know there are some patches in there that have been
committed and so don't really need reviewing anymore.

Thanks,

Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev





___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] please mark reviews for committed patches as such

[Steve Reinhardt]

Hi folks,

Just a reminder that once you've committed a patch to the repo, you
should go back to reviewboard and mark the corresponding review
submission as "submitted".  The review request list is getting pretty
long, and I know there are some patches in there that have been
committed and so don't really need reviewing anymore.

Thanks,

Steve
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] X86 says hello

[nathan binkert]

> Hey! I just successfully ran hello world in x86 on O3! This does NOT
> imply that x86 works generally on O3, only that it didn't choke on its
> own tongue running hello world.
That's great!

> There are apparently still some issues with
> uncommitted ARM patches I'm working through with Ali, but I'm hopeful
> those will be taken care of soon, they should have no impact on the
> majority of the patch (it's big), and I'd love to get it checked in not
> long after that.
We should, if possible, not delay your patch because of this.  It can
be fixed in a merge or in ali's patch.

  Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] X86 says hello

[nathan binkert]

> Yes, your PC state change is still on my to-do list... I *almost* got
> to it yesterday even.  Maybe this afternoon or tomorrow.

I've actually read two (of 9) pages!

  Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] delayed translation in O3

[nathan binkert]

> FS... I'm not really up for rebasing much, so we need to get the prefetch 
> stuff handled and then I can get the latest set in and next on the list is 
> the o3 stuff.

You can of course commit separately and then flip a coin to see who merges.

  Nate
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] X86 says hello

[Steve Reinhardt]

Awesome!  That's a great milestone.

Yes, your PC state change is still on my to-do list... I *almost* got
to it yesterday even.  Maybe this afternoon or tomorrow.

Steve

On Thu, Oct 21, 2010 at 6:17 AM, Gabe Black  wrote:
> Hey! I just successfully ran hello world in x86 on O3! This does NOT
> imply that x86 works generally on O3, only that it didn't choke on its
> own tongue running hello world. There are still significant holes to be
> filled in, major performance issues to sort out, etc. Also, this won't
> be available to anyone until I can start moving some patches, the first
> and most important of which is my PC state object patch on review board.
> I'm realistic about what other things people have to worry about first
> so don't stress out about looking at it, but it was posted a month ago
> and it would be very nice to get it taken care of when the collective
> you have a chance. There are apparently still some issues with
> uncommitted ARM patches I'm working through with Ali, but I'm hopeful
> those will be taken care of soon, they should have no impact on the
> majority of the patch (it's big), and I'd love to get it checked in not
> long after that.
>
> Gabe
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
>
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] X86 says hello

[Gabe Black]

Hey! I just successfully ran hello world in x86 on O3! This does NOT
imply that x86 works generally on O3, only that it didn't choke on its
own tongue running hello world. There are still significant holes to be
filled in, major performance issues to sort out, etc. Also, this won't
be available to anyone until I can start moving some patches, the first
and most important of which is my PC state object patch on review board.
I'm realistic about what other things people have to worry about first
so don't stress out about looking at it, but it was posted a month ago
and it would be very nice to get it taken care of when the collective
you have a chance. There are apparently still some issues with
uncommitted ARM patches I'm working through with Ali, but I'm hopeful
those will be taken care of soon, they should have no impact on the
majority of the patch (it's big), and I'd love to get it checked in not
long after that.

Gabe
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] X86 performance

[Gabe Black]

I have a simple change which adds code to x86's STUPD microop that saves
the old value of the base register into a backup int as described
before. I wanted to know how that affected performance of x86 simulation
because I expected it to be very minor, but I wanted to make sure.
Unfortunately running twolf on the atomic CPU, there's typically about a
5% slowdown, although it can be worse than that depending on the
specific run. The variability makes me think it might be a caching
issue, and because it happens with or without the extra storage location
in the integer register file, I'm thinking it might be that I'm pushing
something just beyond the capacity of the I cache.

Anyway, in a so far fruitless attempt to understand where the
performance is going, I ran the old and new versions through gprof. The
difference unfortunately vanishes with an instrumented binary, so that
didn't help. The output is below, though, and a couple things stand out.
First, the predecoder has a big impact on performance for x86. This
isn't that surprising since this isn't cached like decoded instructions
are, and it usually processes one byte at a time, or perhaps a whole
immediate at once. This could possibly be improved by a cache of some
sort, although we don't have the advantage of a one to one mapping
because the contextualizing info hasn't been added (by the predecoder)
yet. If we move the predecoder, and by extension the regular decoder, to
a modular design where there are multiple decoders which are used in
different circumstances, the contextualizing information could be
largely or hopefully entirely implicit based on what predecoder is in place.

The second and more immediately useful thing I see is that the ==
operator for ExtMachInsts is pretty high on the list. I was entertaining
the idea of adding some sort of simple hash to the ExtMachInst which
would be a hash of the rest of the structure. If the hashes don't match,
you can stop right there and not check the rest. The trouble is this is
normally used, I think, with ExtMachInsts associated with cached decoded
StaticInsts and ExtMachInsts fresh from the predecoder. By forcing the
predecoder to calculate a hash for everything it generates we could just
be moving the cost around or even making it worse. Then again,
ExtMachInst hashes are used to index into the hashmap used for the
decoder, I think, so making the hash function transparently return the
precomputed hash could save there too. On the other hand the == could be
from internal to the hash map, and by comparing with the hash we'll just
waste time since if the hash didn't match we wouldn't be in that bucket,
and the hash map wouldn't be bothering to compare values. Maybe my
ExtMachInst hash function stinks and things are clumped together.

Each sample counts as 0.01 seconds.
  %   cumulative   self  self total   
 time   seconds   secondscalls   s/call   s/call  name
 13.40  8.68 8.68 260854207 0.00 0.00 
AtomicSimpleCPU::tick()
  9.47 14.81 6.13 173494411 0.00 0.00 
X86ISA::Predecoder::process()
  7.13 19.42 4.62 260854207 0.00 0.00 
BaseSimpleCPU::preExecute()
  6.12 23.38 3.96 250692149 0.00 0.00 
Bus::recvAtomic(Packet*)
  4.25 26.13 2.75 250692149 0.00 0.00 
X86ISA::TLB::lookup(unsigned long, bool)
  4.06 28.76 2.63 250692149 0.00 0.00 
X86ISA::TLB::translate(Request*, ThreadContext*, BaseTLB::Translation*,
BaseTLB::Mode, bool&, bool)
  3.64 31.12 2.36 250692149 0.00 0.00 
PhysicalMemory::doAtomicAccess(Packet*)
  3.38 33.31 2.19 219431024 0.00 0.00 
BaseSimpleCPU::advancePC(RefCountingPtr)
  2.92 35.20 1.89 219431024 0.00 0.00 
BaseSimpleCPU::postExecute()
  2.83 37.03 1.83 569732017 0.00 0.00 
StaticInstPtr::operator=(StaticInstPtr const&)
  2.22 38.47 1.44 132035637 0.00 0.00 
X86ISA::operator==(X86ISA::ExtMachInst const&, X86ISA::ExtMachInst const&)
  2.15 39.87 1.40 56649590 0.00 0.00 
AtomicSimpleCPU::readBytes(unsigned long, unsigned char*, unsigned int,
unsigned int)
  1.82 41.05 1.18 219430620 0.00 0.00 
X86ISA::MacroopBase::fetchMicroop(unsigned short) const
  1.79 42.21 1.16 260854208 0.00 0.00 
EventQueue::serviceOne()
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] delayed translation in O3

[Ali Saidi]

FS... I'm not really up for rebasing much, so we need to get the prefetch stuff 
handled and then I can get the latest set in and next on the list is the o3 
stuff.

Ali

On Oct 20, 2010, at 12:09 AM, Gabe Black wrote:

> Great. I was thinking of adding a "translated" flag to the dyninst and
> then making commit wait for that, but it sounded suspiciously simple.
> Are you guys getting ARM to work on O3 for just SE, or FS too? I suppose
> if you need delayed translation that's for FS. Please let me know what
> other issues you've found so I know them if I see them. Any idea when
> you might start moving in O3 patches? After my PCstate patch I hope!
> 
> Gabe
> 
> Ali Saidi wrote:
>> We've got a lot of pending changes that fix issues like this in O3. I 
>> wouldn't put a lot of effort into it until we get out patches sorted out and 
>> thing might just go away.
>> 
>> Ali
>> 
>> On Oct 19, 2010, at 7:31 PM, Gabe Black wrote:
>> 
>> 
>>> I've just been poking around in O3, and the way it's handling delayed
>>> translation is looking pretty suspicious. The initiateAcc function
>>> 
>>> The executeStore function in lsq_unit_impl.hh is the only place
>>> initiateAcc is called in O3. This is actually a wrapper function which
>>> calls the initateAcc function on the staticInst inside.
>>> 
>>>   Fault store_fault = store_inst->initiateAcc();
>>> 
>>>   if (storeQueue[store_idx].size == 0) {
>>>   DPRINTF(LSQUnit,"Fault on Store PC %s, [sn:%lli],Size = 0\n",
>>>   store_inst->pcState(), store_inst->seqNum);
>>> 
>>>   return store_fault;
>>>   }
>>> 
>>>   assert(store_fault == NoFault);
>>> 
>>> What I think is going on here is that O3 expects if the store queue
>>> entry was initialized must not have caused a fault, so go ahead with
>>> execution.
>>> 
>>> If you look for translateTiming, the only place that's called by
>>> initiateTranslation in base_dyn_inst.hh which is called by readBytes and
>>> writeBytes.
>>> 
>>>   if (TheISA::HasUnalignedMemAcc) {
>>>   splitRequest(req, sreqLow, sreqHigh);
>>>   }
>>>   initiateTranslation(req, sreqLow, sreqHigh, NULL, BaseTLB::Read);
>>> 
>>>   if (fault == NoFault) {
>>>   effAddr = req->getVaddr();
>>>   effAddrValid = true;
>>>   fault = cpu->read(req, sreqLow, sreqHigh, data, lqIdx);
>>>   } else {
>>> 
>>> The callback used for when translation is finished is finishTranslation:
>>> 
>>> template
>>> inline void
>>> BaseDynInst::finishTranslation(WholeTranslationState *state)
>>> {
>>>   fault = state->getFault();
>>> 
>>>   if (state->isUncacheable())
>>>   isUncacheable = true;
>>> 
>>>   if (fault == NoFault) {
>>>   physEffAddr = state->getPaddr();
>>>   memReqFlags = state->getFlags();
>>> 
>>>   if (state->mainReq->isCondSwap()) {
>>>   assert(state->res);
>>>   state->mainReq->setExtraData(*state->res);
>>>   }
>>> 
>>>   } else {
>>>   state->deleteReqs();
>>>   }
>>>   delete state;
>>> }
>>> 
>>> So if translation finishes immediately, the fault gets set in
>>> finishTranslation iniline with the initiateTranslation call, and when
>>> you get back to readBytes/writeByte you can check it. If not, the
>>> translation just cleans up after itself and disappears, and the fault is
>>> lost.
>>> 
>>> Am I interpreting this correctly? Is this broken, or am I just missing
>>> some element that makes it work? Making this work correctly would make
>>> implementing my initiateAcc commits change easier because then the
>>> faults from executing initiateAcc and translation are clearly separated,
>>> not mushed together like they are now.
>>> 
>>> Gabe
>>> ___
>>> m5-dev mailing list
>>> m5-dev@m5sim.org
>>> http://m5sim.org/mailman/listinfo/m5-dev
>>> 
>>> 
>> 
>> ___
>> m5-dev mailing list
>> m5-dev@m5sim.org
>> http://m5sim.org/mailman/listinfo/m5-dev
>> 
> 
> ___
> m5-dev mailing list
> m5-dev@m5sim.org
> http://m5sim.org/mailman/listinfo/m5-dev
> 

___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

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

[Cron Daemon]

* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic 
FAILED!
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing 
FAILED!
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp 
FAILED!
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp 
FAILED!
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic 
FAILED!
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 FAILED!
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing 
FAILED!
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 FAILED!
* 
build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 FAILED!
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing FAILED!
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic 
FAILED!
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing 
FAILED!
* 
build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp
 FAILED!
* 
build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp
 FAILED!
* 
build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp
 FAILED!
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed.
* build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby 
passed.
* build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed.
* build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/si