There's been some discussion about how FS and SE mode are being brought together, and while I did a brain dump about this a while ago, I think it would be nice to do that again and sort of outline where I'm headed so we can all have the big picture, as incomplete as it may be. I don't know what all the problems I'll run into are, so I'm going to try to anticipate what I can, plan for it, and just wing it for the rest. All of these issues are sort of tangled together, so I'm going to generally work on whatever piece can make progress given the state of the others. There are going to be places where I just chop things off at odd points because to go farther than that would open a whole additional can of worms.
A major obstacle is that the code built for SE and FS modes is not the same, and some key pieces work differently depending on what mode you're in. This is mostly what I've been working on so far. There are some milestones I'm going for here, which are: 1. FULL_SYSTEM is not used for conditional compilation. It's only considered at runtime, or really at compile time still because it's constant. But it operates only at the level of C++ and not the proprocessor. 2. Make FullSystem a property of the simulation and not a constant. At this point, _SE and _FS suffixes can go away and we can use one build for both. It'll have to be the runtime constant and global still. 2. Make FullSystem a property of an object, probably the system objects and the decoder, and make whatever needs it check for it there. 3. Make FullSystem an implicit property which reflects how a system is configured, not a big switch that's flipped one way or the other. Next, what runs in the simulation is significantly different between the two modes. In one it's an OS with devices, ROM(s), a kernel, etc., and in the other it's a program with a stack, system call emulation, etc. 1. Make devices optional. If a machine has no devices, then it just doesn't have any devices. If it does then it does. The devices attach to a system, and there isn't any dependency the other way, except if software tries to talk to the devices through the memory system. 2. Make a workload object which encapsulates what needs to be set up to get a workload running. A kernel workload would load the kernel into memory, set up any in memory tables, etc. A process workload would load the process into memory, set up the process stack, etc. They would be treated the same by the system object and handle the differences by themselves. 3. The decoder will need to have somewhat different behavior depending on if it's running something with emulated behavior or not. Note I didn't say a user process. We could emulate user space calls to get the effect of SE mode, we could emulate BIOS calls to when running a kernel, hypervisor calls when running on an architecture that requires a hypervisor, etc. I've started laying the ground work for the decoder to be a more sophisticated, specialized object, but I haven't figured out all the details of exactly how this should work. Finally (?) the scripts will need to change. They won't know how to set up a simulation with this new way of doing things. I *think* this will be a mostly mechanical change. So there's a very rough sketch of where I'm going, with the details front loaded to the things I'm active working on/thinking about. One thing to keep in mind is that this isn't necessarily going to be a really tidy transition, but I've been trying and will continue to try to never break any regressions (or anything else, if I can help it). There are most likely going to be warts throughout the process, but they'll get cleaned up eventually. We're changing a fundamental aspect of the simulator, and realistically it's not going to be quick or hassle free. Gabe _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
