Commit graph

11 commits

Author SHA1 Message Date
Gabe Black
1f7ed5b7b4 Big changes to use the new microcode assembler.
--HG--
extra : convert_revision : 7d1a43c5791a2e7e30533746da3dd7036a5b8799
2007-06-08 16:09:43 +00:00
Gabe Black
41bc0fc5b2 Reworking x86's microcode system. This is a work in progress, and X86 doesn't compile.
src/arch/x86/isa/decoder/one_byte_opcodes.isa:
src/arch/x86/isa/macroop.isa:
src/arch/x86/isa/main.isa:
src/arch/x86/isa/microasm.isa:
src/arch/x86/isa/microops/base.isa:
src/arch/x86/isa/microops/microops.isa:
src/arch/x86/isa/operands.isa:
src/arch/x86/isa/microops/regop.isa:
src/arch/x86/isa/microops/specop.isa:
    Reworking x86's microcode system

--HG--
extra : convert_revision : cab66be59ed758b192226af17eddd5a86aa190f3
2007-06-04 15:59:20 +00:00
Gabe Black
9f4ebf9156 Reworked x86 a bit
--HG--
extra : convert_revision : def1a30e54b59c718c451a631a1be6f8e787e843
2007-04-10 17:25:15 +00:00
Gabe Black
85f9213b8a Accidentally didn't save when moving the specialization code out of here.
--HG--
extra : convert_revision : 1ffe0c497e10fef1eb84b3c97c00b98d820fbb97
2007-04-09 01:08:05 +00:00
Gabe Black
5d52cd6409 Move the instruction specialization stuff out of the microassembler file, and added some comments to main.isa
--HG--
extra : convert_revision : 1534ae7d5a9e95bf662d79a04f9286c227541c6c
2007-04-06 16:55:56 +00:00
Gabe Black
59df95c7e6 Consolidated the microcode assembler to help separate it from more x86-centric stuff.
--HG--
extra : convert_revision : 5e7e8026e24ce44a3dac4a358e0c3e5560685958
2007-04-06 16:39:25 +00:00
Gabe Black
2a1c102f25 Refactored the x86 isa description some more. There should be more seperation between x86 specific parts, and those parts which are implemented in the isa description but could eventually be moved elsewhere.
--HG--
rename : src/arch/x86/isa/formats/macroop.isa => src/arch/x86/isa/macroop.isa
extra : convert_revision : 5ab40eedf574fce438d9fe90e00a496dc95c8bcf
2007-04-06 16:00:56 +00:00
Gabe Black
ff7b89beee The process of going from an instruction definition to an instruction to be returned by the decoder has been fleshed out more. The following steps describe how an instruction implementation becomes a StaticInst.
1. Microops are created. These are StaticInsts use templates to provide a basic form of polymorphism without having to make the microassembler smarter.
2. An instruction class is created which has a "templated" microcode program as it's docstring. The template parameters are refernced with ^ following by a number.
3. An instruction in the decoder references an instruction template using it's mnemonic. The parameters to it's format end up replacing the placeholders. These parameters describe a source for an operand which could be memory, a register, or an immediate. It it's a register, the register index is used. If it's memory, eventually a load/store will be pre/postpended to the instruction template and it's destination register will be used in place of the ^. If it's an immediate, the immediate is used. Some operand types, specifically those that come from the ModRM byte, need to be decoded further into memory vs. register versions. This is accomplished by making the decode_block text for these instructions another case statement based off ModRM.
4. Once all of the template parameters have been handled, the instruction goes throw the microcode assembler which resolves labels and creates a list of python op objects. If an operand is a register, it uses a % prefix, an immediate uses $, and a label uses @. If the operand is just letters, numbers, and underscores, it can appear immediately after the prefix. If it's not, it can be encolsed in non nested {}s.
5. If there is a single "op" object (which corresponds to a single microop) the decoder is set up to return it directly. If not, a macroop wrapper is created around it.

In the future, I'm considering seperating the operand type specialization from the template substitution step. A problem this introduces is that either the template arguments need to be kept around for the specialization step, or they need to be re-extracted. Re-extraction might be the way to go so that the operand formats can be coded directly into the micro assembler template without having to pass them in as parameters. I don't know if that's actually useful, though.

src/arch/x86/isa/decoder/one_byte_opcodes.isa:
src/arch/x86/isa/microasm.isa:
src/arch/x86/isa/microops/microops.isa:
src/arch/x86/isa/operands.isa:
src/arch/x86/isa/microops/base.isa:
    Implemented polymorphic microops and changed around the microcode assembler syntax.

--HG--
extra : convert_revision : e341f7b8ea9350a31e586a3d33250137e5954f43
2007-04-04 23:35:20 +00:00
Gabe Black
4285990a96 Reworking how x86's isa description works. I'm adopting the following definitions to make figuring out what's what a little easier:
MicroOp: A single operation actually implemented in hardware.
MacroOp: A collection of microops which are executed as a unit.
Instruction: An architected instruction which can be implemented with a macroop or a microop.

--HG--
extra : convert_revision : 1cfc8409cc686c75220767839f55a30551aa6f13
2007-04-04 14:31:59 +00:00
Gabe Black
61c56ffeaf A batch of changes and fixes. Macroops are now generated automatically, multiops do alot more of what they're supposed to (excluding memory operands), and microops are slightly more implemented.
--HG--
extra : convert_revision : 518059f47e11df50aa450d4a322ef2ac069c99c9
2007-04-03 15:01:09 +00:00
Gabe Black
e67a207ad3 Add a microcode assembler. A microcode "program" is a series of statements. Each statement has an optional label at the beginning, a capitilized microcode class name which is roughly equivalent to a mnemonic in a regular ISA, and then an optional series of operands seperated by white space. The operands are either a decimal constant, a label, or a code fragment surrounded by non nested {}s. Labels are a letter or underscore followed by letters, underscores, or digits. The syntax for describing code segments might need to be changed if a need arrises to have {}s in the code itself.
--HG--
extra : convert_revision : 8e5cfdd1a3c9a7e3731fdf6acd615ee82ac2b9b7
2007-03-29 17:57:18 +00:00