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

> 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 instructi

Re: [m5-dev] delayed translation in O3

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 delaye

[m5-dev] delayed translation in O3

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 funct

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

--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/277/ --- (Updated 2010-10-19 17:30:48.985205) Review request for Default and Ruby Reviewers.

[m5-dev] Times completeAcc has to be called on stores

I've been surveying all the ISAs to see how they're using initiateAcc and completeAcc, and it looks like there are two cases where completeAcc needs to be (and apparently is) called on stores or store like instructions. The first are the StoreConditional instructions which have to (at least in some

Re: [m5-dev] PAL mode detection in the fetch stage of O3

Gabe Black wrote: > nathan binkert wrote: > >>> Whether there's an interrupt available is already tracked by ISA >>> dependent code by the Interrupts object which lives at commit. Why does >>> fetch need to know? Anything it fetches is just going to get blown away >>> anyway. >>> >>>

Re: [m5-dev] PAL mode detection in the fetch stage of O3

nathan binkert wrote: >> Whether there's an interrupt available is already tracked by ISA >> dependent code by the Interrupts object which lives at commit. Why does >> fetch need to know? Anything it fetches is just going to get blown away >> anyway. >> > > The point is, you want to redirect f

Re: [m5-dev] PAL mode detection in the fetch stage of O3

nathan binkert wrote: >> It might work to make callpal and rti SerializeAfter if they aren't >> already (or we may have to force a flush) and have them set a PAL bit in >> some control reg somewhere. Then the TLB can use that and ignore the PC. >> That would probably make those instructions perform

Re: [m5-dev] PAL mode detection in the fetch stage of O3

> Whether there's an interrupt available is already tracked by ISA > dependent code by the Interrupts object which lives at commit. Why does > fetch need to know? Anything it fetches is just going to get blown away > anyway. The point is, you want to redirect fetch intelligently. When there is an

Re: [m5-dev] PAL mode detection in the fetch stage of O3

nathan binkert wrote: >> That's better from the perspective that it's not as Alpha specific, but >> still no other ISA cares about the PC in that way, we'd be carrying >> around several (as many as 4, I think) extra uint64_ts, and only one bit >> actually matters. >> > > Could we carry around

Re: [m5-dev] PAL mode detection in the fetch stage of O3

> It might work to make callpal and rti SerializeAfter if they aren't > already (or we may have to force a flush) and have them set a PAL bit in > some control reg somewhere. Then the TLB can use that and ignore the PC. > That would probably make those instructions perform worse, though. I think t

Re: [m5-dev] PAL mode detection in the fetch stage of O3

> That's better from the perspective that it's not as Alpha specific, but > still no other ISA cares about the PC in that way, we'd be carrying > around several (as many as 4, I think) extra uint64_ts, and only one bit > actually matters. Could we carry around some sort of opaque ISA Flags object

Re: [m5-dev] PAL mode detection in the fetch stage of O3

nathan binkert wrote: >> How does switching in and out of PAL mode work? Could we take advantage >> of that somehow? I don't have a really good idea of how that might help. >> I'm just throwing the idea out there. >> > Basically, the callpal instruction is like a branch, but it also sets > the

Re: [m5-dev] PAL mode detection in the fetch stage of O3

nathan binkert wrote: >> The ExecContext is only for instructions when they execute (although I'm >> not 100% sure that's all it could be used for). I thought of this >> approach, but it doesn't work because the thing that puts together the >> fetch request would have to know the actual PC. If it g

Re: [m5-dev] PAL mode detection in the fetch stage of O3

> How does switching in and out of PAL mode work? Could we take advantage > of that somehow? I don't have a really good idea of how that might help. > I'm just throwing the idea out there. Basically, the callpal instruction is like a branch, but it also sets the mode bit (and enables the pal shadow

Re: [m5-dev] PAL mode detection in the fetch stage of O3

> The ExecContext is only for instructions when they execute (although I'm > not 100% sure that's all it could be used for). I thought of this > approach, but it doesn't work because the thing that puts together the > fetch request would have to know the actual PC. If it gets the filtered > one lik

Re: [m5-dev] PAL mode detection in the fetch stage of O3

How does switching in and out of PAL mode work? Could we take advantage of that somehow? I don't have a really good idea of how that might help. I'm just throwing the idea out there. Gabe Gabe Black wrote: > nathan binkert wrote: > >>>I'm trying to factor out PAL mode from O3, and I found

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

* 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/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic FAI