I've thought a lot about this since x86 has a lot of tables and mechanisms for this sort of thing which I've implemented to various degrees. I think it'd be easier to collect that information at the python level and then propagate it to C++ as apposed to getting it once you start running. In python, you're still working at a fairly high level of abstraction which makes following relationships and getting at values easier. If you did it in the C++, you'd have to have help from all the objects to figure out how to get to things since they can store the pointers they get anywhere they want, or even extract the information they need and discard them. Also, some things like the in memory tables in x86 need to be set up before the simulation gets going so that the kernel can find them as it's just starting up. You could probably slip that in there early in the startup sequence for the C++, but that might get complicated.
As far as doing it in C++ inside of M5, I don't appose that idea but I'm not sure where the code would go. Would that be another part of the CPU with a bunch of functions for accessing it in the thread_context, or part of the microop itself, or what? This actually brings up my idea to turn the ISA into a simobject since that would be an ideal place for that code. I can write a long email about that if people are interested. Gabe Ali Saidi wrote: > I kind of ran into a similar thing with sparc. There is configuration > code that needed to inform the system about the speed/size/type of > various objects. It would be good to have a C++ interface to easily > query the object tree to be able to make those determinations. > > Ali > > On Sep 20, 2008, at 9:42 AM, Steve Reinhardt wrote: > > >> 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 >> > > _______________________________________________ > 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
