Re: [gem5-dev] Can we kill of AutoSerialize please?

[Steve Reinhardt]

Sounds good to me!  Go for it!


On Thu, Aug 6, 2015 at 9:48 AM Andreas Sandberg 
wrote:

> Hi Everyone,
>
> I have recently been spending more time than I¹d like chasing a bugs
> related to event autoserialization (Event::AutoSerialize).
>
> This is currently completely broken both for local events and global
> events. I -- cough, cough -- may have been the one breaking local events,
> but global events have been broken ever since they were introduced.
>
> I¹m leaning towards completely killing off the support for AutoSerialize.
> AFAIK, the only place where this is used is the LinkDelay event, which
> could quite easily be owned by the link and not the event queue. Doing
> this would allow us to remove the fairly complicated dynamic object
> creation code from the serialization framework and it would remove the
> need to serialize event queues. A nice side effect is that it should make
> it possible to load a checkpoint created with a multi-threaded
> (multi-threaded checkpoints currently seem to be broken) gem5 into a
> single-threaded gem5 since event queues wouldn¹t need to be serialized.
>
> Comments anyone? Steve?
>
> //Andreas
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are
> confidential and may also be privileged. If you are not the intended
> recipient, please notify the sender immediately and do not disclose the
> contents to any other person, use it for any purpose, or store or copy the
> information in any medium.  Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2557590
> ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
> Registered in England & Wales, Company No:  2548782
>
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] extending request with more attributes

[Steve Reinhardt]

So the original intent (loosely captured at
http://gem5.org/General_Memory_System#Packets) is that a Request is the
interface between the ISA and a CPU, while the Packet is what is conveyed
between two components in the memory system (the CPU and the L1 cache, or
two adjacent caches, or a cache and the memory controller).

Notice that in the ISA description language, memory accesses are conveyed
to the execution context using readMem and writeMem, which basically just
take an address and a set of Request flags---not even an actual Request
object, but the raw materials to make one  There is no "command" in a
request; you get one out-of-band bit depending on whether you call readMem
or writeMem, and every other attribute of an access must be passed as a
flag.

Note also that I'm not *defending* this interface, merely *describing* it
:).

Given this interface, though, I don't see how we can avoid adding acquire
and release flags to the Request object, as there's no other way to signal
from the instruction to the CPU that that's what's desired.  Any other
approach would really mean changing the ISA/execution context interface.

For better or for worse, all this Request stuff is largely orthogonal to
the Packet interface and its MemCmd component.  I actually kind of like how
that works with the enum, lookup table and attributes---the attributes give
you the orthogonality of being able to specify something like
NeedsExclusive that you can check as needed without comparing against a
long and ever-changing list of commands, while the enum and lookup table
mean you are only occupying a minimal amount of space in the Packet object
itself.

The downside of the orthogonality is that there's also a lot of
redundancy.  I think they're more distinct than they appear on the surface
though.  For example, the Request object doesn't have to encode anything
that's directly related to the coherence protocol, as that's out of the
scope of the ISA.  (Not so for the consistency model, though.)  Also, you
do need a fair degree of decoupling; the ISA may have generated a Request
for a write of 8 bytes, but out in the memory hierarchy that may well turn
into a ReadExReq or UpgradeReq of the cache block size.

I certainly agree that the whole system has accumulated some baggage and
could stand a good spring cleaning, if not a little downright
re-architecting.  There is a method to the madness though.

Steve



On Thu, Aug 6, 2015 at 4:22 PM Marc Orr  wrote:

> Thanks Andreas and Tony,
>
> I think I understand Andreas' original email AFTER reading Tony's response
> :-).
>
> In addition to the two options Tony suggested (enumerated below):
>
>- Use regular read/write commands but have special flags denoting them
>as ACQUIRE/RELEASE (2)
>- Or we could have multiple commands for the each of the
>sync/serializing ops with attributes denoting them as IsSynchornizing or
>IsSerializing etc (4,5)
>
> I would add:
>
>- Add a new "regular" command: FENCE. Have special flags to denote it as
>ACQUIRE/RELEASE (2)
>- Add a new "regular" command: FENCE. Use attributes to capture the
>properties of a particular FENCE command: IsAcquire, IsRelease, etc.
> (4,5)
>
> Any others?
>
> Also, on point (3) in Andreas' original email: I agree that Architecture
> specific flags are not handled very well right now. I noticed that the
> first 8 bits in request.hh (ARCH_BITS) are supposed to be architecture
> specific (according the comment at least). I wonder if those bits are
> sufficient to solve the problem that Andreas raises.
>
> Thanks,
> Marc
>
>
>
> On Thu, Aug 6, 2015 at 3:18 PM, Gutierrez, Anthony <
> anthony.gutier...@amd.com> wrote:
>
> > Thanks for this clarification, Andreas. We were mostly confused by the
> > flags, cmd, and attributes because - as you pointed out - there seems to
> be
> > a lot of overlap with no clear division between the three objects. I
> think
> > this patch is going in a good direction.
> >
> > For our particular case it seems we have a few options. Use regular
> > read/write commands but have special flags denoting them as
> ACQUIRE/RELEASE
> > (2). Or we could have multiple commands for the each of the
> > sync/serializing ops with attributes denoting them as IsSynchornizing or
> > IsSerializing etc (4,5).
> >
> > Are those suitable options? Are there other options?
> >
> > -Original Message-
> > From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas
> > Hansson
> > Sent: Thursday, August 06, 2015 4:43 PM
> > To: gem5 Developer List
> > Subject: Re: [gem5-dev] extending request with more attributes
> >
> > Hi Marc (et al),
> >
> > Have a look at http://reviews.gem5.org/r/3004/ for addressing (5) in my
> > previous mail.
> >
> > Andreas
> >
> > On 06/08/2015 10:41, "gem5-dev on behalf of Andreas Hansson"
> >  wrote:
> >
> > >Hi Marc,
> > >
> > >I would suggest the following (again, this is up for discussion):
> > >
> > >1. Request flags should the kind of propertie

Re: [gem5-dev] Review Request 3004: mem: Cleanup packet attributes and rely on command type

[Steve Reinhardt]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3004/#review6909
---


I confess to being confused by this patch---I thought the focus of the prior 
discussion was on all the flags in the Request object, but this change doesn't 
touch Request at all.

Note that, unlike Request flags, MemCmd attributes have no storage overhead, as 
they're just enum values.  So I don't think there's much savings in getting rid 
of them.  They also enable more orthogonality in the cache code.  While none of 
the removed attributes is currently used in more than one command, I think it's 
pretty easy to imagine that the Prefetch flags could get reused if we 
introduced an exclusive prefetch, or implemented the MMX non-temporal prefetch 
instructions, or some other variant form of prefetch.  It might even be the 
case that we could implement an exclusive prefetch today just by defining a new 
command that has both IsSWPrefetch and NeedsExclusive set.  (OK, it's pretty 
optimistic to think that would work out of the box, but that's the kind of 
thing this structure is supposed to enable.)

Now the Request flags are another story in more ways than one... but I'll 
respond to that on the other thread.

- Steve Reinhardt


On Aug. 6, 2015, 2:41 p.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3004/
> ---
> 
> (Updated Aug. 6, 2015, 2:41 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11004:e6aa2b4cfbef
> ---
> mem: Cleanup packet attributes and rely on command type
> 
> This patch takes one step further in cleaning up the use of packet
> command attributes, and shifts away from using attributes to
> distinguish a single command. The commands affected are software
> prefetch requests and flush requests. There is really no use for
> attributes, as no other request packets share this property.
> 
> Instead of looking at the attribute, the locations that identified
> these packets now check for the actual command.
> 
> 
> Diffs
> -
> 
>   src/mem/cache/cache_impl.hh 4413195267fd 
>   src/mem/packet.hh 4413195267fd 
>   src/mem/packet.cc 4413195267fd 
>   src/mem/ruby/system/DMASequencer.cc 4413195267fd 
>   src/mem/ruby/system/RubyPort.cc 4413195267fd 
>   src/mem/ruby/system/Sequencer.cc 4413195267fd 
> 
> Diff: http://reviews.gem5.org/r/3004/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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

Re: [gem5-dev] sparc dropped from debian

[Steve Reinhardt]

Seems like we need to look at both the costs and the benefits of dropping
support.  The costs may be low, but we'd have to figure out just how
low---are there just a few quiet users on sparc, or is it really nobody?
Second, what are the benefits?  It would eliminate some minor hassle, but
to be honest I haven't run into any cases where maintaining support for
sparc was difficult.  Meanwhile, as soon as we stop doing even the very
basic regressions we do now, it will likely become irretrievably
uncompilable.

So in short, I personally wouldn't miss it, but I'd rather not be too hasty
to jettison it just because we think we can get away with it.

Steve

On Thu, Aug 6, 2015 at 3:24 PM Joel Hestness  wrote:

> What precisely are we proposing to drop here?
>
>   Joel
>
>
> On Thu, Aug 6, 2015 at 5:02 PM, Nilay Vaish  wrote:
>
> > On Thu, 6 Aug 2015, Andreas Hansson wrote:
> >
> > Any thoughts at all on the topic, or shall we go ahead?
> >>
> >>
> > I am ok with dropping sparc.  May be we should ask on the users list as
> > well.
> >
> >
> > --
> > Nilay
> >
> > ___
> > gem5-dev mailing list
> > gem5-dev@gem5.org
> > http://m5sim.org/mailman/listinfo/gem5-dev
> >
>
>
>
> --
>   Joel Hestness
>   PhD Candidate, Computer Architecture
>   Dept. of Computer Science, University of Wisconsin - Madison
>   http://pages.cs.wisc.edu/~hestness/
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3004: mem: Cleanup packet attributes and rely on command type

[Marc Orr]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3004/#review6908
---

Ship it!


Ship It!

- Marc Orr


On Aug. 6, 2015, 9:41 p.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3004/
> ---
> 
> (Updated Aug. 6, 2015, 9:41 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11004:e6aa2b4cfbef
> ---
> mem: Cleanup packet attributes and rely on command type
> 
> This patch takes one step further in cleaning up the use of packet
> command attributes, and shifts away from using attributes to
> distinguish a single command. The commands affected are software
> prefetch requests and flush requests. There is really no use for
> attributes, as no other request packets share this property.
> 
> Instead of looking at the attribute, the locations that identified
> these packets now check for the actual command.
> 
> 
> Diffs
> -
> 
>   src/mem/cache/cache_impl.hh 4413195267fd 
>   src/mem/packet.hh 4413195267fd 
>   src/mem/packet.cc 4413195267fd 
>   src/mem/ruby/system/DMASequencer.cc 4413195267fd 
>   src/mem/ruby/system/RubyPort.cc 4413195267fd 
>   src/mem/ruby/system/Sequencer.cc 4413195267fd 
> 
> Diff: http://reviews.gem5.org/r/3004/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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

Re: [gem5-dev] extending request with more attributes

[Marc Orr]

Thanks Andreas and Tony,

I think I understand Andreas' original email AFTER reading Tony's response
:-).

In addition to the two options Tony suggested (enumerated below):

   - Use regular read/write commands but have special flags denoting them
   as ACQUIRE/RELEASE (2)
   - Or we could have multiple commands for the each of the
   sync/serializing ops with attributes denoting them as IsSynchornizing or
   IsSerializing etc (4,5)

I would add:

   - Add a new "regular" command: FENCE. Have special flags to denote it as
   ACQUIRE/RELEASE (2)
   - Add a new "regular" command: FENCE. Use attributes to capture the
   properties of a particular FENCE command: IsAcquire, IsRelease, etc. (4,5)

Any others?

Also, on point (3) in Andreas' original email: I agree that Architecture
specific flags are not handled very well right now. I noticed that the
first 8 bits in request.hh (ARCH_BITS) are supposed to be architecture
specific (according the comment at least). I wonder if those bits are
sufficient to solve the problem that Andreas raises.

Thanks,
Marc



On Thu, Aug 6, 2015 at 3:18 PM, Gutierrez, Anthony <
anthony.gutier...@amd.com> wrote:

> Thanks for this clarification, Andreas. We were mostly confused by the
> flags, cmd, and attributes because - as you pointed out - there seems to be
> a lot of overlap with no clear division between the three objects. I think
> this patch is going in a good direction.
>
> For our particular case it seems we have a few options. Use regular
> read/write commands but have special flags denoting them as ACQUIRE/RELEASE
> (2). Or we could have multiple commands for the each of the
> sync/serializing ops with attributes denoting them as IsSynchornizing or
> IsSerializing etc (4,5).
>
> Are those suitable options? Are there other options?
>
> -Original Message-
> From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas
> Hansson
> Sent: Thursday, August 06, 2015 4:43 PM
> To: gem5 Developer List
> Subject: Re: [gem5-dev] extending request with more attributes
>
> Hi Marc (et al),
>
> Have a look at http://reviews.gem5.org/r/3004/ for addressing (5) in my
> previous mail.
>
> Andreas
>
> On 06/08/2015 10:41, "gem5-dev on behalf of Andreas Hansson"
>  wrote:
>
> >Hi Marc,
> >
> >I would suggest the following (again, this is up for discussion):
> >
> >1. Request flags should the kind of properties that we would have
> >associated with page-table entries. I am thinking memory attributes
> >like uncacheable, strictly ordered, secure, etc.
> >
> >2. Request flags could also be used to distinguish packets of specific
> >types, where ‘normal’ packet commands like read/write are used, but we
> >want to be able to single out what the ‘reason’ is. Prefetch, PT walks,
> >Fetch, etc.
> >
> >3. We should try and sort out the current use of CLEAR_LL, LOCKED_RMW,
> >LLSC, MEM_SWAP, and MEM_SWAP_COND. In my view these should not really
> >be request flags, because we have specific packets to represent these
> >actions. Also, most of these are ArchSpecific and should go in the
> >ArchSpecific flags. Perhaps we just need to figure out a better way to
> >do this.
> >
> >4. Packet attributes should be common attributes shared by multiple
> >families of packet commands. Good examples are ‘NeedsResponse’,
> >‘IsRead’, ‘NeedsExclusive’ etc.
> >
> >5. Packet attributes should not be introduced if they only apply to a
> >single request/response. Thus, I think we should remove IsSWPrefetch
> >and IsHWPrefetch as an attribute.
> >
> >Does this align with your view of the world?
> >
> >Andreas
> >
> >
> >
> >On 05/08/2015 22:30, "gem5-dev on behalf of Marc Orr"
> > wrote:
> >
> >>In response to reviews http://reviews.gem5.org/r/2821/ and
> >>http://reviews.gem5.org/r/3003/.
> >>
> >>I was going to look at addressing this today for AMD. I'm not
> >>extremely familiar with the organization of the request flags, packet
> >>commands, packet attributes, and packet flags. That said, I was under
> >>the impression that the request is supposed to capture information
> >>that exist at the instruction level. To me, acquire and release are at
> >>the instruction level (not a spurious command between two memory
> >>controllers like  flush command).
> >>
> >>Also, the 32 bits that we have to work with in the request seems
> >>rather small. Especially, when you consider that it needs to capture
> >>all of the possible attributes for a memory request across all of the
> >>different ISAs...
> >>
> >>How would armv8 ldra and strl instructions convey to the cache
> >>hierarchy acquire/release attributes from the instruction (if it were
> necessary)?
> >>
> >>Thanks,
> >>Marc
> >>___
> >>gem5-dev mailing list
> >>gem5-dev@gem5.org
> >>http://m5sim.org/mailman/listinfo/gem5-dev
> >
> >
> >-- IMPORTANT NOTICE: The contents of this email and any attachments are
> >confidential and may also be privileged. If you are not the intended
> >recipient, please notify th

Re: [gem5-dev] sparc dropped from debian

[Joel Hestness]

What precisely are we proposing to drop here?

  Joel


On Thu, Aug 6, 2015 at 5:02 PM, Nilay Vaish  wrote:

> On Thu, 6 Aug 2015, Andreas Hansson wrote:
>
> Any thoughts at all on the topic, or shall we go ahead?
>>
>>
> I am ok with dropping sparc.  May be we should ask on the users list as
> well.
>
>
> --
> Nilay
>
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>



-- 
  Joel Hestness
  PhD Candidate, Computer Architecture
  Dept. of Computer Science, University of Wisconsin - Madison
  http://pages.cs.wisc.edu/~hestness/
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 3004: mem: Cleanup packet attributes and rely on command type

[Tony Gutierrez]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3004/#review6906
---

Ship it!


Ship It!

- Tony Gutierrez


On Aug. 6, 2015, 2:41 p.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3004/
> ---
> 
> (Updated Aug. 6, 2015, 2:41 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11004:e6aa2b4cfbef
> ---
> mem: Cleanup packet attributes and rely on command type
> 
> This patch takes one step further in cleaning up the use of packet
> command attributes, and shifts away from using attributes to
> distinguish a single command. The commands affected are software
> prefetch requests and flush requests. There is really no use for
> attributes, as no other request packets share this property.
> 
> Instead of looking at the attribute, the locations that identified
> these packets now check for the actual command.
> 
> 
> Diffs
> -
> 
>   src/mem/cache/cache_impl.hh 4413195267fd 
>   src/mem/packet.hh 4413195267fd 
>   src/mem/packet.cc 4413195267fd 
>   src/mem/ruby/system/DMASequencer.cc 4413195267fd 
>   src/mem/ruby/system/RubyPort.cc 4413195267fd 
>   src/mem/ruby/system/Sequencer.cc 4413195267fd 
> 
> Diff: http://reviews.gem5.org/r/3004/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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

Re: [gem5-dev] extending request with more attributes

[Gutierrez, Anthony]

Thanks for this clarification, Andreas. We were mostly confused by the flags, 
cmd, and attributes because - as you pointed out - there seems to be a lot of 
overlap with no clear division between the three objects. I think this patch is 
going in a good direction.

For our particular case it seems we have a few options. Use regular read/write 
commands but have special flags denoting them as ACQUIRE/RELEASE (2). Or we 
could have multiple commands for the each of the sync/serializing ops with 
attributes denoting them as IsSynchornizing or IsSerializing etc (4,5).

Are those suitable options? Are there other options?

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Hansson
Sent: Thursday, August 06, 2015 4:43 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] extending request with more attributes

Hi Marc (et al),

Have a look at http://reviews.gem5.org/r/3004/ for addressing (5) in my 
previous mail.

Andreas

On 06/08/2015 10:41, "gem5-dev on behalf of Andreas Hansson"
 wrote:

>Hi Marc,
>
>I would suggest the following (again, this is up for discussion):
>
>1. Request flags should the kind of properties that we would have 
>associated with page-table entries. I am thinking memory attributes 
>like uncacheable, strictly ordered, secure, etc.
>
>2. Request flags could also be used to distinguish packets of specific 
>types, where ‘normal’ packet commands like read/write are used, but we 
>want to be able to single out what the ‘reason’ is. Prefetch, PT walks, 
>Fetch, etc.
>
>3. We should try and sort out the current use of CLEAR_LL, LOCKED_RMW, 
>LLSC, MEM_SWAP, and MEM_SWAP_COND. In my view these should not really 
>be request flags, because we have specific packets to represent these 
>actions. Also, most of these are ArchSpecific and should go in the 
>ArchSpecific flags. Perhaps we just need to figure out a better way to 
>do this.
>
>4. Packet attributes should be common attributes shared by multiple 
>families of packet commands. Good examples are ‘NeedsResponse’, 
>‘IsRead’, ‘NeedsExclusive’ etc.
>
>5. Packet attributes should not be introduced if they only apply to a 
>single request/response. Thus, I think we should remove IsSWPrefetch 
>and IsHWPrefetch as an attribute.
>
>Does this align with your view of the world?
>
>Andreas
>
>
>
>On 05/08/2015 22:30, "gem5-dev on behalf of Marc Orr"
> wrote:
>
>>In response to reviews http://reviews.gem5.org/r/2821/ and 
>>http://reviews.gem5.org/r/3003/.
>>
>>I was going to look at addressing this today for AMD. I'm not 
>>extremely familiar with the organization of the request flags, packet 
>>commands, packet attributes, and packet flags. That said, I was under 
>>the impression that the request is supposed to capture information 
>>that exist at the instruction level. To me, acquire and release are at 
>>the instruction level (not a spurious command between two memory 
>>controllers like  flush command).
>>
>>Also, the 32 bits that we have to work with in the request seems 
>>rather small. Especially, when you consider that it needs to capture 
>>all of the possible attributes for a memory request across all of the 
>>different ISAs...
>>
>>How would armv8 ldra and strl instructions convey to the cache 
>>hierarchy acquire/release attributes from the instruction (if it were 
>>necessary)?
>>
>>Thanks,
>>Marc
>>___
>>gem5-dev mailing list
>>gem5-dev@gem5.org
>>http://m5sim.org/mailman/listinfo/gem5-dev
>
>
>-- IMPORTANT NOTICE: The contents of this email and any attachments are 
>confidential and may also be privileged. If you are not the intended 
>recipient, please notify the sender immediately and do not disclose the 
>contents to any other person, use it for any purpose, or store or copy 
>the information in any medium.  Thank you.
>
>ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
>Registered in England & Wales, Company No:  2557590 ARM Holdings plc, 
>Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in 
>England & Wales, Company No:  2548782 
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590 ARM Holdings plc, Registered office 
110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company 
No:  2548782 ___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
__

Re: [gem5-dev] Review Request 3003: mem: Remove extraneous acquire/release flags and attributes

[Tony Gutierrez]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3003/#review6907
---

Ship it!


Ship It!

- Tony Gutierrez


On Aug. 5, 2015, 1:51 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3003/
> ---
> 
> (Updated Aug. 5, 2015, 1:51 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11001:5b78d01bf635
> ---
> mem: Remove extraneous acquire/release flags and attributes
> 
> This patch removes the extraneous flags and attributes from the
> request and packet, and simply leaves the new commands. The change
> introduced when adding acquire/release breaks all compatibility with
> existing traces, and there is really no need for any new flags and
> attributes. The commands should be sufficient.
> 
> This patch fixes packet tracing (urgent), and also removes the
> unnecessary complexity.
> 
> 
> Diffs
> -
> 
>   src/mem/packet.hh cd22d66592bf 
>   src/mem/packet.cc cd22d66592bf 
>   src/mem/request.hh cd22d66592bf 
> 
> Diff: http://reviews.gem5.org/r/3003/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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

Re: [gem5-dev] sparc dropped from debian

[Nilay Vaish]

On Thu, 6 Aug 2015, Andreas Hansson wrote:


Any thoughts at all on the topic, or shall we go ahead?



I am ok with dropping sparc.  May be we should ask on the users list as 
well.



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

Re: [gem5-dev] sparc dropped from debian

[Andreas Hansson]

Any thoughts at all on the topic, or shall we go ahead?

Andreas

On 28/07/2015 08:45, "gem5-dev on behalf of Andreas Hansson"
 wrote:

>Hi all,
>
>https://lists.debian.org/debian-sparc/2015/07/msg00012.html
>
>Given the discussion at the user conference, perhaps we should follow
>suit.
>
>Any objections?
>
>Andreas
>
>
>-- IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended
>recipient, please notify the sender immediately and do not disclose the
>contents to any other person, use it for any purpose, or store or copy
>the information in any medium. Thank you.
>
>ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>Registered in England & Wales, Company No: 2557590
>ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>Registered in England & Wales, Company No: 2548782
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2548782
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] extending request with more attributes

[Andreas Hansson]

Hi Marc (et al),

Have a look at http://reviews.gem5.org/r/3004/ for addressing (5) in my
previous mail.

Andreas

On 06/08/2015 10:41, "gem5-dev on behalf of Andreas Hansson"
 wrote:

>Hi Marc,
>
>I would suggest the following (again, this is up for discussion):
>
>1. Request flags should the kind of properties that we would have
>associated with page-table entries. I am thinking memory attributes like
>uncacheable, strictly ordered, secure, etc.
>
>2. Request flags could also be used to distinguish packets of specific
>types, where ‘normal’ packet commands like read/write are used, but we
>want to be able to single out what the ‘reason’ is. Prefetch, PT walks,
>Fetch, etc.
>
>3. We should try and sort out the current use of CLEAR_LL, LOCKED_RMW,
>LLSC, MEM_SWAP, and MEM_SWAP_COND. In my view these should not really be
>request flags, because we have specific packets to represent these
>actions. Also, most of these are ArchSpecific and should go in the
>ArchSpecific flags. Perhaps we just need to figure out a better way to do
>this.
>
>4. Packet attributes should be common attributes shared by multiple
>families of packet commands. Good examples are ‘NeedsResponse’, ‘IsRead’,
>‘NeedsExclusive’ etc.
>
>5. Packet attributes should not be introduced if they only apply to a
>single request/response. Thus, I think we should remove IsSWPrefetch and
>IsHWPrefetch as an attribute.
>
>Does this align with your view of the world?
>
>Andreas
>
>
>
>On 05/08/2015 22:30, "gem5-dev on behalf of Marc Orr"
> wrote:
>
>>In response to reviews http://reviews.gem5.org/r/2821/ and
>>http://reviews.gem5.org/r/3003/.
>>
>>I was going to look at addressing this today for AMD. I'm not extremely
>>familiar with the organization of the request flags, packet commands,
>>packet attributes, and packet flags. That said, I was under the
>>impression
>>that the request is supposed to capture information that exist at the
>>instruction level. To me, acquire and release are at the instruction
>>level
>>(not a spurious command between two memory controllers like  flush
>>command).
>>
>>Also, the 32 bits that we have to work with in the request seems rather
>>small. Especially, when you consider that it needs to capture all of the
>>possible attributes for a memory request across all of the different
>>ISAs...
>>
>>How would armv8 ldra and strl instructions convey to the cache hierarchy
>>acquire/release attributes from the instruction (if it were necessary)?
>>
>>Thanks,
>>Marc
>>___
>>gem5-dev mailing list
>>gem5-dev@gem5.org
>>http://m5sim.org/mailman/listinfo/gem5-dev
>
>
>-- IMPORTANT NOTICE: The contents of this email and any attachments are
>confidential and may also be privileged. If you are not the intended
>recipient, please notify the sender immediately and do not disclose the
>contents to any other person, use it for any purpose, or store or copy
>the information in any medium.  Thank you.
>
>ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>Registered in England & Wales, Company No:  2557590
>ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,
>Registered in England & Wales, Company No:  2548782
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2548782
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] Review Request 3004: mem: Cleanup packet attributes and rely on command type

[Andreas Hansson]

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

Review request for Default.


Repository: gem5


Description
---

Changeset 11004:e6aa2b4cfbef
---
mem: Cleanup packet attributes and rely on command type

This patch takes one step further in cleaning up the use of packet
command attributes, and shifts away from using attributes to
distinguish a single command. The commands affected are software
prefetch requests and flush requests. There is really no use for
attributes, as no other request packets share this property.

Instead of looking at the attribute, the locations that identified
these packets now check for the actual command.


Diffs
-

  src/mem/cache/cache_impl.hh 4413195267fd 
  src/mem/packet.hh 4413195267fd 
  src/mem/packet.cc 4413195267fd 
  src/mem/ruby/system/DMASequencer.cc 4413195267fd 
  src/mem/ruby/system/RubyPort.cc 4413195267fd 
  src/mem/ruby/system/Sequencer.cc 4413195267fd 

Diff: http://reviews.gem5.org/r/3004/diff/


Testing
---


Thanks,

Andreas Hansson

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

[gem5-dev] Can we kill of AutoSerialize please?

[Andreas Sandberg]

Hi Everyone,

I have recently been spending more time than I¹d like chasing a bugs
related to event autoserialization (Event::AutoSerialize).

This is currently completely broken both for local events and global
events. I -- cough, cough -- may have been the one breaking local events,
but global events have been broken ever since they were introduced.

I¹m leaning towards completely killing off the support for AutoSerialize.
AFAIK, the only place where this is used is the LinkDelay event, which
could quite easily be owned by the link and not the event queue. Doing
this would allow us to remove the fairly complicated dynamic object
creation code from the serialization framework and it would remove the
need to serialize event queues. A nice side effect is that it should make
it possible to load a checkpoint created with a multi-threaded
(multi-threaded checkpoints currently seem to be broken) gem5 into a
single-threaded gem5 since event queues wouldn¹t need to be serialized.

Comments anyone? Steve?

//Andreas


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2548782

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

Re: [gem5-dev] Review Request 2994: cpu: Change thread assignents for heterogenous SMT

[Alexandru Dutu]

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2994/#review6905
---



src/sim/system.hh (line 199)


Not sure I understand why this is needed, it seems one can already figure 
out if it is a multi-threaded system configured by checking numThreads.


- Alexandru Dutu


On July 30, 2015, 6:46 p.m., Curtis Dunham wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2994/
> ---
> 
> (Updated July 30, 2015, 6:46 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Trying to run an SE system with varying threads per core (SMT cores + Non-SMT
> cores) caused failures due to the CPU id assignment logic.  The comment
> about thread assignment (worrying about core 0 not having tid 0) seems
> not to be valid given that our configuration scripts initialize them in
> order.
> 
> This removes that constraint so a heterogenously threaded sytem can work.
> 
> 
> Diffs
> -
> 
>   src/cpu/base.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/sim/System.py 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/sim/system.hh 40526b73c7db9ff2e03215cdfb477d024ea8d709 
>   src/sim/system.cc 40526b73c7db9ff2e03215cdfb477d024ea8d709 
> 
> Diff: http://reviews.gem5.org/r/2994/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Curtis Dunham
> 
>

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

Re: [gem5-dev] Review Request 3003: mem: Remove extraneous acquire/release flags and attributes

[Andreas Hansson]

> On Aug. 5, 2015, 9:26 p.m., Marc Orr wrote:
> > Hey Andreas,
> > 
> > Go ahead and ship this. But I would appreciate your thoughts on my comment. 
> > I will move that over to an email thread on gem5-dev. Simply put, we need 
> > to get this information down to the cache controllers, and I would like to 
> > do it in a way that everyone is happy with and can even leverage in their 
> > own work.
> > 
> > Thanks,
> > Marc

I responded to the mail. I think we can work this out without adding request 
flags and packet attributes. I'll go ahead and push this for now, and then we 
can converge on the mailing list.


- Andreas


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/3003/#review6903
---


On Aug. 5, 2015, 8:51 a.m., Andreas Hansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/3003/
> ---
> 
> (Updated Aug. 5, 2015, 8:51 a.m.)
> 
> 
> Review request for Default.
> 
> 
> Repository: gem5
> 
> 
> Description
> ---
> 
> Changeset 11001:5b78d01bf635
> ---
> mem: Remove extraneous acquire/release flags and attributes
> 
> This patch removes the extraneous flags and attributes from the
> request and packet, and simply leaves the new commands. The change
> introduced when adding acquire/release breaks all compatibility with
> existing traces, and there is really no need for any new flags and
> attributes. The commands should be sufficient.
> 
> This patch fixes packet tracing (urgent), and also removes the
> unnecessary complexity.
> 
> 
> Diffs
> -
> 
>   src/mem/packet.hh cd22d66592bf 
>   src/mem/packet.cc cd22d66592bf 
>   src/mem/request.hh cd22d66592bf 
> 
> Diff: http://reviews.gem5.org/r/3003/diff/
> 
> 
> Testing
> ---
> 
> 
> Thanks,
> 
> Andreas Hansson
> 
>

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

Re: [gem5-dev] extending request with more attributes

[Andreas Hansson]

Hi Marc,

I would suggest the following (again, this is up for discussion):

1. Request flags should the kind of properties that we would have
associated with page-table entries. I am thinking memory attributes like
uncacheable, strictly ordered, secure, etc.

2. Request flags could also be used to distinguish packets of specific
types, where ‘normal’ packet commands like read/write are used, but we
want to be able to single out what the ‘reason’ is. Prefetch, PT walks,
Fetch, etc.

3. We should try and sort out the current use of CLEAR_LL, LOCKED_RMW,
LLSC, MEM_SWAP, and MEM_SWAP_COND. In my view these should not really be
request flags, because we have specific packets to represent these
actions. Also, most of these are ArchSpecific and should go in the
ArchSpecific flags. Perhaps we just need to figure out a better way to do
this.

4. Packet attributes should be common attributes shared by multiple
families of packet commands. Good examples are ‘NeedsResponse’, ‘IsRead’,
‘NeedsExclusive’ etc.

5. Packet attributes should not be introduced if they only apply to a
single request/response. Thus, I think we should remove IsSWPrefetch and
IsHWPrefetch as an attribute.

Does this align with your view of the world?

Andreas



On 05/08/2015 22:30, "gem5-dev on behalf of Marc Orr"
 wrote:

>In response to reviews http://reviews.gem5.org/r/2821/ and
>http://reviews.gem5.org/r/3003/.
>
>I was going to look at addressing this today for AMD. I'm not extremely
>familiar with the organization of the request flags, packet commands,
>packet attributes, and packet flags. That said, I was under the impression
>that the request is supposed to capture information that exist at the
>instruction level. To me, acquire and release are at the instruction level
>(not a spurious command between two memory controllers like  flush
>command).
>
>Also, the 32 bits that we have to work with in the request seems rather
>small. Especially, when you consider that it needs to capture all of the
>possible attributes for a memory request across all of the different
>ISAs...
>
>How would armv8 ldra and strl instructions convey to the cache hierarchy
>acquire/release attributes from the instruction (if it were necessary)?
>
>Thanks,
>Marc
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2548782
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

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

[Cron Daemon]

* build/ALPHA/tests/opt/quick/se/01.hello-2T-smt/alpha/linux/o3-timing 
passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-atomic 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/minor-timing passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-atomic-mp 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual
 passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/30.eio-mp/alpha/eio/simple-timing-mp 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-atomic 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing 
passed.
* 
build/ALPHA/tests/opt/quick/fs/10.linux-boot/alpha/linux/tsunami-simple-timing-dual
 passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/minor-timing passed.
* build/ALPHA/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby 
passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/50.vortex/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/tru64/simple-atomic passed.
* build/ALPHA/tests/opt/quick/se/00.hello/alpha/linux/o3-timing passed.
* build/ALPHA/tests/opt/quick/se/20.eio-short/alpha/eio/simple-timing 
passed.
* build/ALPHA/tests/opt/quick/se/70.twolf/alpha/tru64/simple-timing passed.
* build/ALPHA/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby passed.
* build/ALPHA/tests/opt/quick/se/30.eon/alpha/tru64/simple-atomic passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer
 passed.
* 
build/ALPHA_MOESI_hammer/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer
 passed.
* 
build/ALPHA/tests/opt/quick/fs/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MESI_Two_Level/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MESI_Two_Level
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_directory/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_directory
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token
 passed.
* 
build/ALPHA_MOESI_CMP_token/tests/opt/quick/se/50.memtest/alpha/linux/memtest-ruby-MOESI_CMP_token
 passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-atomic passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing passed.
* build/MIPS/tests/opt/quick/se/00.hello/mips/linux/o3-timing passed.
 * build/MIPS/tests/opt/quick/se/00.hello/mips/linux/simple-timing-ruby 
passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-simple-mem passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest-filter passed.
* build/NULL/tests/opt/quick/se/50.memtest/null/none/memtest passed.
* build/NULL/tests/opt/quick/se/70.tgen/null/none/tgen-dram-ctrl passed.
* build/POWER/tests/opt/quick/se/00.hello/power/linux/o3-timing passed.
* build/POWER/tests/opt/quick/se/00.hello/power/linux/simple-atomic passed.
* build/SPARC/tests/opt/quick/se/00.hello/sparc/linux/sim