Re: [m5-dev] Review Request: ARM: Add I/O devices for booting linux

[Ali Saidi]

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



src/base/intmath.hh


There is an overflow that wouldn't be caught. If n >= 18446744073709551615 
the overflow wouldn't be caught. That probably isn't a reasonable case 
though... If you would prefer, n could be a 32bit int which would take care of 
the problem.



- Ali


On 2010-08-13 09:44:12, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/164/
> ---
> 
> (Updated 2010-08-13 09:44:12)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: Add I/O devices for booting linux
> 
> 
> Diffs
> -
> 
>   src/base/intmath.hh 3c48b2b3cb83 
>   src/dev/arm/RealView.py PRE-CREATION 
>   src/dev/arm/SConscript 3c48b2b3cb83 
>   src/dev/arm/Versatile.py 3c48b2b3cb83 
>   src/dev/arm/amba_device.hh PRE-CREATION 
>   src/dev/arm/amba_device.cc PRE-CREATION 
>   src/dev/arm/amba_fake.hh PRE-CREATION 
>   src/dev/arm/amba_fake.cc PRE-CREATION 
>   src/dev/arm/gic.hh PRE-CREATION 
>   src/dev/arm/gic.cc PRE-CREATION 
>   src/dev/arm/pl011.hh PRE-CREATION 
>   src/dev/arm/pl011.cc PRE-CREATION 
>   src/dev/arm/realview.hh PRE-CREATION 
>   src/dev/arm/realview.cc PRE-CREATION 
>   src/dev/arm/rv_ctrl.hh PRE-CREATION 
>   src/dev/arm/rv_ctrl.cc PRE-CREATION 
>   src/dev/arm/timer_sp804.hh PRE-CREATION 
>   src/dev/arm/timer_sp804.cc PRE-CREATION 
>   src/dev/arm/versatile.hh 3c48b2b3cb83 
>   src/dev/arm/versatile.cc 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/164/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] TimingSimpleCPU, x86: sendSplitData packet sender states

[Gabriel Michael Black]

This code was worked on a few times by different people, originally by  
me. When I wrote the first version, sender state wasn't chained  
together like I think it is now. I believe my version didn't do  
anything with sender state until it got the packet back, but I don't  
quite remember. You changed the sender state stuff, right Steve?  
What's the rule as far as when senderstate can change? Is the code  
checking it wrong, or the code changing it? This would likely affect  
ARM as well since it can have looser alignment requirements and might  
do a split load.


Gabe

Quoting Joel Hestness :


Hi,
  I am currently looking at the sendSplitData function in TimingSimpleCPU
(cpu/simple/timing.cc:~307), and I'm encountering a problem with the packet
sender states when running with Ruby.  After the call to buildSplitPacket,
pkt1 and pkt2 have senderState type SplitFragmentSenderState.  However, with
Ruby enabled, the call to handleReadPacket sends the packet to a RubyPort,
and in RubyPort::M5Port::recvTiming (mem/ruby/system/RubyPort.cc:~173), a
new senderState is pushed into the packet that has type SenderState (note
that the old senderState is saved in the new senderState. After the packet
transfer, Ruby restores the old senderState).  When the stack unwinds back
to sendSplitData, the dynamic_cast after handleReadPacket fails because of
the type difference.
  It looks like the senderState variable is used elsewhere as a stack to
store data while the packet traverses from source to destination and on the
way back as a response, which makes sense.  I'm wondering why the
clearFromParent call needs to happen in sendSplitData, since it seems like
it should happen in completeDataAccess when cleaning up the packets.
  Thanks,
  Joel

PS.  In sendSplitData after handleReadPacket(pkt2), it looks like there is a
bug with the dynamic_cast and clearFromParent since the cast is called on
pkt1->senderState.  This doesn't affect correctness, but it does leave
references that affect deletion of the packets.  Is that correct?

--
  Joel Hestness
  PhD Student, Computer Architecture
  Dept. of Computer Science, University of Texas - Austin
  http://www.cs.utexas.edu/~hestness




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

Re: [m5-dev] Review Request: ARM: Add I/O devices for booting linux

[Steve Reinhardt]

> On 2010-08-17 14:56:45, Ali Saidi wrote:
> > src/base/intmath.hh, line 84
> > 
> >
> > How about a warning if it's called with an exponent > 20?
> >
> 
> Steve Reinhardt wrote:
> I'd prefer something a little more robust.  One option is to track old 
> and new result values in the loop, and warn if new_result < old_result.  
> Another option is just to do it in FP by calling pow(), then verify that the 
> result is something that can be safely cast back to a uint64_t.  (I like that 
> second one, to be honest, assuming that this isn't called that frequently.)  
> The advantage of the first one is that if you actually do care about 
> performance, you could code it up in such a way that the test is only done in 
> debug mode.  However I don't recommend that unless you're really doing this 
> every 10 ticks.
> 
> Ali Saidi wrote:
> I have a warning if exp > 20 and a check old_val < result on every 
> iteration of the loop. sound good?
> 
> Gabe Black wrote:
> I considered adding that to my example code above, but then it seemed 
> that the calculation could overflow over and over and spew warnings. Also, 
> isn't it possible to overflow but still end up with a larger value? I don't 
> think it would be that difficult to find a case. Getting a warning sometimes 
> would be nice if it catches a problem, but if it doesn't it could give a 
> false sense of security. The FP suggestion seems a lot safer, but then too I 
> imagine you could end up having to round (you will, if you have a truely 64 
> bit integer) and getting something that doesn't actually overflow but that 
> fails the test.

If you've got the per-iteration check then I think the exp>20 warning is 
superfluous, right?

Gabe, as long as you're checking every iteration, then I don't think there's an 
overflow case that would fail the test (though I could be wrong).  Also, for 
the pow() approach, you'd expect to round, you'd just be testing that the float 
return value <= MAXINT (or whatever the uint64_t equivalent is).


- Steve


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


On 2010-08-13 09:44:12, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/164/
> ---
> 
> (Updated 2010-08-13 09:44:12)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: Add I/O devices for booting linux
> 
> 
> Diffs
> -
> 
>   src/base/intmath.hh 3c48b2b3cb83 
>   src/dev/arm/RealView.py PRE-CREATION 
>   src/dev/arm/SConscript 3c48b2b3cb83 
>   src/dev/arm/Versatile.py 3c48b2b3cb83 
>   src/dev/arm/amba_device.hh PRE-CREATION 
>   src/dev/arm/amba_device.cc PRE-CREATION 
>   src/dev/arm/amba_fake.hh PRE-CREATION 
>   src/dev/arm/amba_fake.cc PRE-CREATION 
>   src/dev/arm/gic.hh PRE-CREATION 
>   src/dev/arm/gic.cc PRE-CREATION 
>   src/dev/arm/pl011.hh PRE-CREATION 
>   src/dev/arm/pl011.cc PRE-CREATION 
>   src/dev/arm/realview.hh PRE-CREATION 
>   src/dev/arm/realview.cc PRE-CREATION 
>   src/dev/arm/rv_ctrl.hh PRE-CREATION 
>   src/dev/arm/rv_ctrl.cc PRE-CREATION 
>   src/dev/arm/timer_sp804.hh PRE-CREATION 
>   src/dev/arm/timer_sp804.cc PRE-CREATION 
>   src/dev/arm/versatile.hh 3c48b2b3cb83 
>   src/dev/arm/versatile.cc 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/164/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM: Add I/O devices for booting linux

[Gabe Black]

> On 2010-08-17 14:56:45, Ali Saidi wrote:
> > src/base/intmath.hh, line 84
> > 
> >
> > How about a warning if it's called with an exponent > 20?
> >
> 
> Steve Reinhardt wrote:
> I'd prefer something a little more robust.  One option is to track old 
> and new result values in the loop, and warn if new_result < old_result.  
> Another option is just to do it in FP by calling pow(), then verify that the 
> result is something that can be safely cast back to a uint64_t.  (I like that 
> second one, to be honest, assuming that this isn't called that frequently.)  
> The advantage of the first one is that if you actually do care about 
> performance, you could code it up in such a way that the test is only done in 
> debug mode.  However I don't recommend that unless you're really doing this 
> every 10 ticks.
> 
> Ali Saidi wrote:
> I have a warning if exp > 20 and a check old_val < result on every 
> iteration of the loop. sound good?

I considered adding that to my example code above, but then it seemed that the 
calculation could overflow over and over and spew warnings. Also, isn't it 
possible to overflow but still end up with a larger value? I don't think it 
would be that difficult to find a case. Getting a warning sometimes would be 
nice if it catches a problem, but if it doesn't it could give a false sense of 
security. The FP suggestion seems a lot safer, but then too I imagine you could 
end up having to round (you will, if you have a truely 64 bit integer) and 
getting something that doesn't actually overflow but that fails the test.


- Gabe


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


On 2010-08-13 09:44:12, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/164/
> ---
> 
> (Updated 2010-08-13 09:44:12)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: Add I/O devices for booting linux
> 
> 
> Diffs
> -
> 
>   src/base/intmath.hh 3c48b2b3cb83 
>   src/dev/arm/RealView.py PRE-CREATION 
>   src/dev/arm/SConscript 3c48b2b3cb83 
>   src/dev/arm/Versatile.py 3c48b2b3cb83 
>   src/dev/arm/amba_device.hh PRE-CREATION 
>   src/dev/arm/amba_device.cc PRE-CREATION 
>   src/dev/arm/amba_fake.hh PRE-CREATION 
>   src/dev/arm/amba_fake.cc PRE-CREATION 
>   src/dev/arm/gic.hh PRE-CREATION 
>   src/dev/arm/gic.cc PRE-CREATION 
>   src/dev/arm/pl011.hh PRE-CREATION 
>   src/dev/arm/pl011.cc PRE-CREATION 
>   src/dev/arm/realview.hh PRE-CREATION 
>   src/dev/arm/realview.cc PRE-CREATION 
>   src/dev/arm/rv_ctrl.hh PRE-CREATION 
>   src/dev/arm/rv_ctrl.cc PRE-CREATION 
>   src/dev/arm/timer_sp804.hh PRE-CREATION 
>   src/dev/arm/timer_sp804.cc PRE-CREATION 
>   src/dev/arm/versatile.hh 3c48b2b3cb83 
>   src/dev/arm/versatile.cc 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/164/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM: Clean up flattening for SPSR adding

[Ali Saidi]

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



src/arch/arm/isa.hh


Changed this to only call flattenMiscIndex if SPSR, however I imagine it's 
a wash since this is being inlined in the function and the first thing in does 
is the check.


- Ali


On 2010-08-13 10:16:56, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/195/
> ---
> 
> (Updated 2010-08-13 10:16:56)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: Clean up flattening for SPSR adding
> 
> 
> Diffs
> -
> 
>   src/arch/arm/isa.hh 3c48b2b3cb83 
>   src/arch/arm/isa.cc 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/195/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM: Don't write tracedata in completeAcc as we might hav freed it already

[Ali Saidi]

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



src/arch/arm/isa/templates/mem.isa


comment adjusted


- Ali


On 2010-08-13 10:15:01, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/191/
> ---
> 
> (Updated 2010-08-13 10:15:01)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: Don't write tracedata in completeAcc as we might have freed it already
> 
> 
> Diffs
> -
> 
>   src/arch/arm/isa/templates/mem.isa 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/191/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM: Implement CLREX init/complete acc methods

[Ali Saidi]

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



src/arch/arm/isa/templates/misc.isa


It just seems like a miscellaneous instruction, but it can be moved.


- Ali


On 2010-08-13 10:14:46, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/190/
> ---
> 
> (Updated 2010-08-13 10:14:46)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: Implement CLREX init/complete acc methods
> 
> 
> Diffs
> -
> 
>   src/arch/arm/isa/insts/misc.isa 3c48b2b3cb83 
>   src/arch/arm/isa/templates/misc.isa 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/190/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM/O3: store the result of the predicate evaluation in DynInst or Threadstate.

[Gabriel Michael Black]

Sorry if I wasn't clear before (I reread my post and it sounded a  
little vague) but what the simple CPU does is keep track of whether  
the supposed memory instruction actually calls read or write on the  
execution context. If not, then the CPU doesn't try to complete any  
access, it just considers that part over. Ideally we can do the same  
thing here.


Gabe

Quoting Ali Saidi :



Anyone have comments on this? It seems like this is the only way to access
the DynInst from the isa description. Threadstate does have the current
instruction in it, as well as things like "Temporary storage to pass the
source address from copy_load to". It doesn't seem to out of place to
include current instruction predication state in there.

Ali


On Sat, 14 Aug 2010 07:08:35 -, "Gabe Black" 
wrote:

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



src/cpu/thread_context.hh


This isn't really a property of a thread, it's the property of a
single instruction. I don't think this is being done in the right
place. I think we should have a discussion on m5-dev to determine

the

best way to handle this. There was a little code added to the simple
CPU that does what this is supposed to do if a memory instruction
didn't actually read or write memory, and I think this is a better

way

to handle this. We should have a discussion about this on m5-dev,
especially since it touches lots of low level bits like *contexts,
instruction behavior, CPUs, etc. These sorts of changes need to be

made

carefully.


- Gabe


On 2010-08-13 10:12:35, Ali Saidi wrote:


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

(Updated 2010-08-13 10:12:35)


Review request for Default and Min Kyu Jeong.


Summary
---

ARM/O3: store the result of the predicate evaluation in DynInst or
Threadstate.
THis allows the CPU to handle predicated-false instructions

accordingly.

This particular patch makes loads that are predicated-false to be sent
straight to the commit stage directly, not waiting for return of the

data

that was never requested since it was predicated-false.


Diffs
-

  src/arch/arm/isa/templates/mem.isa 3c48b2b3cb83
  src/arch/arm/isa/templates/pred.isa 3c48b2b3cb83
  src/cpu/base_dyn_inst.hh 3c48b2b3cb83
  src/cpu/base_dyn_inst_impl.hh 3c48b2b3cb83
  src/cpu/o3/lsq_unit_impl.hh 3c48b2b3cb83
  src/cpu/simple/base.hh 3c48b2b3cb83
  src/cpu/simple_thread.hh 3c48b2b3cb83
  src/cpu/thread_context.hh 3c48b2b3cb83

Diff: http://reviews.m5sim.org/r/177/diff


Testing
---


Thanks,

Ali




___
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

Re: [m5-dev] Review Request: Devices: Allow a device to specify that a request is uncachable.

[Ali Saidi]

> On 2010-08-13 16:03:06, Steve Reinhardt wrote:
> > src/dev/io_device.cc, line 231
> > 
> >
> > Did you really mean to commit this?

Fixed


- Ali


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


On 2010-08-13 10:14:31, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/188/
> ---
> 
> (Updated 2010-08-13 10:14:31)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> Devices: Allow a device to specify that a request is uncachable.
> 
> 
> Diffs
> -
> 
>   src/dev/io_device.hh 3c48b2b3cb83 
>   src/dev/io_device.cc 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/188/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM: Add I/O devices for booting linux

[Ali Saidi]

> On 2010-08-17 14:56:45, Ali Saidi wrote:
> > src/base/intmath.hh, line 84
> > 
> >
> > How about a warning if it's called with an exponent > 20?
> >
> 
> Steve Reinhardt wrote:
> I'd prefer something a little more robust.  One option is to track old 
> and new result values in the loop, and warn if new_result < old_result.  
> Another option is just to do it in FP by calling pow(), then verify that the 
> result is something that can be safely cast back to a uint64_t.  (I like that 
> second one, to be honest, assuming that this isn't called that frequently.)  
> The advantage of the first one is that if you actually do care about 
> performance, you could code it up in such a way that the test is only done in 
> debug mode.  However I don't recommend that unless you're really doing this 
> every 10 ticks.

I have a warning if exp > 20 and a check old_val < result on every iteration of 
the loop. sound good?


- Ali


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


On 2010-08-13 09:44:12, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/164/
> ---
> 
> (Updated 2010-08-13 09:44:12)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: Add I/O devices for booting linux
> 
> 
> Diffs
> -
> 
>   src/base/intmath.hh 3c48b2b3cb83 
>   src/dev/arm/RealView.py PRE-CREATION 
>   src/dev/arm/SConscript 3c48b2b3cb83 
>   src/dev/arm/Versatile.py 3c48b2b3cb83 
>   src/dev/arm/amba_device.hh PRE-CREATION 
>   src/dev/arm/amba_device.cc PRE-CREATION 
>   src/dev/arm/amba_fake.hh PRE-CREATION 
>   src/dev/arm/amba_fake.cc PRE-CREATION 
>   src/dev/arm/gic.hh PRE-CREATION 
>   src/dev/arm/gic.cc PRE-CREATION 
>   src/dev/arm/pl011.hh PRE-CREATION 
>   src/dev/arm/pl011.cc PRE-CREATION 
>   src/dev/arm/realview.hh PRE-CREATION 
>   src/dev/arm/realview.cc PRE-CREATION 
>   src/dev/arm/rv_ctrl.hh PRE-CREATION 
>   src/dev/arm/rv_ctrl.cc PRE-CREATION 
>   src/dev/arm/timer_sp804.hh PRE-CREATION 
>   src/dev/arm/timer_sp804.cc PRE-CREATION 
>   src/dev/arm/versatile.hh 3c48b2b3cb83 
>   src/dev/arm/versatile.cc 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/164/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: CPU: Make Exec trace to print predication result (if false) for memory instructions

[Ali Saidi]

> On 2010-08-13 23:55:49, Gabe Black wrote:
> > src/cpu/exetrace.cc, line 115
> > 
> >
> > How about "false predicate" instead? I don't think the word predicate 
> > is being used right here. This is partially just personal taste.

A search of papers for "predicate false" returns a lot of hits, so it has been 
used before.


- Ali


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


On 2010-08-13 10:10:25, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/180/
> ---
> 
> (Updated 2010-08-13 10:10:25)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> CPU: Make Exec trace to print predication result (if false) for memory 
> instructions
> 
> 
> Diffs
> -
> 
>   src/cpu/base_dyn_inst.hh 3c48b2b3cb83 
>   src/cpu/exetrace.cc 3c48b2b3cb83 
>   src/cpu/o3/lsq_unit_impl.hh 3c48b2b3cb83 
>   src/cpu/simple/base.hh 3c48b2b3cb83 
>   src/sim/insttracer.hh 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/180/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM/O3: store the result of the predicate evaluation in DynInst or Threadstate.

[Ali Saidi]

Anyone have comments on this? It seems like this is the only way to access
the DynInst from the isa description. Threadstate does have the current
instruction in it, as well as things like "Temporary storage to pass the
source address from copy_load to". It doesn't seem to out of place to
include current instruction predication state in there.

Ali


On Sat, 14 Aug 2010 07:08:35 -, "Gabe Black" 
wrote:
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/177/#review185
> ---
> 
> 
> 
> src/cpu/thread_context.hh
> 
> 
> This isn't really a property of a thread, it's the property of a
> single instruction. I don't think this is being done in the right
> place. I think we should have a discussion on m5-dev to determine
the
> best way to handle this. There was a little code added to the simple
> CPU that does what this is supposed to do if a memory instruction
> didn't actually read or write memory, and I think this is a better
way
> to handle this. We should have a discussion about this on m5-dev,
> especially since it touches lots of low level bits like *contexts,
> instruction behavior, CPUs, etc. These sorts of changes need to be
made
> carefully.
> 
> 
> - Gabe
> 
> 
> On 2010-08-13 10:12:35, Ali Saidi wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> http://reviews.m5sim.org/r/177/
>> ---
>> 
>> (Updated 2010-08-13 10:12:35)
>> 
>> 
>> Review request for Default and Min Kyu Jeong.
>> 
>> 
>> Summary
>> ---
>> 
>> ARM/O3: store the result of the predicate evaluation in DynInst or
>> Threadstate.
>> THis allows the CPU to handle predicated-false instructions
accordingly.
>> This particular patch makes loads that are predicated-false to be sent
>> straight to the commit stage directly, not waiting for return of the
data
>> that was never requested since it was predicated-false.
>> 
>> 
>> Diffs
>> -
>> 
>>   src/arch/arm/isa/templates/mem.isa 3c48b2b3cb83 
>>   src/arch/arm/isa/templates/pred.isa 3c48b2b3cb83 
>>   src/cpu/base_dyn_inst.hh 3c48b2b3cb83 
>>   src/cpu/base_dyn_inst_impl.hh 3c48b2b3cb83 
>>   src/cpu/o3/lsq_unit_impl.hh 3c48b2b3cb83 
>>   src/cpu/simple/base.hh 3c48b2b3cb83 
>>   src/cpu/simple_thread.hh 3c48b2b3cb83 
>>   src/cpu/thread_context.hh 3c48b2b3cb83 
>> 
>> Diff: http://reviews.m5sim.org/r/177/diff
>> 
>> 
>> Testing
>> ---
>> 
>> 
>> Thanks,
>> 
>> Ali
>> 
>>
> 
> ___
> 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] TimingSimpleCPU, x86: sendSplitData packet sender states

[Joel Hestness]

I just realized that the clearFromParent call is used for tracking which of
the packets have successfully sent, so that if the send port is busy, it can
retry them when a recvRetry is received later.  It appears that maybe a
better solution to this is to hold a pointer on the stack in sendSplitData
to the senderState that may eventually call clearFromParent rather than
trying to get the senderState back out after the call to handleReadPacket.
  Does sound reasonable?
  Thanks,
  Joel

On Tue, Aug 17, 2010 at 3:11 PM, Joel Hestness wrote:

> Hi,
>   I am currently looking at the sendSplitData function in TimingSimpleCPU
> (cpu/simple/timing.cc:~307), and I'm encountering a problem with the packet
> sender states when running with Ruby.  After the call to buildSplitPacket,
> pkt1 and pkt2 have senderState type SplitFragmentSenderState.  However, with
> Ruby enabled, the call to handleReadPacket sends the packet to a RubyPort,
> and in RubyPort::M5Port::recvTiming (mem/ruby/system/RubyPort.cc:~173), a
> new senderState is pushed into the packet that has type SenderState (note
> that the old senderState is saved in the new senderState. After the packet
> transfer, Ruby restores the old senderState).  When the stack unwinds back
> to sendSplitData, the dynamic_cast after handleReadPacket fails because of
> the type difference.
>   It looks like the senderState variable is used elsewhere as a stack to
> store data while the packet traverses from source to destination and on the
> way back as a response, which makes sense.  I'm wondering why the
> clearFromParent call needs to happen in sendSplitData, since it seems like
> it should happen in completeDataAccess when cleaning up the packets.
>   Thanks,
>   Joel
>
> PS.  In sendSplitData after handleReadPacket(pkt2), it looks like there is
> a bug with the dynamic_cast and clearFromParent since the cast is called on
> pkt1->senderState.  This doesn't affect correctness, but it does leave
> references that affect deletion of the packets.  Is that correct?
>
> --
>   Joel Hestness
>   PhD Student, Computer Architecture
>   Dept. of Computer Science, University of Texas - Austin
>   http://www.cs.utexas.edu/~hestness
>



-- 
  Joel Hestness
  PhD Student, Computer Architecture
  Dept. of Computer Science, University of Texas - Austin
  http://www.cs.utexas.edu/~hestness
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: ARM: Add I/O devices for booting linux

[Steve Reinhardt]

> On 2010-08-17 14:56:45, Ali Saidi wrote:
> > src/base/intmath.hh, line 84
> > 
> >
> > How about a warning if it's called with an exponent > 20?
> >

I'd prefer something a little more robust.  One option is to track old and new 
result values in the loop, and warn if new_result < old_result.  Another option 
is just to do it in FP by calling pow(), then verify that the result is 
something that can be safely cast back to a uint64_t.  (I like that second one, 
to be honest, assuming that this isn't called that frequently.)  The advantage 
of the first one is that if you actually do care about performance, you could 
code it up in such a way that the test is only done in debug mode.  However I 
don't recommend that unless you're really doing this every 10 ticks.


- Steve


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


On 2010-08-13 09:44:12, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/164/
> ---
> 
> (Updated 2010-08-13 09:44:12)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: Add I/O devices for booting linux
> 
> 
> Diffs
> -
> 
>   src/base/intmath.hh 3c48b2b3cb83 
>   src/dev/arm/RealView.py PRE-CREATION 
>   src/dev/arm/SConscript 3c48b2b3cb83 
>   src/dev/arm/Versatile.py 3c48b2b3cb83 
>   src/dev/arm/amba_device.hh PRE-CREATION 
>   src/dev/arm/amba_device.cc PRE-CREATION 
>   src/dev/arm/amba_fake.hh PRE-CREATION 
>   src/dev/arm/amba_fake.cc PRE-CREATION 
>   src/dev/arm/gic.hh PRE-CREATION 
>   src/dev/arm/gic.cc PRE-CREATION 
>   src/dev/arm/pl011.hh PRE-CREATION 
>   src/dev/arm/pl011.cc PRE-CREATION 
>   src/dev/arm/realview.hh PRE-CREATION 
>   src/dev/arm/realview.cc PRE-CREATION 
>   src/dev/arm/rv_ctrl.hh PRE-CREATION 
>   src/dev/arm/rv_ctrl.cc PRE-CREATION 
>   src/dev/arm/timer_sp804.hh PRE-CREATION 
>   src/dev/arm/timer_sp804.cc PRE-CREATION 
>   src/dev/arm/versatile.hh 3c48b2b3cb83 
>   src/dev/arm/versatile.cc 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/164/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM: Make sure that software prefetch instructions can't change the state of the TLB

[Ali Saidi]

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



src/mem/cache/cache_impl.hh


It's possible to be using the caches for a region of memory and then mark 
in uncachable with ARM. In this case we'l step on this assert. The above change 
causes the cache to invalidate that block when this happens. 


- Ali


On 2010-08-13 10:16:34, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/192/
> ---
> 
> (Updated 2010-08-13 10:16:34)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: Make sure that software prefetch instructions can't change the state of 
> the TLB
> 
> 
> Diffs
> -
> 
>   src/arch/arm/faults.hh 3c48b2b3cb83 
>   src/arch/arm/table_walker.cc 3c48b2b3cb83 
>   src/arch/arm/tlb.cc 3c48b2b3cb83 
>   src/mem/cache/cache_impl.hh 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/192/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM: adding genMachineCheckFault() stub for ARM that doesn't panic

[Ali Saidi]

> On 2010-08-14 00:03:01, Gabe Black wrote:
> > src/arch/arm/faults.hh, line 221
> > 
> >
> > What made this necessary? Why does non-ARM specific code need to 
> > generate resets through machine check faults?

The O3 cpu generates a fault when something that shouldn't happen does happen 
to make sure it doesn't reach past commit and is instead squashed.


> On 2010-08-14 00:03:01, Gabe Black wrote:
> > src/arch/arm/faults.hh, line 224
> > 
> >
> > Don't comment out code, delete it.

Done.


- Ali


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


On 2010-08-13 10:12:22, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/176/
> ---
> 
> (Updated 2010-08-13 10:12:22)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: adding genMachineCheckFault() stub for ARM that doesn't panic
> 
> 
> Diffs
> -
> 
>   src/arch/arm/faults.hh 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/176/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM: DFSR status value for sync external data abort is expected to be 0x8 in ARMv7

[Ali Saidi]

> On 2010-08-14 00:01:01, Gabe Black wrote:
> > src/arch/arm/faults.hh, line 78
> > 
> >
> > Is it that the value was wrong, or that the wrong 
> > SynchronousExternalAbort was being used? Now Synch...Abort0 and 1 have the 
> > same value which seems odd if not wrong.

Odd yes, wrong no... It's correct for ARMv7.


- Ali


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


On 2010-08-13 10:12:18, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/175/
> ---
> 
> (Updated 2010-08-13 10:12:18)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: DFSR status value for sync external data abort is expected to be 0x8 in 
> ARMv7
> 
> 
> Diffs
> -
> 
>   src/arch/arm/faults.hh 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/175/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: Loader: Don't insert symbols into the symbol table that begin wiht '$'.

[Ali Saidi]

> On 2010-08-13 23:45:23, Gabe Black wrote:
> > src/base/loader/elf_object.cc, line 378
> > 
> >
> > Are all symbols 100% guaranteed to be one character or longer? Is 
> > excluding symbols with "$" a universal behavior?
> > 
> > I honestly don't know the answers to those questions, but they make me 
> > a little nervous.

Well, the previous code ha that problem as well, but I've changed to to verify  
that elf_strptr didn't return null. Symbols beginning with $ are normally 
internally compiler/assembler generated and just turn the output into a but of 
$a+XXX instead of something meaningful, so it should be fine to ignore them. 


- Ali


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


On 2010-08-13 10:08:02, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/169/
> ---
> 
> (Updated 2010-08-13 10:08:02)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> Loader: Don't insert symbols into the symbol table that begin wiht '$'.
> 
> 
> Diffs
> -
> 
>   src/base/loader/elf_object.cc 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/169/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM: Add system for ARM/Linux and bootstrapping

[Ali Saidi]

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



src/arch/arm/faults.cc


M5_USED_VAR was added instead. Having the PC here is nice for debugging



src/arch/arm/faults.cc


Even though I didn't change it, it's ifxed



src/arch/arm/linux/atag.hh


No because part of the spec says that every descriptor is in units of  4 
byte chunks



src/arch/arm/linux/atag.hh


The style guide is silent on the matter



src/arch/arm/linux/atag.hh


Fine


- Ali


On 2010-08-13 09:44:46, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/165/
> ---
> 
> (Updated 2010-08-13 09:44:46)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: Add system for ARM/Linux and bootstrapping
> 
> 
> Diffs
> -
> 
>   src/arch/arm/ArmSystem.py 3c48b2b3cb83 
>   src/arch/arm/SConscript 3c48b2b3cb83 
>   src/arch/arm/faults.cc 3c48b2b3cb83 
>   src/arch/arm/linux/atag.hh PRE-CREATION 
>   src/arch/arm/linux/system.hh PRE-CREATION 
>   src/arch/arm/linux/system.cc PRE-CREATION 
>   src/arch/arm/system.cc 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/165/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

[m5-dev] TimingSimpleCPU, x86: sendSplitData packet sender states

[Joel Hestness]

Hi,
  I am currently looking at the sendSplitData function in TimingSimpleCPU
(cpu/simple/timing.cc:~307), and I'm encountering a problem with the packet
sender states when running with Ruby.  After the call to buildSplitPacket,
pkt1 and pkt2 have senderState type SplitFragmentSenderState.  However, with
Ruby enabled, the call to handleReadPacket sends the packet to a RubyPort,
and in RubyPort::M5Port::recvTiming (mem/ruby/system/RubyPort.cc:~173), a
new senderState is pushed into the packet that has type SenderState (note
that the old senderState is saved in the new senderState. After the packet
transfer, Ruby restores the old senderState).  When the stack unwinds back
to sendSplitData, the dynamic_cast after handleReadPacket fails because of
the type difference.
  It looks like the senderState variable is used elsewhere as a stack to
store data while the packet traverses from source to destination and on the
way back as a response, which makes sense.  I'm wondering why the
clearFromParent call needs to happen in sendSplitData, since it seems like
it should happen in completeDataAccess when cleaning up the packets.
  Thanks,
  Joel

PS.  In sendSplitData after handleReadPacket(pkt2), it looks like there is a
bug with the dynamic_cast and clearFromParent since the cast is called on
pkt1->senderState.  This doesn't affect correctness, but it does leave
references that affect deletion of the packets.  Is that correct?

-- 
  Joel Hestness
  PhD Student, Computer Architecture
  Dept. of Computer Science, University of Texas - Austin
  http://www.cs.utexas.edu/~hestness
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

Re: [m5-dev] Review Request: ARM: Implement some more misc registers

[Gabe Black]

> On 2010-08-17 14:47:22, Ali Saidi wrote:
> > src/arch/arm/isa.cc, line 215
> > 
> >
> > I don't see why that's any better. The warns are there because I intend 
> > to implement some functionality for them at some point, but I haven't 
> > gotten around to doing it. I would both like to be reminded of this fact on 
> > access and like to get past this point at present.

I think we're talking about different things. I'm talking about the ones that 
already return something, not the ones that are warning below that. The warning 
ones are fine.


> On 2010-08-17 14:47:22, Ali Saidi wrote:
> > src/arch/arm/miscregs.hh, line 150
> > 
> >
> > It matters because they must be moved above MISCREG_CP15_UNIMP_START to 
> > not cause a panic() when they are accessed because they're unimplemented.

You're right, I'd forgotten about that. Never mind!


- Gabe


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


On 2010-08-13 09:43:07, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/163/
> ---
> 
> (Updated 2010-08-13 09:43:07)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: Implement some more misc registers
> 
> 
> Diffs
> -
> 
>   src/arch/arm/isa.cc 3c48b2b3cb83 
>   src/arch/arm/isa/formats/misc.isa 3c48b2b3cb83 
>   src/arch/arm/miscregs.hh 3c48b2b3cb83 
>   src/arch/arm/miscregs.cc 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/163/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM: Add I/O devices for booting linux

[Ali Saidi]

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



src/base/intmath.hh


How about a warning if it's called with an exponent > 20?




src/dev/arm/timer_sp804.cc


You're right... this is what I get for trying to be cute... 

time = time / clock / power(16, control.timerPrescale); is what I'm after 


- Ali


On 2010-08-13 09:44:12, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/164/
> ---
> 
> (Updated 2010-08-13 09:44:12)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: Add I/O devices for booting linux
> 
> 
> Diffs
> -
> 
>   src/base/intmath.hh 3c48b2b3cb83 
>   src/dev/arm/RealView.py PRE-CREATION 
>   src/dev/arm/SConscript 3c48b2b3cb83 
>   src/dev/arm/Versatile.py 3c48b2b3cb83 
>   src/dev/arm/amba_device.hh PRE-CREATION 
>   src/dev/arm/amba_device.cc PRE-CREATION 
>   src/dev/arm/amba_fake.hh PRE-CREATION 
>   src/dev/arm/amba_fake.cc PRE-CREATION 
>   src/dev/arm/gic.hh PRE-CREATION 
>   src/dev/arm/gic.cc PRE-CREATION 
>   src/dev/arm/pl011.hh PRE-CREATION 
>   src/dev/arm/pl011.cc PRE-CREATION 
>   src/dev/arm/realview.hh PRE-CREATION 
>   src/dev/arm/realview.cc PRE-CREATION 
>   src/dev/arm/rv_ctrl.hh PRE-CREATION 
>   src/dev/arm/rv_ctrl.cc PRE-CREATION 
>   src/dev/arm/timer_sp804.hh PRE-CREATION 
>   src/dev/arm/timer_sp804.cc PRE-CREATION 
>   src/dev/arm/versatile.hh 3c48b2b3cb83 
>   src/dev/arm/versatile.cc 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/164/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM: Implement some more misc registers

[Ali Saidi]

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



src/arch/arm/isa.cc


I don't see why that's any better. The warns are there because I intend to 
implement some functionality for them at some point, but I haven't gotten 
around to doing it. I would both like to be reminded of this fact on access and 
like to get past this point at present. 



src/arch/arm/miscregs.hh


It matters because they must be moved above MISCREG_CP15_UNIMP_START to not 
cause a panic() when they are accessed because they're unimplemented. 


- Ali


On 2010-08-13 09:43:07, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/163/
> ---
> 
> (Updated 2010-08-13 09:43:07)
> 
> 
> Review request for Default.
> 
> 
> Summary
> ---
> 
> ARM: Implement some more misc registers
> 
> 
> Diffs
> -
> 
>   src/arch/arm/isa.cc 3c48b2b3cb83 
>   src/arch/arm/isa/formats/misc.isa 3c48b2b3cb83 
>   src/arch/arm/miscregs.hh 3c48b2b3cb83 
>   src/arch/arm/miscregs.cc 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/163/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: O3: Handle loads when the destination is the PC.

[Gabe Black]

> On 2010-08-14 00:14:09, Gabe Black wrote:
> > src/cpu/o3/lsq_unit_impl.hh, line 994
> > 
> >
> > Why doesn't the normal branch mispredict logic catch this?
> > 
> > I'm betting instructions that normally wouldn't be branches but that 
> > modify the PC aren't being marked as branches in the decoder, and that may 
> > or may not be contributing to this problem. This change may be necessary, 
> > but I'm skeptical.
> 
> Min Kyu Jeong wrote:
> Normally, branch misprediction is checked right after the instruction is 
> executed because we know the result immediately (or some fixed-cycle latency 
> but I don't believe that is being modeled). However, load instruction is a 
> split-transaction and therefore we need to have the check at the finishing 
> end of the split transaction.

I haven't actually verified what you're saying myself, but it sounds very 
plausible. Since most instructions in ARM and, apparently, all instructions in 
other ISAs won't need this code, you might want to only run it if the 
instruction is marked as a branch. You'd also need to make sure those 
instructions actually -are- marked as branches, but you'd want to do that 
anyway to really be correct. It would also be best, if at all possible, for 
this to go through the same mispredict and branch predictor updating logic as 
other instructions. That way we don'd duplicate the code, especially code that 
applies so infrequently and might not be run without really thorough testing, 
and we make sure the predictor gets involved and we don't mispredict on every 
load to the PC.


- Gabe


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


On 2010-08-13 10:12:44, Ali Saidi wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.m5sim.org/r/178/
> ---
> 
> (Updated 2010-08-13 10:12:44)
> 
> 
> Review request for Default and Min Kyu Jeong.
> 
> 
> Summary
> ---
> 
> O3: Handle loads when the destination is the PC.
> For loads that PC is the destination, check if the load
> was mispredicted again when the value being loaded returns from memory
> 
> 
> Diffs
> -
> 
>   src/cpu/o3/iew.hh 3c48b2b3cb83 
>   src/cpu/o3/iew_impl.hh 3c48b2b3cb83 
>   src/cpu/o3/lsq_unit.hh 3c48b2b3cb83 
>   src/cpu/o3/lsq_unit_impl.hh 3c48b2b3cb83 
> 
> Diff: http://reviews.m5sim.org/r/178/diff
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Ali
> 
>

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

Re: [m5-dev] Review Request: ARM: make predicated-false instruction to move data from a old register.

[Gabriel Michael Black]

Quoting Steve Reinhardt :


On Sun, Aug 15, 2010 at 6:07 PM, Min Kyu Jeong  wrote:



I needed to spit out a code that reads from a register, and writes to it
again. The thing is arch reg indices are renamed (reg renaming and shadow
reg file), so many structures are needed to be looked up to find a
previous/current physical register for the given arch reg name. These
indirections are handled in ISA-specific code and encapsulated, and the
operand section of the ISA description specifies which one to use.


I think we're thinking of these things on different levels... the
operand registers are available via StaticInst::srcRegIdx() and
destRegIdx(), and can be accessed via (for example) readIntReg() in
o3/thread_context_impl.hh, none of which are ISA dependent.  I don't
see why you can't build on these calls to handle this entirely within
the O3 model in an ISA-independent fashion (i.e., a way that would
generalize to any ISA with universal predication, if we ever run into
another one).

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



I was actually thinking this could be handled at a level higher than  
the parser, namely in the ISA description.


If the predicate is false, then the instruction still needs to forward  
the value from the physical source register to the physical  
destination register so future consumers get the right thing. For  
renaming to work, it's necessary for all those registers to be listed  
as both sources and destinations. By putting a fall through condition  
in the instruction as defined by the ISA description that just assigns  
registers to themselves (DestReg = DestReg; SrcReg1 = SrcReg1) both of  
those conditions are satisfied automatically without the CPUs having  
to get any smarter/complex/constrained and without retrofitting the  
ISA parser.


This will mean having to change a lot of instruction templates so that  
they have the fall through case and so that the definitions know what  
registers to assign to themselves. That's going to be tedious, but  
hopefully fairly mechanical to do.


If the ISA parser were a python framework instead of a parser, then  
it's conceivable this sort of thing could be handled automatically and  
cleanly by subclassing, replacing default function implementations,  
etc. etc., and kept local to ARM. That would give the benefits you  
might have been going for by changing the parser (the parser does the  
work, fewer bugs...) , but without impacting the complexity seen by  
all the other ISAs. That's not going to happen tomorrow or possibly  
ever so I hestitated to mention it and don't make any plans around it,  
but it's something I would really like to see happen.


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

[m5-dev] changeset in m5: misc: add some AMD copyright notices

[Steve Reinhardt]

changeset c76a14014c27 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=c76a14014c27
description:
misc: add some AMD copyright notices
Meant to add these with the previous batch of csets.

diffstat:

 configs/common/Simulation.py |  1 +
 src/python/m5/SimObject.py   |  1 +
 src/python/m5/params.py  |  1 +
 src/python/m5/simulate.py|  1 +
 src/sim/Root.py  |  1 +
 src/sim/sim_object.cc|  1 +
 src/sim/sim_object.hh|  1 +
 7 files changed, 7 insertions(+), 0 deletions(-)

diffs (65 lines):

diff -r b4aa25440bdd -r c76a14014c27 configs/common/Simulation.py
--- a/configs/common/Simulation.py  Tue Aug 17 05:20:39 2010 -0700
+++ b/configs/common/Simulation.py  Tue Aug 17 05:49:05 2010 -0700
@@ -1,4 +1,5 @@
 # Copyright (c) 2006-2008 The Regents of The University of Michigan
+# Copyright (c) 2010 Advanced Micro Devices, Inc.
 # All rights reserved.
 #
 # Redistribution and use in source and binary forms, with or without
diff -r b4aa25440bdd -r c76a14014c27 src/python/m5/SimObject.py
--- a/src/python/m5/SimObject.pyTue Aug 17 05:20:39 2010 -0700
+++ b/src/python/m5/SimObject.pyTue Aug 17 05:49:05 2010 -0700
@@ -1,4 +1,5 @@
 # Copyright (c) 2004-2006 The Regents of The University of Michigan
+# Copyright (c) 2010 Advanced Micro Devices, Inc.
 # All rights reserved.
 #
 # Redistribution and use in source and binary forms, with or without
diff -r b4aa25440bdd -r c76a14014c27 src/python/m5/params.py
--- a/src/python/m5/params.py   Tue Aug 17 05:20:39 2010 -0700
+++ b/src/python/m5/params.py   Tue Aug 17 05:49:05 2010 -0700
@@ -1,4 +1,5 @@
 # Copyright (c) 2004-2006 The Regents of The University of Michigan
+# Copyright (c) 2010 Advanced Micro Devices, Inc.
 # All rights reserved.
 #
 # Redistribution and use in source and binary forms, with or without
diff -r b4aa25440bdd -r c76a14014c27 src/python/m5/simulate.py
--- a/src/python/m5/simulate.py Tue Aug 17 05:20:39 2010 -0700
+++ b/src/python/m5/simulate.py Tue Aug 17 05:49:05 2010 -0700
@@ -1,4 +1,5 @@
 # Copyright (c) 2005 The Regents of The University of Michigan
+# Copyright (c) 2010 Advanced Micro Devices, Inc.
 # All rights reserved.
 #
 # Redistribution and use in source and binary forms, with or without
diff -r b4aa25440bdd -r c76a14014c27 src/sim/Root.py
--- a/src/sim/Root.py   Tue Aug 17 05:20:39 2010 -0700
+++ b/src/sim/Root.py   Tue Aug 17 05:49:05 2010 -0700
@@ -1,4 +1,5 @@
 # Copyright (c) 2005-2007 The Regents of The University of Michigan
+# Copyright (c) 2010 Advanced Micro Devices, Inc.
 # All rights reserved.
 #
 # Redistribution and use in source and binary forms, with or without
diff -r b4aa25440bdd -r c76a14014c27 src/sim/sim_object.cc
--- a/src/sim/sim_object.cc Tue Aug 17 05:20:39 2010 -0700
+++ b/src/sim/sim_object.cc Tue Aug 17 05:49:05 2010 -0700
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2001-2005 The Regents of The University of Michigan
+ * Copyright (c) 2010 Advanced Micro Devices, Inc.
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
diff -r b4aa25440bdd -r c76a14014c27 src/sim/sim_object.hh
--- a/src/sim/sim_object.hh Tue Aug 17 05:20:39 2010 -0700
+++ b/src/sim/sim_object.hh Tue Aug 17 05:49:05 2010 -0700
@@ -1,5 +1,6 @@
 /*
  * Copyright (c) 2001-2005 The Regents of The University of Michigan
+ * Copyright (c) 2010 Advanced Micro Devices, Inc.
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] changeset in m5: x86: minor checkpointing bug fixes

[Steve Reinhardt]

changeset b4aa25440bdd in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=b4aa25440bdd
description:
x86: minor checkpointing bug fixes

diffstat:

 src/arch/x86/interrupts.hh |  4 ++--
 src/arch/x86/isa.cc|  5 +
 2 files changed, 7 insertions(+), 2 deletions(-)

diffs (34 lines):

diff -r 3f6413fc37a2 -r b4aa25440bdd src/arch/x86/interrupts.hh
--- a/src/arch/x86/interrupts.hhTue Aug 17 05:17:06 2010 -0700
+++ b/src/arch/x86/interrupts.hhTue Aug 17 05:20:39 2010 -0700
@@ -260,13 +260,13 @@
 void
 serialize(std::ostream &os)
 {
-panic("Interrupts::serialize unimplemented!\n");
+warn("Interrupts::serialize unimplemented!\n");
 }
 
 void
 unserialize(Checkpoint *cp, const std::string §ion)
 {
-panic("Interrupts::unserialize unimplemented!\n");
+warn("Interrupts::unserialize unimplemented!\n");
 }
 
 /*
diff -r 3f6413fc37a2 -r b4aa25440bdd src/arch/x86/isa.cc
--- a/src/arch/x86/isa.cc   Tue Aug 17 05:17:06 2010 -0700
+++ b/src/arch/x86/isa.cc   Tue Aug 17 05:20:39 2010 -0700
@@ -352,6 +352,11 @@
  const std::string & section)
 {
 UNSERIALIZE_ARRAY(regVal, NumMiscRegs);
+updateHandyM5Reg(regVal[MISCREG_EFER],
+ regVal[MISCREG_CR0],
+ regVal[MISCREG_CS_ATTR],
+ regVal[MISCREG_SS_ATTR],
+ regVal[MISCREG_RFLAGS]);
 }
 
 }
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] changeset in m5: sim: revamp unserialization procedure

[Steve Reinhardt]

changeset 3f6413fc37a2 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=3f6413fc37a2
description:
sim: revamp unserialization procedure

Replace direct call to unserialize() on each SimObject with a pair of
calls for better control over initialization in both ckpt and non-ckpt
cases.

If restoring from a checkpoint, loadState(ckpt) is called on each
SimObject.  The default implementation simply calls unserialize() if
there is a corresponding checkpoint section, so we get backward
compatibility for existing objects.  However, objects can override
loadState() to get other behaviors, e.g., doing other programmed
initializations after unserialize(), or complaining if no checkpoint
section is found.  (Note that the default warning for a missing
checkpoint section is now gone.)

If not restoring from a checkpoint, we call the new initState() method
on each SimObject instead.  This provides a hook for state
initializations that are only required when *not* restoring from a
checkpoint.

Given this new framework, do some cleanup of LiveProcess subclasses
and X86System, which were (in some cases) emulating initState()
behavior in startup via a local flag or (in other cases) erroneously
doing initializations in startup() that clobbered state loaded earlier
by unserialize().

diffstat:

 src/arch/alpha/process.cc   |  26 +-
 src/arch/alpha/process.hh   |   6 +-
 src/arch/arm/process.cc |   4 +---
 src/arch/mips/process.cc|   5 ++---
 src/arch/mips/process.hh|   2 +-
 src/arch/power/linux/process.cc |   4 ++--
 src/arch/power/linux/process.hh |   2 +-
 src/arch/power/process.cc   |   7 +++
 src/arch/power/process.hh   |   2 +-
 src/arch/sparc/process.cc   |  18 ++
 src/arch/sparc/process.hh   |   6 +++---
 src/arch/x86/linux/system.cc|   4 ++--
 src/arch/x86/linux/system.hh|   2 +-
 src/arch/x86/process.cc |  14 --
 src/arch/x86/process.hh |   4 ++--
 src/arch/x86/system.cc  |   5 +++--
 src/arch/x86/system.hh  |   2 +-
 src/python/m5/simulate.py   |   6 +-
 src/python/swig/core.i  |   5 -
 src/python/swig/pyobject.hh |  10 --
 src/python/swig/sim_object.i|   2 ++
 src/sim/process.cc  |   9 +++--
 src/sim/process.hh  |   5 +
 src/sim/serialize.cc|  15 ++-
 src/sim/serialize.hh|   1 -
 src/sim/sim_object.cc   |  12 
 src/sim/sim_object.hh   |  39 +++
 27 files changed, 131 insertions(+), 86 deletions(-)

diffs (truncated from 609 to 300 lines):

diff -r f5e86115a07a -r 3f6413fc37a2 src/arch/alpha/process.cc
--- a/src/arch/alpha/process.cc Tue Aug 17 05:17:06 2010 -0700
+++ b/src/arch/alpha/process.cc Tue Aug 17 05:17:06 2010 -0700
@@ -173,19 +173,35 @@
 }
 
 void
-AlphaLiveProcess::startup()
+AlphaLiveProcess::setupASNReg()
 {
 ThreadContext *tc = system->getThreadContext(contextIds[0]);
 tc->setMiscRegNoEffect(IPR_DTB_ASN, M5_pid << 57);
+}
 
-if (checkpointRestored) {
-return;
-}
 
-Process::startup();
+void
+AlphaLiveProcess::loadState(Checkpoint *cp)
+{
+LiveProcess::loadState(cp);
+// need to set up ASN after unserialization since M5_pid value may
+// come from checkpoint
+setupASNReg();
+}
+
+
+void
+AlphaLiveProcess::initState()
+{
+// need to set up ASN before further initialization since init
+// will involve writing to virtual memory addresses
+setupASNReg();
+
+LiveProcess::initState();
 
 argsInit(MachineBytes, VMPageSize);
 
+ThreadContext *tc = system->getThreadContext(contextIds[0]);
 tc->setIntReg(GlobalPointerReg, objFile->globalPointer());
 //Operate in user mode
 tc->setMiscRegNoEffect(IPR_ICM, 0x18);
diff -r f5e86115a07a -r 3f6413fc37a2 src/arch/alpha/process.hh
--- a/src/arch/alpha/process.hh Tue Aug 17 05:17:06 2010 -0700
+++ b/src/arch/alpha/process.hh Tue Aug 17 05:17:06 2010 -0700
@@ -36,10 +36,14 @@
 
 class AlphaLiveProcess : public LiveProcess
 {
+  private:
+void setupASNReg();
+
   protected:
 AlphaLiveProcess(LiveProcessParams *params, ObjectFile *objFile);
 
-void startup();
+void loadState(Checkpoint *cp);
+void initState();
 
 void argsInit(int intSize, int pageSize);
 
diff -r f5e86115a07a -r 3f6413fc37a2 src/arch/arm/process.cc
--- a/src/arch/arm/process.cc   Tue Aug 17 05:17:06 2010 -0700
+++ b/src/arch/arm/process.cc   Tue Aug 17 05:17:06 2010 -0700
@@ -76,6 +76,7 @@
 void
 ArmLiveProcess::startup()
 {
+LiveProcess::startup();
 argsInit(MachineBytes, VMPageSize);
 }
 
@@ -114,9 +115,6 @@
 //We want 16 byte alignment
 uint64_t align = 16;
 
-// Overloaded argsInit so th

[m5-dev] changeset in m5: sim: fold checkpoint restore code into instanti...

[Steve Reinhardt]

changeset f5e86115a07a in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=f5e86115a07a
description:
sim: fold checkpoint restore code into instantiate()
The separate restoreCheckpoint() call is gone; just pass
the checkpoint dir as an optional arg to instantiate().
This change is a precursor to some more extensive
reworking of the startup code.

diffstat:

 configs/common/Simulation.py |  12 +++-
 src/python/m5/simulate.py|  14 ++
 2 files changed, 9 insertions(+), 17 deletions(-)

diffs (75 lines):

diff -r 89b6893554f5 -r f5e86115a07a configs/common/Simulation.py
--- a/configs/common/Simulation.py  Tue Aug 17 05:17:06 2010 -0700
+++ b/configs/common/Simulation.py  Tue Aug 17 05:17:06 2010 -0700
@@ -190,8 +190,7 @@
 for i in xrange(np):
 testsys.cpu[i].max_insts_any_thread = offset
 
-m5.instantiate()
-
+checkpoint_dir = None
 if options.checkpoint_restore != None:
 from os.path import isdir, exists
 from os import listdir
@@ -212,10 +211,6 @@
   "cpt.%s.%s" % (options.bench, inst))
 if not exists(checkpoint_dir):
 fatal("Unable to find checkpoint directory %s", checkpoint_dir)
-
-print "Restoring checkpoint ..."
-m5.restoreCheckpoint(checkpoint_dir)
-print "Done."
 else:
 dirs = listdir(cptdir)
 expr = re.compile('cpt\.([0-9]*)')
@@ -234,10 +229,9 @@
 
 ## Adjust max tick based on our starting tick
 maxtick = maxtick - int(cpts[cpt_num - 1])
+checkpoint_dir = joinpath(cptdir, "cpt.%s" % cpts[cpt_num - 1])
 
-## Restore the checkpoint
-m5.restoreCheckpoint(joinpath(cptdir,
-  "cpt.%s" % cpts[cpt_num - 1]))
+m5.instantiate(checkpoint_dir)
 
 if options.standard_switch or cpu_class:
 if options.standard_switch:
diff -r 89b6893554f5 -r f5e86115a07a src/python/m5/simulate.py
--- a/src/python/m5/simulate.py Tue Aug 17 05:17:06 2010 -0700
+++ b/src/python/m5/simulate.py Tue Aug 17 05:17:06 2010 -0700
@@ -46,7 +46,7 @@
 
 # The final hook to generate .ini files.  Called from the user script
 # once the config is built.
-def instantiate():
+def instantiate(ckpt_dir=None):
 root = objects.Root.getInstance()
 
 if not root:
@@ -86,6 +86,11 @@
 # We're done registering statistics.  Enable the stats package now.
 stats.enable()
 
+# Restore checkpoint (if any)
+if ckpt_dir:
+internal.core.unserializeAll(ckpt_dir)
+need_resume.append(root)
+
 # Reset to put the stats in a consistent state.
 stats.reset()
 
@@ -160,13 +165,6 @@
 internal.core.serializeAll(dir)
 resume(root)
 
-def restoreCheckpoint(dir):
-root = objects.Root.getInstance()
-print "Restoring from checkpoint"
-internal.core.unserializeAll(dir)
-need_resume.append(root)
-stats.reset()
-
 def changeToAtomic(system):
 if not isinstance(system, (objects.Root, objects.System)):
 raise TypeError, "Parameter of type '%s'.  Must be type %s or %s." % \
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] changeset in m5: configs: clean up checkpoint code in Simulation.py

[Steve Reinhardt]

changeset 89b6893554f5 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=89b6893554f5
description:
configs: clean up checkpoint code in Simulation.py
Small change to clean up some redundant code.
Should not have any functional impact.

diffstat:

 configs/common/Simulation.py |  30 ++
 1 files changed, 10 insertions(+), 20 deletions(-)

diffs (46 lines):

diff -r 383498e0a1cd -r 89b6893554f5 configs/common/Simulation.py
--- a/configs/common/Simulation.py  Tue Aug 17 05:14:03 2010 -0700
+++ b/configs/common/Simulation.py  Tue Aug 17 05:17:06 2010 -0700
@@ -200,32 +200,22 @@
 if not isdir(cptdir):
 fatal("checkpoint dir %s does not exist!", cptdir)
 
-if options.at_instruction:
-checkpoint_dir = joinpath(cptdir, "cpt.%s.%s" % \
-(options.bench, options.checkpoint_restore))
+if options.at_instruction or options.simpoint:
+inst = options.checkpoint_restore
+if options.simpoint:
+# assume workload 0 has the simpoint
+if testsys.cpu[0].workload[0].simpoint == 0:
+fatal('Unable to find simpoint')
+inst += int(testsys.cpu[0].workload[0].simpoint)
+
+checkpoint_dir = joinpath(cptdir,
+  "cpt.%s.%s" % (options.bench, inst))
 if not exists(checkpoint_dir):
 fatal("Unable to find checkpoint directory %s", checkpoint_dir)
 
 print "Restoring checkpoint ..."
 m5.restoreCheckpoint(checkpoint_dir)
 print "Done."
-elif options.simpoint:
-# assume workload 0 has the simpoint
-if testsys.cpu[0].workload[0].simpoint == 0:
-fatal('Unable to find simpoint')
-
-options.checkpoint_restore += \
-int(testsys.cpu[0].workload[0].simpoint)
-
-checkpoint_dir = joinpath(cptdir, "cpt.%s.%d" % \
-(options.bench, options.checkpoint_restore))
-if not exists(checkpoint_dir):
-fatal("Unable to find checkpoint directory %s.%s",
-  options.bench, options.checkpoint_restore)
-
-print "Restoring checkpoint ..."
-m5.restoreCheckpoint(checkpoint_dir)
-print "Done."
 else:
 dirs = listdir(cptdir)
 expr = re.compile('cpt\.([0-9]*)')
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] changeset in m5: test: Update stats for python object iteration.

[Steve Reinhardt]

changeset 383498e0a1cd in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=383498e0a1cd
description:
test: Update stats for python object iteration.
Small changes in tests with data races due to new object creation
order.

diffstat:

 tests/quick/30.eio-mp/ref/alpha/eio/simple-timing-mp/simerr
| 4 +
 tests/quick/30.eio-mp/ref/alpha/eio/simple-timing-mp/simout
|10 +-
 tests/quick/30.eio-mp/ref/alpha/eio/simple-timing-mp/stats.txt 
|   480 +-
 tests/quick/40.m5threads-test-atomic/ref/sparc/linux/o3-timing-mp/simout   
|12 +-
 tests/quick/40.m5threads-test-atomic/ref/sparc/linux/o3-timing-mp/stats.txt
|  2246 ++--
 tests/quick/40.m5threads-test-atomic/ref/sparc/linux/simple-atomic-mp/simout   
|10 +-
 
tests/quick/40.m5threads-test-atomic/ref/sparc/linux/simple-atomic-mp/stats.txt 
   |   544 +-
 tests/quick/40.m5threads-test-atomic/ref/sparc/linux/simple-timing-mp/simout   
|10 +-
 
tests/quick/40.m5threads-test-atomic/ref/sparc/linux/simple-timing-mp/stats.txt 
   |  1008 +-
 
tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/config.ini
  |   316 +-
 
tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/ruby.stats
  |  1058 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/simerr  
|   146 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/simout  
|12 +-
 
tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MESI_CMP_directory/stats.txt
   |42 +-
 
tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_directory/config.ini
 |   316 +-
 
tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_directory/ruby.stats
 |  2592 +++---
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_directory/simerr 
|   146 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_directory/simout 
|12 +-
 
tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_directory/stats.txt
  |42 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_token/config.ini 
|   316 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_token/ruby.stats 
|  3986 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_token/simerr 
|   146 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_token/simout 
|12 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_CMP_token/stats.txt  
|42 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/config.ini
|   508 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/ruby.stats
|  1896 ++--
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/simerr
|   146 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/simout
|12 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest-ruby-MOESI_hammer/stats.txt 
|42 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest/simerr  
|   128 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest/simout  
|10 +-
 tests/quick/50.memtest/ref/alpha/linux/memtest/stats.txt   
|   816 +-
 32 files changed, 8518 insertions(+), 8548 deletions(-)

diffs (truncated from 22594 to 300 lines):

diff -r 6efc3672733b -r 383498e0a1cd 
tests/quick/30.eio-mp/ref/alpha/eio/simple-timing-mp/simerr
--- a/tests/quick/30.eio-mp/ref/alpha/eio/simple-timing-mp/simerr   Tue Aug 
17 05:11:00 2010 -0700
+++ b/tests/quick/30.eio-mp/ref/alpha/eio/simple-timing-mp/simerr   Tue Aug 
17 05:14:03 2010 -0700
@@ -5,3 +5,7 @@
 gzip: stdout: Broken pipe
 
 gzip: stdout: Broken pipe
+
+gzip: stdout: Broken pipe
+
+gzip: stdout: Broken pipe
diff -r 6efc3672733b -r 383498e0a1cd 
tests/quick/30.eio-mp/ref/alpha/eio/simple-timing-mp/simout
--- a/tests/quick/30.eio-mp/ref/alpha/eio/simple-timing-mp/simout   Tue Aug 
17 05:11:00 2010 -0700
+++ b/tests/quick/30.eio-mp/ref/alpha/eio/simple-timing-mp/simout   Tue Aug 
17 05:14:03 2010 -0700
@@ -5,11 +5,11 @@
 All Rights Reserved
 
 
-M5 compiled Feb 24 2010 23:12:40
-M5 revision 1a33ca29ec29 6980 default share-aware-test-update.patch tip qtip
-M5 started Feb 25 2010 02:28:17
-M5 executing on SC2B0619
-command line: build/ALPHA_SE/m5.fast -d 
build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp -re 
tests/run.py 
build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp
+M5 compiled Jul  1 2010 14:37:40
+M5 revision acd9f15a9c7c 7493 default qtip tip simobj-parent-fix-stats-udpate
+M5 started Jul  1 2010 14:37:50
+M5 executing on phenom
+command line: build/ALPHA_SE/m5.opt -d 
build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp -re 
tests/run.py build/ALPHA_SE/tests/opt/quick/30.eio-mp/alpha/eio/simple-timing-mp
 Global f

[m5-dev] changeset in m5: sim: clean up child handling

[Steve Reinhardt]

changeset 6efc3672733b in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=6efc3672733b
description:
sim: clean up child handling
The old code for handling SimObject children was kind of messy,
with children stored both in _values and _children, and
inconsistent and potentially buggy handling of SimObject
vectors.  Now children are always stored in _children, and
SimObject vectors are consistently handled using the
SimObjectVector class.

Also, by deferring the parenting of SimObject-valued parameters
until the end (instead of doing it at assignment), we eliminate
the hole where one could assign a vector of SimObjects to a
parameter then append to that vector, with the appended objects
never getting parented properly.

This patch induces small stats changes in tests with data races
due to changes in the object creation & initialization order.
The new code does object vectors in order and so should be more
stable.

diffstat:

 src/python/m5/SimObject.py |  142 +---
 src/python/m5/params.py|   41 +++-
 src/python/m5/simulate.py  |4 +
 3 files changed, 135 insertions(+), 52 deletions(-)

diffs (truncated from 339 to 300 lines):

diff -r fe90827a663f -r 6efc3672733b src/python/m5/SimObject.py
--- a/src/python/m5/SimObject.pyTue Aug 17 05:08:50 2010 -0700
+++ b/src/python/m5/SimObject.pyTue Aug 17 05:11:00 2010 -0700
@@ -27,7 +27,6 @@
 # Authors: Steve Reinhardt
 #  Nathan Binkert
 
-import math
 import sys
 from types import FunctionType
 
@@ -45,7 +44,8 @@
 from m5.params import *
 # There are a few things we need that aren't in params.__all__ since
 # normal users don't need them
-from m5.params import ParamDesc, VectorParamDesc, isNullPointer, SimObjVector
+from m5.params import ParamDesc, VectorParamDesc, \
+ isNullPointer, SimObjectVector
 
 from m5.proxy import *
 from m5.proxy import isproxy
@@ -155,6 +155,7 @@
 
 # class or instance attributes
 cls._values = multidict()   # param values
+cls._children = multidict() # SimObject children
 cls._port_refs = multidict() # port ref objects
 cls._instantiated = False # really instantiated, cloned, or subclassed
 
@@ -174,6 +175,7 @@
 cls._params.parent = base._params
 cls._ports.parent = base._ports
 cls._values.parent = base._values
+cls._children.parent = base._children
 cls._port_refs.parent = base._port_refs
 # mark base as having been subclassed
 base._instantiated = True
@@ -305,11 +307,7 @@
 
 if isSimObjectOrSequence(value):
 # If RHS is a SimObject, it's an implicit child assignment.
-# Classes don't have children, so we just put this object
-# in _values; later, each instance will do a 'setattr(self,
-# attr, _values[attr])' in SimObject.__init__ which will
-# add this object as a child.
-cls._values[attr] = value
+cls._children[attr] = coerceSimObjectOrVector(value)
 return
 
 # no valid assignment... raise exception
@@ -320,6 +318,9 @@
 if cls._values.has_key(attr):
 return cls._values[attr]
 
+if cls._children.has_key(attr):
+return cls._children[attr]
+
 raise AttributeError, \
   "object '%s' has no attribute '%s'" % (cls.__name__, attr)
 
@@ -465,20 +466,27 @@
 
 # initialize required attributes
 self._parent = None
-self._children = {}
+self._name = None
 self._ccObject = None  # pointer to C++ object
 self._ccParams = None
 self._instantiated = False # really "cloned"
 
 # Inherit parameter values from class using multidict so
-# individual value settings can be overridden.
+# individual value settings can be overridden but we still
+# inherit late changes to non-overridden class values.
 self._values = multidict(ancestor._values)
 # clone SimObject-valued parameters
 for key,val in ancestor._values.iteritems():
-if isSimObject(val):
-setattr(self, key, val(_memo=memo_dict))
-elif isSimObjectSequence(val) and len(val):
-setattr(self, key, [ v(_memo=memo_dict) for v in val ])
+val = tryAsSimObjectOrVector(val)
+if val is not None:
+self._values[key] = val(_memo=memo_dict)
+
+# Clone children specified at class level.  No need for a
+# multidict here since we will be cloning everything.
+self._children = {}
+for key,val in ancestor._children.iteritems():
+self.add_child(key, val(_memo=memo_dict))
+
 # clone port references.  no need to use a multidict here
 # since we

[m5-dev] changeset in m5: sim: fail on implicit creation of orphans via p...

[Steve Reinhardt]

changeset 4bb5f5207617 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=4bb5f5207617
description:
sim: fail on implicit creation of orphans via ports
Orphan SimObjects (not in the config hierarchy) could get
created implicitly if they have a port connection to a SimObject
that is in the hierarchy.  This means that there are objects on
the C++ SimObject list (created via the C++ SimObject
constructor call) that are unknown to Python and will get
skipped if we walk the hierarchy from the Python side (as we are
about to do).  This patch detects this situation and prints an
error message.

Also fix the rubytester config script which happened to rely on
this behavior.

diffstat:

 src/python/m5/SimObject.py |  11 +--
 src/python/m5/params.py|  10 --
 tests/configs/rubytest-ruby.py |   2 +-
 3 files changed, 18 insertions(+), 5 deletions(-)

diffs (65 lines):

diff -r 722f2ad014a7 -r 4bb5f5207617 src/python/m5/SimObject.py
--- a/src/python/m5/SimObject.pyTue Aug 17 05:06:22 2010 -0700
+++ b/src/python/m5/SimObject.pyTue Aug 17 05:06:22 2010 -0700
@@ -761,13 +761,16 @@
 # children.
 def getCCObject(self):
 if not self._ccObject:
-# Cycles in the configuration heirarchy are not supported. This
+# Make sure this object is in the configuration hierarchy
+if not self._parent and not isRoot(self):
+raise RuntimeError, "Attempt to instantiate orphan node"
+# Cycles in the configuration hierarchy are not supported. This
 # will catch the resulting recursion and stop.
 self._ccObject = -1
 params = self.getCCParams()
 self._ccObject = params.create()
 elif self._ccObject == -1:
-raise RuntimeError, "%s: Cycle found in configuration heirarchy." \
+raise RuntimeError, "%s: Cycle found in configuration hierarchy." \
   % self.path()
 return self._ccObject
 
@@ -890,6 +893,10 @@
 def isSimObjectOrSequence(value):
 return isSimObject(value) or isSimObjectSequence(value)
 
+def isRoot(obj):
+from m5.objects import Root
+return obj and obj is Root.getInstance()
+
 baseClasses = allClasses.copy()
 baseInstances = instanceDict.copy()
 
diff -r 722f2ad014a7 -r 4bb5f5207617 src/python/m5/params.py
--- a/src/python/m5/params.py   Tue Aug 17 05:06:22 2010 -0700
+++ b/src/python/m5/params.py   Tue Aug 17 05:06:22 2010 -0700
@@ -1049,8 +1049,14 @@
 peer = self.peer
 if not self.peer: # nothing to connect to
 return
-connectPorts(self.simobj.getCCObject(), self.name, self.index,
- peer.simobj.getCCObject(), peer.name, peer.index)
+try:
+connectPorts(self.simobj.getCCObject(), self.name, self.index,
+ peer.simobj.getCCObject(), peer.name, peer.index)
+except:
+print "Error connecting port %s.%s to %s.%s" % \
+  (self.simobj.path(), self.name,
+   peer.simobj.path(), peer.name)
+raise
 self.ccConnected = True
 peer.ccConnected = True
 
diff -r 722f2ad014a7 -r 4bb5f5207617 tests/configs/rubytest-ruby.py
--- a/tests/configs/rubytest-ruby.pyTue Aug 17 05:06:22 2010 -0700
+++ b/tests/configs/rubytest-ruby.pyTue Aug 17 05:06:22 2010 -0700
@@ -70,7 +70,7 @@
 #
 tester = RubyTester(checks_to_complete = 100, wakeup_frequency = 10)
 
-system = System(physmem = PhysicalMemory())
+system = System(tester = tester, physmem = PhysicalMemory())
 
 system.ruby = Ruby.create_system(options, system.physmem)
 
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev

[m5-dev] changeset in m5: sim: move iterating over SimObjects into Python.

[Steve Reinhardt]

changeset fe90827a663f in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=fe90827a663f
description:
sim: move iterating over SimObjects into Python.

diffstat:

 src/python/m5/SimObject.py   |  46 +--
 src/python/m5/core.py|   8 
 src/python/m5/simulate.py|  33 ++--
 src/python/m5/stats.py   |   5 ++
 src/python/swig/core.i   |   4 --
 src/python/swig/pyobject.hh  |  17 -
 src/python/swig/sim_object.i |   6 +++
 src/sim/sim_object.cc|  82 
 src/sim/sim_object.hh|   8 
 9 files changed, 42 insertions(+), 167 deletions(-)

diffs (truncated from 417 to 300 lines):

diff -r 4bb5f5207617 -r fe90827a663f src/python/m5/SimObject.py
--- a/src/python/m5/SimObject.pyTue Aug 17 05:06:22 2010 -0700
+++ b/src/python/m5/SimObject.pyTue Aug 17 05:08:50 2010 -0700
@@ -530,7 +530,8 @@
 # If the attribute exists on the C++ object, transparently
 # forward the reference there.  This is typically used for
 # SWIG-wrapped methods such as init(), regStats(),
-# regFormulas(), resetStats(), and startup().
+# regFormulas(), resetStats(), startup(), drain(), and
+# resume().
 if self._ccObject and hasattr(self._ccObject, attr):
 return getattr(self._ccObject, attr)
 
@@ -660,7 +661,7 @@
 def unproxy(self, base):
 return self
 
-def unproxy_all(self):
+def unproxyParams(self):
 for param in self._params.iterkeys():
 value = self._values.get(param)
 if value != None and isproxy(value):
@@ -681,12 +682,6 @@
 if port != None:
 port.unproxy(self)
 
-# Unproxy children in sorted order for determinism also.
-child_names = self._children.keys()
-child_names.sort()
-for child in child_names:
-self._children[child].unproxy_all()
-
 def print_ini(self, ini_file):
 print >>ini_file, '[' + self.path() + ']'   # .ini section header
 
@@ -717,9 +712,6 @@
 
 print >>ini_file# blank line between objects
 
-for child in child_names:
-self._children[child].print_ini(ini_file)
-
 def getCCParams(self):
 if self._ccParams:
 return self._ccParams
@@ -774,39 +766,25 @@
   % self.path()
 return self._ccObject
 
-# Call C++ to create C++ object corresponding to this object and
-# (recursively) all its children
+def descendants(self):
+yield self
+for child in self._children.itervalues():
+for obj in child.descendants():
+yield obj
+
+# Call C++ to create C++ object corresponding to this object
 def createCCObject(self):
 self.getCCParams()
 self.getCCObject() # force creation
-for child in self._children.itervalues():
-child.createCCObject()
 
 def getValue(self):
 return self.getCCObject()
 
 # Create C++ port connections corresponding to the connections in
-# _port_refs (& recursively for all children)
+# _port_refs
 def connectPorts(self):
 for portRef in self._port_refs.itervalues():
 portRef.ccConnect()
-for child in self._children.itervalues():
-child.connectPorts()
-
-def startDrain(self, drain_event, recursive):
-count = 0
-if isinstance(self, SimObject):
-count += self._ccObject.drain(drain_event)
-if recursive:
-for child in self._children.itervalues():
-count += child.startDrain(drain_event, True)
-return count
-
-def resume(self):
-if isinstance(self, SimObject):
-self._ccObject.resume()
-for child in self._children.itervalues():
-child.resume()
 
 def getMemoryMode(self):
 if not isinstance(self, m5.objects.System):
@@ -820,8 +798,6 @@
 # setMemoryMode directly from self._ccObject results in calling
 # SimObject::setMemoryMode, not the System::setMemoryMode
 self._ccObject.setMemoryMode(mode)
-for child in self._children.itervalues():
-child.changeTiming(mode)
 
 def takeOverFrom(self, old_cpu):
 self._ccObject.takeOverFrom(old_cpu._ccObject)
diff -r 4bb5f5207617 -r fe90827a663f src/python/m5/core.py
--- a/src/python/m5/core.py Tue Aug 17 05:06:22 2010 -0700
+++ b/src/python/m5/core.py Tue Aug 17 05:08:50 2010 -0700
@@ -27,14 +27,6 @@
 # Authors: Nathan Binkert
 
 import internal
-from internal.core import initAll, regAllStats
 
 def setOutputDir(dir):
 internal.core.setOutputDir(dir)
-
-def initAll():
-internal.core.initAll()
-
-def regAllStats():
-internal.core.regAllStats()
-
diff -r 4bb5f5207617 -r fe90827a663f src/python/m5/simulate.py
--- a/src/python/m5/simulate.py Tue Aug 17 05:06:22 2010 -0700
+++ b/sr

[m5-dev] changeset in m5: tests: update reference config.ini files for pr...

[Steve Reinhardt]

changeset 1eb0be76e800 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=1eb0be76e800
description:
tests: update reference config.ini files for previous cset
Rename 'responder_set' to 'use_default_range'.

diffstat:

 tests/long/00.gzip/ref/alpha/tru64/o3-timing/config.ini
   |  4 ++--
 tests/long/00.gzip/ref/alpha/tru64/simple-atomic/config.ini
   |  2 +-
 tests/long/00.gzip/ref/alpha/tru64/simple-timing/config.ini
   |  4 ++--
 tests/long/00.gzip/ref/arm/linux/simple-atomic/config.ini  
   |  2 +-
 tests/long/00.gzip/ref/arm/linux/simple-timing/config.ini  
   |  4 ++--
 tests/long/00.gzip/ref/sparc/linux/o3-timing/config.ini
   |  4 ++--
 tests/long/00.gzip/ref/sparc/linux/simple-atomic/config.ini
   |  2 +-
 tests/long/00.gzip/ref/sparc/linux/simple-timing/config.ini
   |  4 ++--
 tests/long/00.gzip/ref/x86/linux/simple-atomic/config.ini  
   |  2 +-
 tests/long/00.gzip/ref/x86/linux/simple-timing/config.ini  
   |  4 ++--
 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3-dual/config.ini
   |  6 +++---
 tests/long/10.linux-boot/ref/alpha/linux/tsunami-o3/config.ini 
   |  6 +++---
 tests/long/10.mcf/ref/arm/linux/simple-atomic/config.ini   
   |  2 +-
 tests/long/10.mcf/ref/arm/linux/simple-timing/config.ini   
   |  4 ++--
 tests/long/10.mcf/ref/sparc/linux/simple-atomic/config.ini 
   |  2 +-
 tests/long/10.mcf/ref/sparc/linux/simple-timing/config.ini 
   |  4 ++--
 tests/long/10.mcf/ref/x86/linux/simple-atomic/config.ini   
   |  2 +-
 tests/long/10.mcf/ref/x86/linux/simple-timing/config.ini   
   |  4 ++--
 tests/long/20.parser/ref/arm/linux/simple-atomic/config.ini
   |  2 +-
 tests/long/20.parser/ref/arm/linux/simple-timing/config.ini
   |  4 ++--
 tests/long/20.parser/ref/x86/linux/simple-atomic/config.ini
   |  2 +-
 tests/long/20.parser/ref/x86/linux/simple-timing/config.ini
   |  4 ++--
 tests/long/30.eon/ref/alpha/tru64/o3-timing/config.ini 
   |  4 ++--
 tests/long/30.eon/ref/alpha/tru64/simple-atomic/config.ini 
   |  2 +-
 tests/long/30.eon/ref/alpha/tru64/simple-timing/config.ini 
   |  4 ++--
 tests/long/30.eon/ref/arm/linux/simple-atomic/config.ini   
   |  2 +-
 tests/long/30.eon/ref/arm/linux/simple-timing/config.ini   
   |  4 ++--
 tests/long/40.perlbmk/ref/alpha/tru64/o3-timing/config.ini 
   |  4 ++--
 tests/long/40.perlbmk/ref/alpha/tru64/simple-atomic/config.ini 
   |  2 +-
 tests/long/40.perlbmk/ref/alpha/tru64/simple-timing/config.ini 
   |  4 ++--
 tests/long/40.perlbmk/ref/arm/linux/simple-atomic/config.ini   
   |  2 +-
 tests/long/40.perlbmk/ref/arm/linux/simple-timing/config.ini   
   |  4 ++--
 tests/long/50.vortex/ref/alpha/tru64/inorder-timing/config.ini 
   |  4 ++--
 tests/long/50.vortex/ref/alpha/tru64/o3-timing/config.ini  
   |  4 ++--
 tests/long/50.vortex/ref/alpha/tru64/simple-atomic/config.ini  
   |  2 +-
 tests/long/50.vortex/ref/alpha/tru64/simple-timing/config.ini  
   |  4 ++--
 tests/long/50.vortex/ref/arm/linux/simple-atomic/config.ini
   |  2 +-
 tests/long/50.vortex/ref/arm/linux/simple-timing/config.ini
   |  4 ++--
 tests/long/50.vortex/ref/sparc/linux/simple-atomic/config.ini  
   |  2 +-
 tests/long/50.vortex/ref/sparc/linux/simple-timing/config.ini  
   |  4 ++--
 tests/long/60.bzip2/ref/alpha/tru64/o3-timing/config.ini   
   |  4 ++--
 tests/long/60.bzip2/ref/alpha/tru64/simple-atomic/config.ini   
   |  2 +-
 tests/long/60.bzip2/ref/alpha/tru64/simple-timing/config.ini   
   |  4 ++--
 tests/long/60.bzip2/ref/arm/linux/simple-atomic/config.ini 
   |  2 +-
 tests/long/60.bzip2/ref/arm/linux/simple-timing/config.ini 
   |  4 ++--
 tests/long/60.bzip2/ref/x86/linux/simple-atomic/config.ini 
   |  2 +-
 tests/long/60.bzip2/ref/x86/linux/simple-timing/config.ini 
   |  4 ++--
 tests/long/70.twolf/ref/alpha/tru64/inorder-timing/config.ini  
   |  4 ++--
 tests/long/70.twolf/ref/alpha/tru64/o3-timing/config.ini  

[m5-dev] changeset in m5: sim: make Python Root object a singleton

[Steve Reinhardt]

changeset 722f2ad014a7 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=722f2ad014a7
description:
sim: make Python Root object a singleton
Enforce that the Python Root SimObject is instantiated only
once.  The C++ Root object already panics if more than one is
created.  This change avoids the need to track what the root
object is, since it's available from Root.getInstance() (if it
exists).  It's now redundant to have the user pass the root
object to functions like instantiate(), checkpoint(), and
restoreCheckpoint(), so that arg is gone.  Users who use
configs/common/Simulate.py should not notice.

diffstat:

 configs/common/Simulation.py|  20 ++--
 configs/example/memtest-ruby.py |   2 +-
 configs/example/memtest.py  |   2 +-
 configs/example/rubytest.py |   2 +-
 configs/splash2/cluster.py  |   2 +-
 configs/splash2/run.py  |   2 +-
 src/python/m5/SimObject.py  |   2 +-
 src/python/m5/simulate.py   |  14 +++---
 src/sim/Root.py |  25 +
 tests/run.py|   2 +-
 10 files changed, 53 insertions(+), 20 deletions(-)

diffs (248 lines):

diff -r 1eb0be76e800 -r 722f2ad014a7 configs/common/Simulation.py
--- a/configs/common/Simulation.py  Tue Aug 17 05:06:22 2010 -0700
+++ b/configs/common/Simulation.py  Tue Aug 17 05:06:22 2010 -0700
@@ -190,7 +190,7 @@
 for i in xrange(np):
 testsys.cpu[i].max_insts_any_thread = offset
 
-m5.instantiate(root)
+m5.instantiate()
 
 if options.checkpoint_restore != None:
 from os.path import isdir, exists
@@ -207,7 +207,7 @@
 fatal("Unable to find checkpoint directory %s", checkpoint_dir)
 
 print "Restoring checkpoint ..."
-m5.restoreCheckpoint(root, checkpoint_dir)
+m5.restoreCheckpoint(checkpoint_dir)
 print "Done."
 elif options.simpoint:
 # assume workload 0 has the simpoint
@@ -224,7 +224,7 @@
   options.bench, options.checkpoint_restore)
 
 print "Restoring checkpoint ..."
-m5.restoreCheckpoint(root,checkpoint_dir)
+m5.restoreCheckpoint(checkpoint_dir)
 print "Done."
 else:
 dirs = listdir(cptdir)
@@ -246,8 +246,8 @@
 maxtick = maxtick - int(cpts[cpt_num - 1])
 
 ## Restore the checkpoint
-m5.restoreCheckpoint(root,
-joinpath(cptdir, "cpt.%s" % cpts[cpt_num - 1]))
+m5.restoreCheckpoint(joinpath(cptdir,
+  "cpt.%s" % cpts[cpt_num - 1]))
 
 if options.standard_switch or cpu_class:
 if options.standard_switch:
@@ -324,7 +324,7 @@
 
 if exit_event.getCause() == \
"a thread reached the max instruction count":
-m5.checkpoint(root, joinpath(cptdir, "cpt.%s.%d" % \
+m5.checkpoint(joinpath(cptdir, "cpt.%s.%d" % \
 (options.bench, checkpoint_inst)))
 print "Checkpoint written."
 num_checkpoints += 1
@@ -341,7 +341,7 @@
 exit_event = m5.simulate(when - m5.curTick())
 
 if exit_event.getCause() == "simulate() limit reached":
-m5.checkpoint(root, joinpath(cptdir, "cpt.%d"))
+m5.checkpoint(joinpath(cptdir, "cpt.%d"))
 num_checkpoints += 1
 
 sim_ticks = when
@@ -358,7 +358,7 @@
 while exit_event.getCause() == "checkpoint":
 exit_event = m5.simulate(sim_ticks - m5.curTick())
 if exit_event.getCause() == "simulate() limit reached":
-m5.checkpoint(root, joinpath(cptdir, "cpt.%d"))
+m5.checkpoint(joinpath(cptdir, "cpt.%d"))
 num_checkpoints += 1
 
 if exit_event.getCause() != "simulate() limit reached":
@@ -371,7 +371,7 @@
 exit_event = m5.simulate(maxtick)
 
 while exit_event.getCause() == "checkpoint":
-m5.checkpoint(root, joinpath(cptdir, "cpt.%d"))
+m5.checkpoint(joinpath(cptdir, "cpt.%d"))
 num_checkpoints += 1
 if num_checkpoints == max_checkpoints:
 exit_cause = "maximum %d checkpoints dropped" % max_checkpoints
@@ -385,5 +385,5 @@
 print 'Exiting @ cycle %i because %s' % (m5.curTick(), exit_cause)
 
 if options.checkpoint_at_end:
-m5.checkpoint(root, joinpath(cptdir, "cpt.%d"))
+m5.checkpoint(joinpath(cptdir, "cpt.%d"))
 
diff -r 1eb0be76e800 -r 722f2ad014a7 configs/example/memtest-ruby.py
--- a/configs/example/memtest-ruby.py   Tue Aug 17 05:06:22 2010 -0700
+++ b/configs/example/memtest-ruby.py   Tue Aug 17 05:06:22 2010 -0700
@@ -129,7 +129,7 @@
 m5.ticks.setGlobalFrequency('1ns')
 
 #

[m5-dev] changeset in m5: bus: clean up default responder code.

[Steve Reinhardt]

changeset 9c8fdcdae976 in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=9c8fdcdae976
description:
bus: clean up default responder code.
Clean up some minor things left over from the default responder
change in rev 9af6fb59752f.  Mostly renaming the 'responder_set'
param to 'use_default_range' to actually reflect what it does...
old name wasn't that descriptive in the first place, but now
it really doesn't make sense at all.

Also got rid of the bogus obsolete assignment to 'bus.responder'
which used to be a parameter but now is interpreted as an
implicit child assignment, and which was giving me problems in
the config restructuring to come.  (A good argument for not
allowing implicit child assignments, IMO, but that's water under
the bridge, I'm afraid.)

Also moved the Bus constructor to the .cc file since that's
where it should have been all along.

diffstat:

 src/dev/alpha/Tsunami.py |   3 +-
 src/dev/x86/Pc.py|   3 +-
 src/mem/Bus.py   |   9 +++
 src/mem/bus.cc   |  54 +++
 src/mem/bus.hh   |  27 +--
 5 files changed, 47 insertions(+), 49 deletions(-)

diffs (183 lines):

diff -r 84fd1726290d -r 9c8fdcdae976 src/dev/alpha/Tsunami.py
--- a/src/dev/alpha/Tsunami.py  Sat Aug 14 01:00:45 2010 -0700
+++ b/src/dev/alpha/Tsunami.py  Tue Aug 17 05:06:21 2010 -0700
@@ -96,8 +96,7 @@
 self.cchip.pio = bus.port
 self.pchip.pio = bus.port
 self.pciconfig.pio = bus.default
-bus.responder_set = True
-bus.responder = self.pciconfig
+bus.use_default_range = True
 self.fake_sm_chip.pio = bus.port
 self.fake_uart1.pio = bus.port
 self.fake_uart2.pio = bus.port
diff -r 84fd1726290d -r 9c8fdcdae976 src/dev/x86/Pc.py
--- a/src/dev/x86/Pc.py Sat Aug 14 01:00:45 2010 -0700
+++ b/src/dev/x86/Pc.py Tue Aug 17 05:06:21 2010 -0700
@@ -79,5 +79,4 @@
 self.fake_com_4.pio = bus.port
 self.fake_floppy.pio = bus.port
 self.pciconfig.pio = bus.default
-bus.responder_set = True
-bus.responder = self.pciconfig
+bus.use_default_range = True
diff -r 84fd1726290d -r 9c8fdcdae976 src/mem/Bus.py
--- a/src/mem/Bus.pySat Aug 14 01:00:45 2010 -0700
+++ b/src/mem/Bus.pyTue Aug 17 05:06:21 2010 -0700
@@ -31,9 +31,6 @@
 from m5.proxy import *
 from MemObject import MemObject
 
-if buildEnv['FULL_SYSTEM']:
-from Device import BadAddr
-
 class Bus(MemObject):
 type = 'Bus'
 port = VectorPort("vector port for connecting devices")
@@ -41,6 +38,8 @@
 clock = Param.Clock("1GHz", "bus clock speed")
 header_cycles = Param.Int(1, "cycles of overhead per transaction")
 width = Param.Int(64, "bus width (bytes)")
-responder_set = Param.Bool(False, "Did the user specify a default 
responder.")
 block_size = Param.Int(64, "The default block size if one isn't set by a 
device attached to the bus.")
-default = Port("Default port for requests that aren't handled by a 
device.")
+default = \
+Port("Default port for requests that aren't handled by a device.")
+use_default_range = \
+Param.Bool(False, "Query default port device for legal range.")
diff -r 84fd1726290d -r 9c8fdcdae976 src/mem/bus.cc
--- a/src/mem/bus.ccSat Aug 14 01:00:45 2010 -0700
+++ b/src/mem/bus.ccTue Aug 17 05:06:21 2010 -0700
@@ -40,6 +40,25 @@
 #include "base/trace.hh"
 #include "mem/bus.hh"
 
+Bus::Bus(const BusParams *p)
+: MemObject(p), busId(p->bus_id), clock(p->clock),
+  headerCycles(p->header_cycles), width(p->width), tickNextIdle(0),
+  drainEvent(NULL), busIdle(this), inRetry(false), maxId(0),
+  defaultPort(NULL), funcPort(NULL), funcPortId(-4),
+  useDefaultRange(p->use_default_range), defaultBlockSize(p->block_size),
+  cachedBlockSize(0), cachedBlockSizeValid(false)
+{
+//width, clock period, and header cycles must be positive
+if (width <= 0)
+fatal("Bus width must be positive\n");
+if (clock <= 0)
+fatal("Bus clock period must be positive\n");
+if (headerCycles <= 0)
+fatal("Number of header cycles must be positive\n");
+clearBusCache();
+clearPortCache();
+}
+
 Port *
 Bus::getPort(const std::string &if_name, int idx)
 {
@@ -310,19 +329,22 @@
 Bus::findPort(Addr addr)
 {
 /* An interval tree would be a better way to do this. --ali. */
-int dest_id = -1;
+int dest_id;
 
 dest_id = checkPortCache(addr);
-if (dest_id == -1) {
-PortIter i = portMap.find(RangeSize(addr,1));
-if (i != portMap.end()) {
-dest_id = i->second;
-updatePortCache(dest_id, i->first.start, i->first.end);
-}
+if (dest_id != -1)
+return dest_id;
+
+// Check normal port ranges
+PortIter i = portMap.find(RangeSize(addr,1));
+i

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

[Cron Daemon]

* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-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/linux/simple-timing passed.
* build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/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/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed.
* build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby 
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/00.hello/alpha/tru64/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/linux/simple-timing-ruby-MOESI_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/50.memtest/alpha/linux/memtest-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_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/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* 
build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* 
build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 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/simple-atomic passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed.
* build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing-ruby 
passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/o3-timing passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic 
passed.
* build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-timing 
passed.
* 
build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/o3-timing-mp
 passed.
* 
build/SPA