From a quick read it sounds like option 2 would be better, cleaner, and more extensible. In reality other than Alpha all ISAs have some microcoded instructions. I don't see a reason not to deal with microops as first class operations.
Ali On Sep 14, 2008, at 5:19 PM, Gabe Black wrote: > The more I look at this, the more it seems like there needs to be a > way > to discard the current macroop and start executing out of the ROM as > the > instruction itself. From a practical perspective, this would be more > efficient than constantly checking where a microop should come from on > every fetchMicroop call. The microop would come from the right place > all > the time. > > Second, it simplifies control flow to the ROM. Right now, the ROM and > the regular microops live in the same micropc address space, and > they're > distinguished by putting the ROM at high addresses. This is a problem > since the micropc branch microop only supports an 8 bit immediate > value > for a new absolute micropc. Even if it was relative, that would mean > -all- ROM targets had to be within 255 microops of the combination > micropc space which wouldn't work out very well. > > Third, it's more like the actual hardware where the combinational > macroop does a little bit to either do the whole instruction or get > out > of the way, and then the ROM takes over and does it's thing. > > Fourth, this makes the problem of handling faults without an actual > macroop easier, since it might work out that you can just go to the > ROM > directly. I'm not sure how well this will work out when it's all said > and done, but it is an attractive idea. > > This does mean, however, that the problems of caching microops that > have > been specialized to the environment of the original instruction, > operand > size, blah blah, are still there. It's still going to be hard to keep > track of them in a sensible way. In a real machine this is easier > since > you're microops are really microop templates which are then > specialized > for their context. Also, it means there would need to be a new > mechanism > in the decoder which would allow the macroops to switch themselves out > for a ROM when needed. > > I've been toying with two ideas for how to make this happen. The first > is that there would actually be two decoders. The first would be a > decoder which would go to either a stream of microops actually encoded > in 1s and 0s, or bring in a stream of 1s and 0s from an address space > external to the CPU, aka an actual ROM. The other decoder would go > from > that to a series of actual microop StaticInsts which would get > processed > by the remainder of the CPU. I don't like this very much because it > has > a lot of overhead and would complicate things for ISAs that don't want > to use it. > > The other idea would be to make the microcode ROM a first class > citizen > in the CPU, as apposed to a conceptual entity in the X86 microcode > stuff, and to add a function to the threadcontext which would change > the > mode of the decoder (or whatever else is splitting out microops from > macroops) to start using the ROM instead. > > I'd love to hear what other people think about this, so please don't > hesitate to let me know. I realize my explanation might be hard to > follow without being as familiar with this stuff as I am (or maybe > because I didn't explain it well?), so if you'd like any clarification > or a longer explanation please let me know that too. > > Gabe > > Gabe Black wrote: >> In addition to needing a way to get -to- the microcode in the ROM, >> another issue to work out is how the microops in the ROM are >> represented, constructed, and returned to the decoder. An important >> decision that that hinges on is whether or not microops in the ROM >> will >> be specialized for the operand size, address size, target registers, >> etc. of the originating instruction like combinationally generated >> microops are. In a real system they would be. For the interrupt >> entering >> microcode this shouldn't be a concern since the process is basically >> independent of any particular instruction or mode of operation, >> except >> at the global level. In other words, you do something different >> enough >> in each mode to have its own implementation, but each implementation >> works in only one way. The key difference this makes is whether or >> not >> the microops can be generated once and kept around forever, or if a >> new >> StaticInst needs to be generated for every different environment the >> microops are executed in. >> >> >> Assuming the microops are specialized, which is the more useful, >> realistic and difficult option, several other questions come up. The >> first is exactly how the ROM, which I'm envisioning making a static >> member of the base macroop class, will generate the microops it >> returns >> to the macroop/decoder. Unlike the case of macroops which statically >> allocate their microops at construction and store them in an array, >> the >> ROM will need to have many versions of the same microop around at the >> same time. This means that the micropc isn't indexing into StaticInst >> objects, it's really indexing into StaticInst classes which it then >> needs to instantiate and specialize against the environment of the >> original macroop. >> >> Assuming there's a good indexing mechanism to get the right class >> built based on a micropc, the next issue is performance. If we're >> reallocating these microops every time their executed, we might kill >> some of the performance gain we're getting from the decode cache, >> less >> the decode itself. We would want a cache of some sort which would be >> index on the emulation environment of a particular macroop and the >> micropc of the microop it was referencing. This is less of a concern >> because getting it working is the first priority, and also since >> these >> are exceptions, even by name, they hopefully don't happen very >> often and >> wouldn't affect performance hugely. >> >> If anybody has any opinion or suggestion on this or the earlier >> email about microcode, please let me know. This is the next hurdle to >> get over for x86. >> >> 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
