On 04/24/12 09:19, Steve Reinhardt wrote: > 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.
This is a question, not a statement :-P. I don't think it's certainly true for Alpha either, although I have no concrete evidence either way. > > > >> 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. I agree that we could extend the language to make x86 fit better (and that's exactly what I've done to now), but I don't think it's a scalable thing to do and I think it makes both the descriptions and the language significantly more complex. A convincing argument can be made that we're done scaling out to new ISAs, although I don't want to put barriers up in that respect, but I don't think we're done scaling down to the fine details in the ISAs themselves supporting all the features and nuances correctly like this cc dependence problem. There are also some things which technically work but that are pretty ugly like how doubles are handled that would be nice to clean up, especially in SPARC and somewhat in ARM if I remember the implementation correctly. > > >> 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. What I'm saying is that things get easier when we expose more of the underlying python, so why not just go all the way and use the underlying python directly? > > >> 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. Yeah, inverting things so that python is the primary language doesn't mean the other stuff has to go away. It could live inside the ISA description script just like the python let blobs live in the ISA description today. That's actually a good way to get the best of both worlds where you get the conciseness (if it really is more concise) or the flexibility, whichever you need more. > > >> 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. Knock on wood. Gabe _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
