Thanks Nilay,

That got me a bit further. I seem to be able to run single threaded
applications without a problem with x86 and Ruby now, however, like you
said, more than one CPU doesn't seem to work.

If anyone is interested, I think I tracked it down to an issue with the
atomic operations, but I can't (or don't have time) trace it beyond that.

Thanks!
Jason


------
Jason Power
University of Wisconsin-Madison,
Department of Computer Sciences
[email protected]




On Thu, Aug 25, 2011 at 11:01 AM, Nilay <[email protected]> wrote:

> On Thu, August 25, 2011 9:44 am, Jason Power wrote:
> > Thanks Nilay!
> >
> > I may just be misreading, but it seems like the change you sent me is the
> > same as it was before. Was that a typo?
>
> Two lines that appear inside the if block (preceded by -), have to be
> moved outside the if block (preceded by +). With this change, IIRC, hello
> world runs correctly for O3 + ruby.
>
> >
> > Do you know in general what the issue with Ruby+O3 is? If it's not a
> major
> > re-working of the code I can probably sink some time into it and try to
> > get
> > this working.
>
> Brad Beckmann commented on Ruby+O3 in a separate thread yesterday. As I
> understand, Ruby needs to inform the CPU about the invalidations so that
> speculative loads and stores can be prevented from being committed.
> Personally, I am unsure about the effort involved in making Ruby and O3
> work together for more than one CPU, mostly because I do not have any
> understanding of the implementation of the O3 CPU model.
>
> > On Wed, Aug 24, 2011 at 8:17 PM, Nilay <[email protected]> wrote:
> >
> >> On Wed, August 24, 2011 4:38 pm, Jason Power wrote:
> >> > Hi all,
> >> >
> >> > I'm trying to use the out of order processor model with x86 ISA in SE
> >> > mode.
> >> > When I try to run my applications I get a segfault because the dynamic
> >> > cast
> >> > on line 1111 of lsq_unit_impl.hh returns null. If I change the cast
> >> from
> >> > dynamic to static then the simulator runs for a little bit longer, but
> >> > then
> >> > prints "Exiting @ tick 9223372036854775807 because simulate() limit
> >> > reached"
> >> >
> >> > Tracing the object that is dynamically cast in line 1111 of
> >> > lsq_unit_impl.hh
> >> > (retryPkt->senderState) it seems to be set correctly in line 745.
> >> >
> >> > Has anyone had any success with this configuration (O3CPU, x86, SE)?
> >> >
> >> > Or has anyone already fixed this? Are there any suggestions for where
> >> I
> >> > should look?
> >> >
> >>
> >> As per the status matrix on gem5.org, the combination should work for a
> >> uniprocessor system. o3 currently does not work with ruby, though this
> >> change in lsq_unit_impl.hh should take you farther.
> >>
> >> +        LSQSenderState *state =
> >> +            dynamic_cast<LSQSenderState *>(retryPkt->senderState);
> >> +
> >>         if (dcachePort->sendTiming(retryPkt)) {
> >> -            LSQSenderState *state =
> >> -                dynamic_cast<LSQSenderState *>(retryPkt->senderState);
> >> -
> >>
>
> --
> Nilay
>
>
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to