For people who don't actively work with the ISA descriptions, don't bother reading any further.
For the rest (both?) of us, I've been thinking more about improvements to the parser, and operand definitions seem like a good place to start. They're relatively isolated from the rest of the system, are already managed as objects more or less, and the existing system has had some problems. * Definition outside of the dict: First, I want to be able to define operands outside of the dict and then assign them in after the fact. That would make it easier/possible to generate operands programmaticly when there are clusters of related operands, and would allow grouping operands with the instruction types that consume them. ARM is a good example of an ISA that would benefit from those two properties. Since the operand indices come from member variables of the static inst class instead of raw instruction fields (to allow for multiple encodings/forms of the same instruction), the actual names tend to be reused a lot, ie. op1, op2, etc. There would be a form of op1 based operand for fp, for integer, for integer which might be the pc, for integer which might be the pc only in arm mode, for control registers, etc. It would be a lot more concise to be able to have one function call that would set up all those various forms at once without having to list them out over and over. Also, where the names are different, they tend to differ across instruction type boundaries. For instance, load/store instructions have dest, base, and offset, regular instructions have dest, op0, op1, op2, and microops have ura, urb, urc. Those definitions could be localized to where they're used and may make things easier to understand because their scope is reduced. This wouldn't be to supplant the dict initially (or maybe ever), just to be able to append to it in more flexible ways after it was defined. * Operands as classes: I've brought this up before, but it would be easier to work with operands if the default classes (IntReg, ControlReg, etc.) could be extended and customized as subclasses instead of having to tweak all their parameters in similar ways over and over per operand. The functions I added to generate lists of parameters for different types of operands is an approximation of that, but it doesn't allow mixing together different aspects through inheritance. Also, using a class allows extending the parameters and behaviors of operands in much more sophisticated ways than a sort of fill in the blank order form. In that vein, the operands would be more directly responsible for their own behavior like setting up indexes in the src and dest index arrays, reading and writing values, declaring their proxy in the execute function, etc. * Operands with custom types Operands should be allowed to have custom types like BitUnions defined to have bitfields corresponding to control registers. One immediate problem with this is that it would cause confusion with the "." syntax used to specialize an operands type. We can circumvent that by using a symbol that's not ambiguous like @. I don't think @ is used in C or C++ for anything yet. * Customized indexing Operands should be able to set up their indexes however they see fit, including installing more than one of them. Then, when the time comes to actually read or write their value, they can munge the multiple raw register values into what will be consumed/produced by the instruction. This would help untangle some potential issues with different forms of the same operand (say, all of it or only certain bits) from looking like two totally different operands to the parser. * Printing functions Operands should know how to print themselves in debugging messages and be accessible to do so. Right now, in ISAs which use instruction bitfields directly like SPARC, a lot of hackery is involved in figuring out if srcIdx[0] is really the base register, or the offset, or what. If you could just print out operand "base", it would remove the confusion. Also, registers may need to be printed in special ways in different circumstances. The operand itself could know about the special circumstances and avoid having to rediscover them at disassembly time or having to have specialized functions for each case/cross product of cases. * Automatic generation of base classes Because ISAs that don't use instruction bitfields need somewhere to put their values, there are lots of classes defined which just set up holding places for values in different combinations. It would be great to incorporate the operand stuff into some sort of smart class generator that would set up those classes automatically. This is sort of sort of tangential. A little farther into the future, I'd like the instruction classes to be able to scan for operands manually, tweak the corresponding list before and after, and to scan for them in custom ways. This is just sort of a brain dump and what I think are good ideas right now. I don't have time to actually -do- anything about this right now, but I thought I'd put it out there to maybe get a conversation started. Let me know what you think. Gabe _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
