Quoting nathan binkert <[email protected]>:
0x20: IntegerOperate('addq', 'Rc = Ra + Rb_or_imm;')
We can make this work:
0x20: IntegerOperate.addq('Rc = Ra + Rb_or_imm;')
We could even make this work:
0x20: IntegerOperate.addq(R.c = R.a + R.b.imm)
Of course, then you're getting into magic land :)
There are a couple of reasons I like actually declaring classes for
the different instructions. First, you can have inheritance, and you
can also override select things on a per instruction basis. Second,
I'd like to see, say, all the integer instructions get defined
adjacent to the machinery that they use. If we had an IntegerOp class
and the IntegerOpCc class inherited from it and the Add class
inherited from that, we could put all that in one place so it would be
easy to look up what different things were doing. It's also a bit less
verbose. If you have 1 instruction having IntegerOp in front isn't
that much clutter. When you have 200, the little bits add up.
If we use execfile to execute the isa parser stuff, then we can have
default values for unknown variables (as of python 2.4 the dict can be
any mapping object):
class default(object):
def __call__(self, *args, **kwargs):
print args, kwargs
class Dict(dict):
def __getitem__(self, name):
try:
return dict.__getitem__(self, name)
except KeyError:
val = default()
self[name] = val
return val
d = Dict()
exec "asdf(99)" in d
The python sorcery/python library design aspect of this is where my
past efforts at this have come apart. Help getting that part right is
definitely appreciated.
Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
