You guys have valid points, and I don't know for a fact that the compiler isn't already giving us the same performance boost this might. Back that summer when someone looked at increasing performace I think they got somewhere by moving some common cases out of the switch statement and into ifs, so it would seem that the switch isn't always being optimized out of an inlined version. I never checked that myself.
As far as how often those functions are called, the read one will be called fairly often for address translation, and potentially in the predecoder depending on the ISA. The writing one is likely called substantially less often. That reminds me. Why do we have a convention of read/set? Why not read/write or set/get? It seems a little asymmetric, but admittedly probably not important enough to change in any case. Gabe Quoting Steve Reinhardt <ste...@gmail.com>: > I had similar thoughts... I think Gabe's idea could work, but I'm not > sold on the motivation. If it's just for performance, do we know for > sure that this is actually a performance bottleneck? > > Also, I don't think we can get rid of the MiscReg space and the > indices, since they're needed to indicate dependencies (though I think > most if not all MiscReg dependencies are handled through other means, > such as marking the instructions that write them as serializing). If > bypassing the indices for accesses meant we could get rid of the > indices altogether then I'd feel more favorable since the net > amount/complexity of code might be the same or reduced. However if we > can't get rid of the indices then having a different access method > that doesn't use them seems like additional complexity, which is > generally best avoided unless it's really necessary. > > What do you think, Gabe? > > Steve > > On Tue, Sep 8, 2009 at 7:42 PM, nathan binkert<n...@binkert.org> wrote: >> How often are these functions used? I'd have thought that they're not >> so frequent and wouldn't warrant optimization. Also, couldn't they >> just be inlined? Or is the variable obfuscated in such a way that the >> compiler doesn't know what it is at compile time? >> >> Nate >> >>> Hello everybody. I was thinking the other day that it might be a good >>> idea to templatize readMiscReg and setMiscReg. I don't have the idea >>> fleshed out all the way, but I thought it would be a good idea to send >>> an email to before I forgot about it. >>> >>> When we access control registers, my impression is that we almost >>> always know which one we want. There are some exceptions where things >>> are accessed in a loop, but usually there's a specific place where we >>> need a specific register for a specific purpose. What happens, though, >>> is that we call a function that handles -all- registers, and it has to >>> switch on a parameter to redetermine what we wanted to do. If we >>> called a specific function for, say, reading CR0, we'd skip the >>> overhead of the switch statement. We'd also make the functions that >>> set/read those registers shorter and more managable. >>> >>> In x86, I use bitunion types to split out the bitfields of a register. >>> Because of that, basically each of the control registers already has a >>> type that corresponds to it specifically. There are some exceptions >>> where the same type is used for more than one register, but I don't >>> think that's the common case. That type could be used as the template >>> parameter to the read/set functions which would cause template >>> instantiations all the way back into the isa object. >>> >>> Once there, template specialization would let you define a function >>> that reads/sets just CR0, and the type system and C++ would plop it >>> into place at the right place and time while still respecting >>> interfaces. It might even be inlinable. The regular version that takes >>> an index would still be available. I'm not quite sure how to fold it >>> into the templated version of that function since the index is >>> explicit, but since it's likely going to be (and probably should >>> normally be) a MiscReg, that might work out. >>> >>> Gabe >>> _______________________________________________ >>> m5-dev mailing list >>> m5-dev@m5sim.org >>> http://m5sim.org/mailman/listinfo/m5-dev >>> >>> >> _______________________________________________ >> m5-dev mailing list >> m5-dev@m5sim.org >> http://m5sim.org/mailman/listinfo/m5-dev >> > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
