> On May 28, 2012, 7:59 a.m., Steve Reinhardt wrote: > > I'm fine with making FullSystem a property of the decoder, but all this > > mechanism to support both SE and FS in the same simulation seems like > > overkill at this point (and for the foreseeable future, IMO). Can we just > > clean up the FullSystemInt part first, and worry about simultaneous SE/FS > > when we really need it? There's clearly a performance cost here (though > > possibly a small one), and it also makes the code more complex. Since the > > vast majority of instructions don't depend on the mode, either, I don't > > really like the idea of having completely separate decode caches like most > > ISAs do. OTOH, I don't like the overhead of having to hash in and compare > > the FS bit on every decode lookup either. > > Gabe Black wrote: > Leaving out whether we were in full system or not as contextualizing > state when decoding instructions was actually broken, so that part of the > change is necessary. The performance cost was not measurable on x86. Having > separate decode caches is an intrinsic part of the design we talked about > before because se/fs has to be contextualizing information. > > Also we don't *have* to have SE/FS in the decoder in the first place. > Some ISAs (SPARC, for instance) take care of the SE vs. FS changes in > behavior when handling the trap/exception/interrupt which is requesting a > system call. When set up that way, the instruction objects themselves don't > know which type of system they're part of. It gets a little more complicated > when there are system call instructions which don't return Fault objects (X86 > has these), but then we can just inject system call targets with pseudo > instructions at them which invoke a system call in SE mode. > > Steve Reinhardt wrote: > I wouldn't say it was "broken"... having SE and FS simultaneously in the > same simulation is just a feature that's not supported. Sort of like having > multiple CPUs with different ISAs in the same simulation: it doesn't work, > but that doesn't mean it's broken, just that the design doesn't even attempt > to cover that case. > > However, unlike having multiple CPUs with different ISAs, I can't even > think of a use case for having SE and FS simultaneously in the same > simulation. Also, I doubt that just being able to dynamically decode > instructions under either mode is enough to actually support SE and FS > simultaneously anyway, especially in the same system where the simulator and > the OS would have to fight over physical memory allocation etc. So to me, > making SE/FS part of the dynamic context is code and runtime overhead that > has no purpose, and at most only gives the false appearance that we support > something that doesn't actually work or make sense. Thus even if the code > and overhead is small, I don't like having it in there. > > Gabe Black wrote: > I'm trying to eliminate or significantly reduce the separation between SE > mode and FS mode, so yes, it's something that I plan to support. A simple > example of where that would be useful would be where you have some simple > client apps you want to run in SE mode and a server you want to run in FS. I > agree it's probably unlikely you'd want to switch the *same* cpu/system > between SE and FS, but you might want to have both in two *different* systems > in the same simulation. The distinction between SE and FS mode is fairly > artificial anyway, so I want to be able to have things which are at other > points on that spectrum (BIOS emulation mode, hypervisor emulation mode in > SPARC, emulated option ROMs). In that vein I want to flush SE and FS mode out > of the decoder entirely, but I'm not there yet. > > The code has virtually no overhead, supports what I'm working towards, > makes sense, and is something I intend to support. > > Steve Reinhardt wrote: > We can't run client apps in SE mode because there's no network stack for > them to use to communicate with the server. Can you come up with a better > example?
I don't think I need to come up with use cases to justify fixing a bug. I also don't think I have to prove something is a bug because "nobody will try that" while I work towards making it possible for somebody to try that or something similar. - Gabe ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/1229/#review2834 ----------------------------------------------------------- On May 28, 2012, 12:52 a.m., Gabe Black wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/1229/ > ----------------------------------------------------------- > > (Updated May 28, 2012, 12:52 a.m.) > > > Review request for Default. > > > Description > ------- > > Changeset 9030:674d25baca5e > --------------------------- > ISA: Factor FullSystemInt out of the decoders. > > > Diffs > ----- > > src/arch/alpha/decoder.hh 5851586f399c > src/arch/alpha/decoder.cc 5851586f399c > src/arch/alpha/isa/decoder.isa 5851586f399c > src/arch/mips/decoder.hh 5851586f399c > src/arch/mips/decoder.cc 5851586f399c > src/arch/mips/isa/decoder.isa 5851586f399c > src/arch/x86/decoder.hh 5851586f399c > src/arch/x86/isa.cc 5851586f399c > src/arch/x86/isa/decoder/one_byte_opcodes.isa 5851586f399c > src/arch/x86/isa/decoder/two_byte_opcodes.isa 5851586f399c > src/sim/full_system.hh 5851586f399c > src/sim/root.cc 5851586f399c > > Diff: http://reviews.gem5.org/r/1229/diff/ > > > Testing > ------- > > > Thanks, > > Gabe Black > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
