Hey folks, here are some of my thoughts on the SimObject() mechanism in
SCons, and the structure of the m5.objects package.
Right now, when you put a SimObject('foo.py') line in a SConscript, that
eventually leads to SCons importing foo.py (with some special machinery)
and discovering through python what SimObjects, etc, are declared in that
file. Those are collected into lists, and then each SimObject gets a
params/Foo.hh, params/Bar.hh, etc.
Then as far as m5.objects, each file declared with SimObject() ends up as a
subpackage, with the stuff inside it available as you would expect, ie
m5.objects.Foo.Bar and m5.objects.Foo.Foo. Also, all the SimObjects are
artificially put under m5.objects so that:
from m5.objects import *
will get everything.
First, having a single SimObject() which can produce an arbitrary number of
actual SimObject subclasses, enums, etc, is problematic for SCons. SCons
only does one pass, where you have to tell it all of what files come from
what files, and then tell it to build. That means that SimObject() files
*must* be read in during the build setup phase, since we have to figure out
what files they would produce. It would be much more convenient to be able
to delay that and do that as part of the actual build. That would let us,
for example, build the marshal binary as a build product and not as part of
setting up the build process itself.
Second, something that I've brought up in the past is that having no
hierarchy in m5.objects is not ideal. That leads to SimObjects having
namespace information built into their name like "X86TLB", "ARMTLB", etc.
This makes things more verbose, and hides structure. It also increases the
likelihood of name collisions since everything is jammed into the same
space.
To help solve both of those problems, I'd like to propose changing
SimObject() to have an __all__ type parameter which specifies what inside
it to export, and what to export it as. It would also need to encode what
type of entity something is as well, so we know if we need to define an
enum, a SimObject, etc. Perhaps something like this:
SimObject('foo.py', ['objects.x86.TLB', 'objects.x86.LocalApic',
'enum.MyFavoriteEnum'])
That would tell SCons what targets to set up for, and also how to structure
the m5.objects package.
import m5.objects.x86
Foo.tlb = x86.TLB()
class Example(SimObject):
tlb = Param.x86.TLB(...)
This would be a major departure from how imports have worked. It would
mostly be mechanical when SimObjects are imported directly, but would make
"from m5.objects import *" impossible.
It would also probably also mean the params/ headers would be slightly more
complex, and would need to be something like:
#include "params/x86/TLB.hh"
instead of:
#include "params/X86TLB.hh"
What do folks think?
Gabe
_______________________________________________
gem5-dev mailing list -- [email protected]
To unsubscribe send an email to [email protected]
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
