If it's that complicated, why not just do it in C++ inside of M5, and have a special microop that just calls that function and lets it do the dirty work? I don't think performance fidelity is an issue here, and even if it were, we could always just make that single microop take longer.
Steve On Sat, Sep 20, 2008 at 12:50 AM, Gabe Black <[EMAIL PROTECTED]> wrote: > Now that I'm making the branch microop always use a fixed absolute > micropc, the only place I wasn't already using it, the CPUID > instruction, needs to change. The problem is, as things are implemented, > it really has to be able to compute it's target. The CPUID instruction > basically queries a mostly but not completely static pool of information > about the CPU it's run on. For instance, it can tell you the size of > various caches, what version the CPU is, who the manufacturer was, what > instruction extensions are supported (that's partially where the info in > /proc/cpuinfo comes from), blah blah blah. It's not completely static > for two reasons. First, sometimes certain extensions are implemented in > only some modes. I believe some CPUs turn off the bits of instructions > that won't work in the current mode, although I'm not sure of that and I > think it's done inconsistently among processors. Second, I believe Intel > now allows you to tamper with the values returned by CPUID in order to > allow a virtualized guest to query freely and not see capabilities that > wouldn't work or that it shouldn't use. > > Right now, my implementation of CPUID does a little munging on the > "function" code, which specifies what information you want, and then > goes into what is essentially a big case statement/computed branch that > puts the right values in the right registers and then returns. As I > mentioned, since I'll no longer be able to do computed branches, this > will no longer work. There are lots of other limitations too like having > lots of microops to function as a basic lookup table, and the fact that > the information is static and completely unconfigurable. For instance, > the cache would always reported as the same size, and if some benchmark > tried to use that value to behave in a certain way, it wouldn't do what > it was supposed to. What I'm thinking I'd want to do is one of two > things. Either the CPUID instruction should do a series of loads out of > an actual lookup ROM/RAM somewhere outside of the CPU, or there could be > a CPUID device which would allow it to respond in intelligent ways > depending on the CPU mode, for instance. I'm favoring sticking a ROM in > the memory system somewhere. Also, I'd like to put in some sort of > configuration interface that would allow the configs to program in what > CPUID should say if it needs to reflect the actual hardware or someone > wants to add a new function, for instance. > > What do you guys think? > > Gabe > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev >
_______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
