On 04/23/12 08:43, Steve Reinhardt wrote:
> On Sun, Apr 22, 2012 at 10:40 PM, Gabe Black <[email protected]> wrote:
>
>> [...] there are two problems I ran into/can remember.
>> First, scons can't figure out what python files matter as far as
>> rebuilding things. If it doesn't know that foo.py is imported by bar.py
>> is imported by main.isa's let block, changes to foo.py will not cause
>> things to be rebuilt without a lot of arm twisting. Because the isa file
>> include mechanism is more explicit and easier for scons to follow, it
>> works better in that sense.
>
> Interesting, that hadn't occurred to me. I can see where people who write
> build tools don't generally bother to track file dependencies for
> interpreted languages.
>
> Given that the isa parser runs as one monolithic process, one inelegant but
> likely effective approach would just be to add an explicit scons dependency
> on every .py file in the isa directory tree (and we could find the files by
> walking the tree if we didn't want to have to name them manually).
>
> Now that I checked, it looks like that's pretty much what you already do
> with the existing .py files in arch/x86/isa/insts. So I guess we could
> just extend that to any other .py files that get created.
What you're referring to is a huge list of microcode .pys, I believe,
and while that works it's pretty hacky. I certainly wouldn't mind
getting rid of it if we find a more elegant solution.
>
>
>> Also I think there were problems with the
>> python search path.
>>
> I'm not too surprised on this one, but it can be fixed, if nothing else
> than by pulling out our ugly but trusty friend addToPath().
Yep. Entirely solvable I think, but not worth the time at that point.
>
>
>> As you mention, Steve, I'd ultimately like to turn the whole thing
>> inside out so that the ISA description stuff is embedded in normal
>> python code, probably as a python library.
>>
> I know you've mentioned that before, and I'm curious how you envision that
> working. I find the syntactic conciseness of the existing language very
> valuable. I know it doesn't work well for x86, but my inclination would be
> to fix/extend the language rather than getting rid of it. I'm open to
> considering a different approach, but I'm not ready to endorse it.
>
> Then again, this could be one of those places where the way we each
> describe what we want diverges more than our actual ideas do.
As I see it, there's two main parts to the ISA parser. There's the
backend which actually does the operand finding, code generating, etc.,
and there's the front end which actually processes the ISA description
uses it t drive the backend. The backend part is already all written in
python in isa_parser.py, and whatever flaws that may have, it could be
transfered basically intact into a library.
The other part, then, is the front end which implements the language.
The question is whether it's more efficient, concise, maintainable,
etc., to use a custom language and a parser to drive the backend, or if
it's better to actually write code which drives the backend directly,
perhaps through a thin glue/interface layer. I think there are some
benefits to doing things in python regardless of how good the custom
language is, for instance that people can come in with existing
knowledge of python, or that we remove a layer which reduces complexity
and the chance of bugs.
Besides that, though, you're saying that the custom language is more
concise than doing things in python. If someone were to sit down and
write a language specific for describing ISAs and someone else sat down
and made a more generic language which was then used to describe ISAs,
you'd probably be right. I think, though, that python is a very well
developed language which transcends its generic nature and may even be
*more* concise because it's very flexible and elegant and can be
extended in ways specific to even the ISA in question instead of just
ISAs in general.
For instance, an example I've brought up before are operand types. If
you want to define lots of operand types that behave in similar ways,
before you used to have to define them all completely and just use the
same values over and over. I added a feature which allows you to define
them with a function so you only have to specify the "interesting"
parts, but I think rather than showing how the parser can handle that
situation, that actually shows that when the parser steps out of the way
and lets generic python do its thing, things get cleaner and easier. Of
course the parser is still providing value since it actually does
everything else with those operands once they're defined, but that's the
backend which we'd have in either case.
Another example would be defining the decoder. Currently in ARM and x86,
the instructions are not defined inline in the decoder. This is because
in both cases there are several encodings for the same instruction and I
didn't want to have to make up two different names, etc., for the same
thing. Second, in ARM, the encodings are quite complicated and need to
be decoded using a function instead of a simple switch statement. The
decoder could be defined in python as a hierarchy of objects which could
map to switch statements by being dict-like, or map to functions, or map
to just instruction constructors, etc., and be extensible local to the
ISA. It might look something like this.
class Add(IntOp):
code = "a = b + c"
class Sub(IntOp):
code = "a = b - c"
class Xor(IntOp):
code = "a = b ^ c"
class And(IntOp):
code = "a = b & c"
class Or(IntOp):
code = "a = b | c"
SwitchDecode("INST_TYPE", {
"0" : Add("RA", "RB", "RC"),
"1" : decodeNeon, # an object that may be another decoder, a C++
function, etc.
"2" : SwitchDecode("OPCODE ^ 0x101", {
"0" : Sub("RA", "RB", "RC2",
"1" : IfDecode(
# These use fixed indexes instead of bitfields
("opBits0 = 3", Xor(0, 1, 2)), # if ()
("opBits1 != 2", And(0, 1, 2)), # else if ()
Or(0, 1, 2) # else
)
"default" : Undefined
}
}
And if some crazy company comes out with an ISA called y86 (why? why
indeed) and it needs some totally crazy new mechanism to munge the
instruction to get what it's supposed to do, then the y86 isa
description script can implement it locally and not complicate the other
descriptions or the common parser stuff.
Gabe
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev
