http://repo.m5sim.org/wiki/index.php?title=X86_microcode_system&feed=atom&action=historyX86 microcode system - Revision history2024-03-28T23:55:18ZRevision history for this page on the wikiMediaWiki 1.29.2http://repo.m5sim.org/wiki/index.php?title=X86_microcode_system&diff=2133&oldid=prevGblack: /* Macroop Argument Specialization */2007-06-08T00:01:08Z<p><span dir="auto"><span class="autocomment">Macroop Argument Specialization</span></span></p>
<table class="diff diff-contentalign-left" data-mw="interface">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;' lang='en'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 00:01, 8 June 2007</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l33" >Line 33:</td>
<td colspan="2" class="diff-lineno">Line 33:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>This sounds like but is very different from microop parameter specialization. This refers to generating groups of macroops which all perform the same operation, but use different arguments from different places including memory.</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>This sounds like but is very different from microop parameter specialization. This refers to generating groups of macroops which all perform the same operation, but use different arguments from different places including memory.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><del class="diffchange diffchange-inline">The solution </del>which will be implemented <del class="diffchange diffchange-inline">for now will be to generate the microcode using python</del>. <del class="diffchange diffchange-inline">The python </del>will <del class="diffchange diffchange-inline">generate a memory based and non-memory based implementation. A preprocessor would work, but it would likely be overkill for what</del>'s <del class="diffchange diffchange-inline">needed</del>.</div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">In order to simplify the system which specifies the microcode </ins>which <ins class="diffchange diffchange-inline">makes up instructions, a preprocessor </ins>will <ins class="diffchange diffchange-inline">need to </ins>be implemented. <ins class="diffchange diffchange-inline">This </ins>will <ins class="diffchange diffchange-inline">probably use syntax mimicking NASM</ins>'s.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>To allow the decoder to specify what variant of arguments to use, the system of passing tags into the instruction format will be revamped. It will work essentially the same, but instead of doing replacement on the register arguments, it will need to take advantage of whatever the microop parameter specialization mechanism is to set things up.</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>To allow the decoder to specify what variant of arguments to use, the system of passing tags into the instruction format will be revamped. It will work essentially the same, but instead of doing replacement on the register arguments, it will need to take advantage of whatever the microop parameter specialization mechanism is to set things up.</div></td></tr>
</table>Gblackhttp://repo.m5sim.org/wiki/index.php?title=X86_microcode_system&diff=2132&oldid=prevGblack: /* Microop Parameter Specialization */2007-06-07T20:14:59Z<p><span dir="auto"><span class="autocomment">Microop Parameter Specialization</span></span></p>
<table class="diff diff-contentalign-left" data-mw="interface">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;' lang='en'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 20:14, 7 June 2007</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l11" >Line 11:</td>
<td colspan="2" class="diff-lineno">Line 11:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>Immediate values are handled by making ROM based microops generate a few combinational microops before actually going to the ROM. These push the immediate parameters into certain microcode registers which the ROM code is written to use.</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>Immediate values are handled by making ROM based microops generate a few combinational microops before actually going to the ROM. These push the immediate parameters into certain microcode registers which the ROM code is written to use.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;"></ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;"></ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;"></ins></div></td></tr>
<tr><td colspan="2"> </td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins style="font-weight: bold; text-decoration: none;">A potential solution is to create an "EmulEnv" (or similar) class which contains the emulation environment. That's passed into the macroop, and then the pieces of it are used to construct the contained microops using the standard "operand" mechanism. In the case where there is no containing macroop (which we might not want anyway), the "emulation environment" will exist only in python and its values will be used to fill in the microops parameters directly.</ins></div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>== Microop Allocation ==</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>== Microop Allocation ==</div></td></tr>
</table>Gblackhttp://repo.m5sim.org/wiki/index.php?title=X86_microcode_system&diff=2131&oldid=prevGblack: /* Macroop Argument Specialization */2007-06-07T19:55:26Z<p><span dir="auto"><span class="autocomment">Macroop Argument Specialization</span></span></p>
<table class="diff diff-contentalign-left" data-mw="interface">
<col class='diff-marker' />
<col class='diff-content' />
<col class='diff-marker' />
<col class='diff-content' />
<tr style='vertical-align: top;' lang='en'>
<td colspan='2' style="background-color: white; color:black; text-align: center;">← Older revision</td>
<td colspan='2' style="background-color: white; color:black; text-align: center;">Revision as of 19:55, 7 June 2007</td>
</tr><tr><td colspan="2" class="diff-lineno" id="mw-diff-left-l29" >Line 29:</td>
<td colspan="2" class="diff-lineno">Line 29:</td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>This sounds like but is very different from microop parameter specialization. This refers to generating groups of macroops which all perform the same operation, but use different arguments from different places including memory.</div></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"><div>This sounds like but is very different from microop parameter specialization. This refers to generating groups of macroops which all perform the same operation, but use different arguments from different places including memory.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><del class="diffchange diffchange-inline">A possible </del>solution <del class="diffchange diffchange-inline">would </del>be to <del class="diffchange diffchange-inline">use microop specialization creatively to use register indices from </del>the <del class="diffchange diffchange-inline">appropriate places and to put loads and stores as prefixes </del>and <del class="diffchange diffchange-inline">suffixes on the body of the operation</del>. <del class="diffchange diffchange-inline">This might not </del>work <del class="diffchange diffchange-inline">because while the entry point could </del>be <del class="diffchange diffchange-inline">before or after the load, the macroop wouldn</del>'<del class="diffchange diffchange-inline">t know to not execute the store suffix. There may also be cases where more than one value is loaded or stored. Entry points only one instruction apart also seem to conflict with the one example that is available which deals with instructions in quads, or in other words specialized bundles of four instructions</del>.</div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">The </ins>solution <ins class="diffchange diffchange-inline">which will be implemented for now will </ins>be to <ins class="diffchange diffchange-inline">generate </ins>the <ins class="diffchange diffchange-inline">microcode using python. The python will generate a memory based </ins>and <ins class="diffchange diffchange-inline">non-memory based implementation</ins>. <ins class="diffchange diffchange-inline">A preprocessor would </ins>work<ins class="diffchange diffchange-inline">, but it would likely </ins>be <ins class="diffchange diffchange-inline">overkill for what</ins>'<ins class="diffchange diffchange-inline">s needed</ins>.</div></td></tr>
<tr><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td><td class='diff-marker'> </td><td style="background-color: #f9f9f9; color: #333333; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #e6e6e6; vertical-align: top; white-space: pre-wrap;"></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><del class="diffchange diffchange-inline">Another solution, which looks like </del>the <del class="diffchange diffchange-inline">one that may be implemented in actual hardware, is </del>to <del class="diffchange diffchange-inline">have two copies of each instruction, one that uses memory and one that doesn't. It would be cumbersome to write a new version of each of these instructions by hand, so a preprocessor might be needed. As mentioned in the page about the microcode assembler, this preprocessor would likely mimic nasm syntax and be totally separate from the actual assembler.</del></div></td><td class='diff-marker'>+</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #a3d3ff; vertical-align: top; white-space: pre-wrap;"><div><ins class="diffchange diffchange-inline">To allow </ins>the <ins class="diffchange diffchange-inline">decoder </ins>to <ins class="diffchange diffchange-inline">specify </ins>what <ins class="diffchange diffchange-inline">variant </ins>of <ins class="diffchange diffchange-inline">arguments </ins>to use, the <ins class="diffchange diffchange-inline">system of passing </ins>tags <ins class="diffchange diffchange-inline">into </ins>the instruction format <ins class="diffchange diffchange-inline">will be revamped</ins>. <ins class="diffchange diffchange-inline">It will work essentially </ins>the <ins class="diffchange diffchange-inline">same</ins>, <ins class="diffchange diffchange-inline">but instead of doing replacement on </ins>the <ins class="diffchange diffchange-inline">register arguments, it will need </ins>to <ins class="diffchange diffchange-inline">take advantage </ins>of <ins class="diffchange diffchange-inline">whatever </ins>the <ins class="diffchange diffchange-inline">microop parameter specialization mechanism is to set things up</ins>.</div></td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div> </div></td><td colspan="2"> </td></tr>
<tr><td class='diff-marker'>−</td><td style="color:black; font-size: 88%; border-style: solid; border-width: 1px 1px 1px 4px; border-radius: 0.33em; border-color: #ffe49c; vertical-align: top; white-space: pre-wrap;"><div><del class="diffchange diffchange-inline">There also needs to be clean syntax to differentiate </del>what <del class="diffchange diffchange-inline">version </del>of <del class="diffchange diffchange-inline">an instruction </del>to use, <del class="diffchange diffchange-inline">and what register indices, etc, to feed into it. In </del>the <del class="diffchange diffchange-inline">previous version, this was done by specifying argument types in special "</del>tags<del class="diffchange diffchange-inline">" that were processed by </del>the instruction format. <del class="diffchange diffchange-inline">Because </del>the <del class="diffchange diffchange-inline">instructions are mostly already set up</del>, the <del class="diffchange diffchange-inline">format's job is only </del>to <del class="diffchange diffchange-inline">specify the structure </del>of the <del class="diffchange diffchange-inline">decoder as directed by the tags</del>.</div></td><td colspan="2"> </td></tr>
</table>Gblackhttp://repo.m5sim.org/wiki/index.php?title=X86_microcode_system&diff=2118&oldid=prevGblack at 21:39, 6 June 20072007-06-06T21:39:41Z<p></p>
<p><b>New page</b></p><div>== Microop Parameter Specialization ==<br />
<br />
Microops are not, in general, written in an absolute sense. They are templates which provide an implementation for a macroop, but need to be specialized using the arguments of the original instruction. In hardware, this appears to be handled in two different ways depending on the origin of the microop. In the case of combinationally generated microops, the instructions are actually generated with the correct parameters in place. This is how the macroops in SPARC work. If the microops come from the ROM, they are specilized afterwards by a special hardware unit which operates on them before they pass on to the rest of the pipeline. The "emulation environment", aka the particulars of the instruction being emulated by the microop sequence, is stored and is used by this specializer to get the values to substitute in. In hardware, this means recognizing a bit pattern and replacing the value with a different one on a match. In C++, this becomes more complicated. There seem to be three options.<br />
<br />
* The instructions could be allocated with the correct parameters, similar to the combinational case. This has the benefit that the instruction is totally specialized for it's environment from the very start.<br />
* The instructions could be specialized after the fact by adding a new function. This lets you reuse instructions without having to fully reallocate them.<br />
* The instructions could be specialized by adding in an external blob of data which holds all the relevant parameters.<br />
<br />
The simplest approach would be the first, but allocating a new microop for every instruction from the ROM would likely have a fairly high performance overhead. The later two approaches help with that somewhat by letting you skip actually allocating memory, but they prevent you from using more than one version of a microop at a time.<br />
<br />
Immediate values are handled by making ROM based microops generate a few combinational microops before actually going to the ROM. These push the immediate parameters into certain microcode registers which the ROM code is written to use.<br />
<br />
<br />
== Microop Allocation ==<br />
<br />
Microops are allocated in two different ways. When they're generated combinationally, they can be set up by their containing macroop when ''it'' gets allocated. Existing mechanisms which cache regular instructions also cache the macroop, and the microops end up being saved as well. With microops that come from the microcode ROM, microops aren't stored with the macroop, and the caching mechanism doesn't automatically work.<br />
<br />
Also, the microop that should be generated from a particular microopc will depend, probably significantly, on the macroop it was generated for. This ties in with the above topic about parameter specialization, and means that the ROM can't directly hold instatiations of it's microops which would be a handy caching mechanism.<br />
<br />
One potential solution would be for the ROM to have it's own cache of microop instantiations. This wouldn't be as simple as in the regular decode case because there aren't handy machine code representations to work with, but the micropc might be used instead. Unlike regular instruction memory, the same micropc should always refer to the same instruction. Note that while this might seem like a reasonable assumption, there are situations I can imagine someone at some point might want to have dynamic microcode.<br />
<br />
Another option would be to actually store the microops in the macroop which requested them. The draw back here is that it's possible that you're macroop might need a non constant and large set of microops to implement itself, and it might be difficult to keep track of what's been instantiated and what hasn't.<br />
<br />
Yet another solution would be to try to work the microops into the main cache somehow. This doesn't sound like a great idea since they really aren't the same thing.<br />
<br />
<br />
== Macroop Argument Specialization ==<br />
<br />
This sounds like but is very different from microop parameter specialization. This refers to generating groups of macroops which all perform the same operation, but use different arguments from different places including memory.<br />
<br />
A possible solution would be to use microop specialization creatively to use register indices from the appropriate places and to put loads and stores as prefixes and suffixes on the body of the operation. This might not work because while the entry point could be before or after the load, the macroop wouldn't know to not execute the store suffix. There may also be cases where more than one value is loaded or stored. Entry points only one instruction apart also seem to conflict with the one example that is available which deals with instructions in quads, or in other words specialized bundles of four instructions.<br />
<br />
Another solution, which looks like the one that may be implemented in actual hardware, is to have two copies of each instruction, one that uses memory and one that doesn't. It would be cumbersome to write a new version of each of these instructions by hand, so a preprocessor might be needed. As mentioned in the page about the microcode assembler, this preprocessor would likely mimic nasm syntax and be totally separate from the actual assembler.<br />
<br />
There also needs to be clean syntax to differentiate what version of an instruction to use, and what register indices, etc, to feed into it. In the previous version, this was done by specifying argument types in special "tags" that were processed by the instruction format. Because the instructions are mostly already set up, the format's job is only to specify the structure of the decoder as directed by the tags.</div>Gblack