On Tue, Apr 24, 2012 at 2:03 AM, Gabe Black <[email protected]> wrote:
> > > 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. > Yea, that's exactly what I'm referring to... I agree, it could be improved upon, but my point is that if we did more of that kind of thing then there's precedent for it and we're not introducing some new level of hackiness. > 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. > Yea, even though it's not factored out into a separate module, the documentation at http://gem5.org/Code_parsing already refers to this as a library. > Besides that, though, you're saying that the custom language is more > concise than doing things in python. It certainly is for Alpha. I can believe that it's not the case (or at least that the difference is not as significant) for x86 and ARM. > 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. > Certainly a general-purpose programming language is more general than a domain-specific one... no argument there. The key thing is that the current ISA parser/language wasn't designed for "ISAs in general", it was basically designed to be good enough for Alpha, yet generic enough to deal with similar RISC ISAs, with the expectation that it would likely need to be expanded to support other ISAs (particularly CISC ISAs). You've managed to heroically wedge support for x86 in anyway, and we both agree it's not ideal. I'm confident that the language could be extended to better support CISC ISAs. I'm not claiming that it's the right thing to do though. > 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. > Right, the parser has always been designed to leverage the flexibility of python where it could... for example, the way the "def format" blocks are really just python functions, and the only thing special about them is the way they get called implicitly by statements in the decode block, which provides conciseness. You found that in going from RISC to CISC the operand support needed more flexibility and you provided that by adding richer hooks into python, which is perfectly fine and in keeping with the original spirit of the parser. > Another example would be defining the decoder. Sure, that's another thing where the current language assumes RISC decoding. Again, it's just a design decision of whether to fix this assumption by extending the language or by effectively abandoning it. I'm open to either. Actually your example (which I left out for brevity) seems pretty reasonable to me. Things like SwitchDecode() are what the language already does, only that functionality isn't accessible outside the language. Refactoring things a bit so that the language is a thinner layer on top of a more comprehensive library that covers more of the "front end" functionality as well as the "back end", and enabling ISAs to skip the language entirely and just treat the whole thing as a library, seems like a reasonable approach. I'd still keep the language around, partly just so we don't have to rewrite all the existing RISC ISA descriptions. > 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. I'm willing to gamble that we will never have to support an ISA that's more idiosyncratic than x86. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
