(Splitting this off-list thread into a third part.) On Mon, Aug 24, 2009 at 12:39 AM, Gabe Black<[email protected]> wrote: > Steve Reinhardt wrote: >> On Sun, Aug 23, 2009 at 11:21 PM, Gabe Black<[email protected]> wrote: >>> Along those lines, something I've considered for quite a while, tried >>> unsuccessfully to implement a couple times, but still think would be a >>> decent idea is to implement the driver mechanism for the isa >>> descriptions as a python library/script instead of a parser and >>> description specification. The formats could work as classes. They could >>> inherit from a class that handles operands, knows how to substitute >>> templates, etc. The instructions themselves could either be instances of >>> those classes, or they could be classes themselves that use the formats >>> as meta classes. The later would be harder to use, but classes fit with >>> a more declarative syntax that seems to fit naturally with the >>> instructions. At least that's the impression I got with the microops. >>> >> >> I think some form of format inheritance sounds like a good idea, and >> could be added without abandoning the parser/specification model. >> > > Thanks! I'm sure it could be added, but I'm worried that we're doing a > lot of work to add capabilities to the parser that regular python > already has. Also, beyond you, me, and a select few others, people know > python and they don't know the ISA description language. I'd worry that > making it more sophisticated would also make it harder to learn. > > [...] > >>> Generally, being able to specialize the capabilities of the ISA system >>> through inheritance and other pythony stuff would, I think, keep the ISA >>> descriptions simpler. There wouldn't need to be any mechanisms that >>> aren't genuinely useful across ISAs across all ISAs. Also, while a >>> specialized syntax helps describe things more tersely by removing >>> unnecessary flexibility and information, because it needs to work for >>> all ISAs it can't work quite as well as it might in all cases without >>> specialization. If you look at src/x86/isa/operands.isa, you'll find a >>> small clump of functions that generate the sequence of parameters >>> necessary for different types of operands. By using those functions, the >>> operand definitions below are much simpler than they were before because >>> they contain the information that's -really- relevant, not the >>> information that's -usually- relevant, the rest living in the smarts of >>> those functions. The lists are then used to create classes inside the >>> parser. To me, it seems it would be sufficient to expose the ControlReg >>> class, for instance, allow subclassing it as X86ControlReg, and >>> instantiating it as necessary with the three relevant parameters. >>> >> >> Actually that operands.isa file doesn't look too bad to me... the fact >> that you could use a let block to define some functions that you call >> in the 'def operands' block makes it a whole lot cleaner than if those >> mechanisms weren't present. What do you not like about it? >> > > What I didn't like about it I actually addressed with those functions. I > added the ability to define functions in let blocks that you could use > in the operands block. I forget which construct wasn't playing along, > but it was fairly easy to fix. My point was that by letting python do > its thing more directly, you can get a cleaner description of what you > want to happen. What I've done is add a new way to take advantage of > that through the parser, but if operands were just classes then there > wouldn't have to be any new mechanisms.
This discussion is pretty interesting and timely since we've been having a similar conversation with Derek about the future of SLICC, and he recently proposed the option of replacing the SLICC language with an extended scripting language such as Ruby or Python. Personally I think the model that the ISA parser uses of having close integration of a domain-specific language and a scripting language, enabled by having the parser implemented in the scripting language, is pretty nice. Maybe not as nice as if you had a scripting language with truly extensible syntax, but I'm not sure what that would look like much less if there is such a thing. That said, I'm not going to claim that the split between the isa language and Python is perfect; it was my first attempt at such a thing, and IIRC I started out trying to write a complete language and sort of fell in to the exec-some-python escape mechanism and then grew to rely on it more and more. A good chunk of the overall ISA description system is already just a set of python classes (CodeBlock and InstObjParams) so there's no reason to think that more stuff could be implemented that way. Loosely speaking it's the back-end stuff that's native python while the DSL does the front-end stuff, and we're talking about making the front-end stuff more python. Actually I think the main issue is that you've taken the ISA description system way way (waaaay) past what it was originally design for (of necessity), so a lot of the original design decisions just don't apply anymore. Looking at what you've got in x86/isa, I'd want to go back and add or maybe reorient some features; for example, you've got about 10K lines of microcode in the insts subdirectory, by my estimation, but a lot of it is handling the cross-product of lots of opcodes by lots of addressing modes, so I'd look for a way to do templating on microcode routines to address that. (It may or may not be useful to go back and do this kind of thing now, since you've already done a lot of the hard work, but my point is that if we really want to clean things up it might be closer to a total redesign than a few little tweaks.) Our separate-but-related discussion on using a more powerful 3rd-party templating system for code generation also fits in with this somehow, I think. Steve _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
