On Sat, 9 May 2015, Joel Hestness wrote:
Hi guys,
@Nilay: Thanks for clarifying the desired MachineType usage.
I understand the aims now, and I still disagree with statically defined
MachineTypes. SLICC is already very powerful, and it only makes sense to
add features, not contract them. In this case, scons and SLICC already do
the following for us: (1) they allow dynamically extending the list of
protocols in any SConscript ('all_protocols' variable), (2) they traverse
all directories to find all protocol-related files, and (3) they generate
all the MachineType code. This is nearly everything we need!
So, it seems that we're divided on whether we should "just make
MachineTypes work" or "do this the right way". I spent a little time today
to assemble a patch that dynamically generates the MachineType enum from
the superset of all protocol controller definitions. Here it is:
http://reviews.gem5.org/r/2773/
Overall, I feel that the vision should be that SLICC be able to generate
and build any/all protocols in a single build operation (like gem5's SE+FS
mode merge). I suspect that direction will involve eliminating statically
defined types, since they often need to be updated per-protocol, which
tends to cause merge headaches.
Joel
Joel, AMD might have used machine types for which no definition exists in
any of the protocols. This used to happen in erstwhile
GenericMachineType.
To everyone,
I am not in favor of committing Joel's patch or the one I wrote (which is
why I had taken it off the reviewboard). We should not add protocol
specific code to files that are not protocol-specific. Such code should
reside in protocol specific .sm files. If required, SLICC should be
modified. I am unable to think of any technical difficulty that prevents
us from adding statistical variables to .sm files. We already have cache
hits and misses being collected in .sm files.
I am not in favor of the argument that we should stick to same way as
things were done in past. If in past something was done incorrectly /
inefficiently / not-correct-completely, we should be willing to change it.
In the current context, protocol-specific code in protocol-independent
files was not the right thing to do. Therefore, we should be unwilling to
allow such code.
--
Nilay
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
