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
