Nice!  I didn't have time to read all the code closely, but I did notice a few things, and wanted to give feedback before I forgot.

Basically the comments boil down to three things:

1. There are several pieces (Named, TickedModule, maybe the Expr stuff) that look more broadly useful, and it would be nice not to bury them inside of the CPU model
2. The report() functionality, at least, looks similar to methods on other objects like dump() and print(); we might want to standardize on this
3. A few minor (no pun intended) places where there are formatting inconsistencies with undocumented gem5 conventions

As far as #3, I'd be glad to update the coding style page appropriately if people agree that the things I've called out below should be standardized.

Where does the name come from?  Will you be committing a 'Major' model in the future?

src/cpu/minor/Expr.py (Diff revision 1)

This is pretty interesting... it would be nice to generalize this capability and not make it Minor-specific

1. Andrew Bardsley June 5, 2014, 3:06 a.m. (June 5, 2014, 3:06 a.m.)

   Yeah.  MinorExpr could easily be hoisted upwards and lose its Minor prefix (It doesn't have any dependencies on Minor).
   
   Maybe TimingExpr or something like that (to disambiguate and suggest its function a bit more) would be a good name? 

2. Andrew Bardsley June 18, 2014, 1:38 a.m. (June 18, 2014, 1:38 a.m.)

   In r2: I've moved Minor::Expr up to be in src/cpu as TimingExpr

src/cpu/minor/cpu.hh (Diff revision 1)

I don't know why, and I know it's not in the style guide, but all the gem5 code I've seen (or written) has the colon at the beginning of the second line, not the end of the first... might as well be consistent

1. Andrew Bardsley June 5, 2014, 3:06 a.m. (June 5, 2014, 3:06 a.m.)

   I've run a couple of regexps over the codebase (quick and dirty, not checked all the matches):
   
   '^ * : [a-z]' (next line :)  257 lines
   '\) :'$ (trailing :) 394 lines
   
   If you drop uses in src/arch/... (as the archs seem to have slightly more fast and loose enforcement of the style rules):
   
   next line: 231 lines
   trailing: 125 lines
   
   So next line seems to be winning.
   
   I have no real preference.
   Do you want to add this to the style guide?

2. Steve Reinhardt July 1, 2014, 11:05 a.m. (July 1, 2014, 11:05 a.m.)

   Hmm, I get significantly different numbers:
   
   % find src -type f | xargs grep ') :$' | wc -l
   321
   % find src -type f | xargs grep '^ * : \w' | wc -l
   859
   % find src -type f | xargs grep ') :$' | grep -v '^src/arch/' | wc -l
   53
   % find src -type f | xargs grep '^ * : \w' | grep -v '^src/arch/' | wc -l
   618
   
   So not counting src/arch, it's pretty overwhelming in favor of next line.  I'd be fine with standardizing on that, but I don't know if anyone else cares.
   
   And just for grins....
   
   % find src -type f | xargs grep ') :$' | grep '^src/arch/' | perl -ne '@F = split("/"); print $F[2], "\n";' | uniq -c
         1 alpha
        28 sparc
       134 arm
        84 x86
        19 mips
         2 generic
   
   

src/cpu/minor/decode.cc (Diff revision 1)

another implicit, undocumented consistency thing: continued arg lists get indented to the opening paren, not just four spaces

1. Andrew Bardsley June 5, 2014, 3:06 a.m. (June 5, 2014, 3:06 a.m.)

   Erm, yeah, I really strongly disagree with hanging arguments.  I find they waste too much space (and break my indentation fascist person rule about always indenting exactly once and always the same size, but that's my psychological problem to deal with ;) ).
   
   I throw myself of the mercy of the style enforcement court and plea for hanging arguments *not* become an explicit style rule.

src/cpu/minor/dyn_inst.hh (Diff revision 1)

I'd put a paren at the beginning of this expression, then indent so all the lines start one column past the paren... keeps the assignment '=' from blending in with all the '=='

1. Andrew Bardsley June 5, 2014, 3:06 a.m. (June 5, 2014, 3:06 a.m.)

   Yeah, that line could be *much* clearer.  I've put parens around the whole expression.  Are parens around equality/inequality tests preferred as well?  I've seen cases in the codebase.

src/cpu/minor/scoreboard.cc (Diff revision 1)

space after for

1. Andrew Bardsley June 5, 2014, 3:06 a.m. (June 5, 2014, 3:06 a.m.)

   Yep

src/cpu/minor/scoreboard.cc (Diff revision 1)

opening brace at end of previous line (here & a few places below)

1. Andrew Bardsley June 5, 2014, 3:06 a.m. (June 5, 2014, 3:06 a.m.)

   There are lots of those.  They're following the explicitly allowable case where the condition is longer than a line.
   
   There may be some wild cases left where a modified condition *does* now fit on the line but may still be split (for unjustifiable reasons) but I've spent quite a bit of time cleaning those before the patch was submitted.

src/cpu/minor/ticked.hh (Diff revision 1)

This seems like it could be useful outside of Minor... perhaps we should put it in src/sim, or even just integrate this functionality with ClockedObject

1. Andrew Bardsley June 5, 2014, 3:06 a.m. (June 5, 2014, 3:06 a.m.)

   Yes, the 'evaluate' member function on Ticked could be hoisted up to ClockedObject.  The cycle accounting in TickedModule could potentially also go that way.  I didn't make that change as I didn't want to try and have the interface blessed/promoted by trying to affect a core class (and set precedent and pass the tighter review that that demands).
   
   You can see, in Ticked, my preference for building 'interface'-like classes and using multiple inheritance for interface-link classes.
   In this case, Ticked isn't used (any more, it was previously) in contexts where the 'virtual' qualification on its member functions is used anymore, so arguably it isn't really functioning as a base class anymore.
   
   I would suggest dropping Ticked and just folding its member functions into Stage and TickedModule. (I don't believe 'Ticked */&' is ever used)

2. Andrew Bardsley June 18, 2014, 1:38 a.m. (June 18, 2014, 1:38 a.m.)

   In r2: In the end I didn't remove Ticked.  It felt wrong to remove such an obviously 'base'/interface definition.

src/cpu/minor/ticked.hh (Diff revision 1)

We also have various objects that have dump() or print() methods... it would be nice to standardize this

1. Andrew Bardsley June 5, 2014, 3:06 a.m. (June 5, 2014, 3:06 a.m.)

   Actually, report is specifically used here for MinorTrace.  Its name possibly should reflect just that. Maybe Ticked should have been be MinorTicked?  ...::report should almost certainly really be ...::minorTrace to reflect this specialised use.
   
   I think there are three interesting opportunities here:
   
   1) Standardise a name/maybe some flags for micro-architectural dumping
   2) Standardise a format for human-readable dump
   3) Standardise a format for machine-readable dump
   
   MinorTrace is horribly verbose but a it's a crack at doing point 3.

2. Andrew Bardsley June 18, 2014, 1:38 a.m. (June 18, 2014, 1:38 a.m.)

   In r2: I've renamed 'report' to 'minorTrace' to reflect its very specific role in Minor.

src/cpu/minor/ticked.hh (Diff revision 1)

integrating with ClockedObject would eliminate the multiple inheritance... not that MI is totally evil, but it's always better to avoid it when possible

1. Andrew Bardsley June 5, 2014, 3:06 a.m. (June 5, 2014, 3:06 a.m.)

   I think I've answered that one above.

2. Andrew Bardsley June 18, 2014, 1:38 a.m. (June 18, 2014, 1:38 a.m.)

   In r2: see above

src/cpu/minor/trace.hh (Diff revision 1)

This would be very useful outside of Minor... should go in src/base/trace.hh, IMO

1. Andrew Bardsley June 5, 2014, 3:06 a.m. (June 5, 2014, 3:06 a.m.)

   Yes, it would and it could be used to clean up some of annoying ambiguities around DPRINTF use and maybe even replace the DPRINTF macros with functions.
   
   Using Named to replace _name/name in SimObject would sort of open up the interface-like MI question.  (Named isn't actually an interface as it has a data member).
   
   I suggest moving Named into src/base/trace.hh so it can be optionally used, but not go as far as trying to strongly suggest its usage by making SimObject adopt it.  Thoughts?

2. Andrew Bardsley June 18, 2014, 1:38 a.m. (June 18, 2014, 1:38 a.m.)

   In r2: I've moved Named into src/base/trace.hh as another convenience definition (alongside StringWrap).

src/cpu/static_inst.hh (Diff revision 1)

blank line here would be nice

1. Andrew Bardsley June 5, 2014, 3:06 a.m. (June 5, 2014, 3:06 a.m.)

   Before SymbolTable?  Yes.
   
   A small style question:  What's should be the preferred form for namespaces?  I've seen both brace location options used and I've gone with next-line braces for all uses of namespaces as they are large scale structures.  The use of namespace in static_inst.hh is really just a fancy (and unfortunately required) way of building a reference to a class, should putting the brace on the same line be the preferred form for this one-liner? (As with Trace::InstRecord).  If this isn't already in the style guide, maybe it should be.

2. Steve Reinhardt July 1, 2014, 11:28 a.m. (July 1, 2014, 11:28 a.m.)

   Good questions.  I don't have a strong opinion.  Arguably we always put the opening brace on a separate line for other top-level block constructs (class and function definitions) so I'd lean towards saying that namespaces should do the same for consistency.  I'm open to other arguments though.  Whatever we come up with, it probably should go in the style guide.

Last chance for comments?

Looks good, thanks for all the changes.

One question: in your email you said that Ticked was separate so it could be "added to objects which are already SimObjects/don't want to be SimObjects".  I get the latter, but in the former case, is there a reason not to just make those objects derive from TickedObject now?