No description
Find a file
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
build_opts Add build hooks for x86. 2007-03-03 16:01:48 +00:00
configs Fix mcf benchmark object so it gets the arguments it expects. 2007-03-22 00:10:47 -04:00
ext New directory structure: 2006-05-22 14:29:33 -04:00
src 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. 2007-04-04 23:35:20 +00:00
tests Update refs for recent changes. 2007-03-30 16:59:40 -04:00
util Update to statetrace. This will break it, but I want to make sure it gets into mercurial. 2007-03-15 06:10:50 -04:00
AUTHORS AUTHORS: 2006-08-17 00:44:54 -04:00
LICENSE Remove authors from copyright. 2006-05-28 23:26:15 -04:00
README Update for 2.0 beta 1 patch 1 2006-08-25 15:17:25 -04:00
RELEASE_NOTES add 2.0b2 release notes 2006-11-28 16:02:13 -05:00
SConstruct Rework the way SCons recurses into subdirectories, making it 2007-03-10 23:00:54 -08:00

This is release 2.0_beta (patch 1) of the M5 simulator.

For detailed information about building the simulator and getting
started please refer to http://www.m5sim.org.

Specific pages of interest are:
http://www.m5sim.org/wiki/index.php/Compiling_M5
http://www.m5sim.org/wiki/index.php/Running_M5

Short version:

1. If you don't have SCons version 0.96.91 or newer, get it from
http://wwww.scons.org.

2. If you don't have SWIG version 1.3.28 or newer, get it from
http://wwww.swig.org.

3. In this directory, type 'scons build/ALPHA_SE/tests/debug/quick'.  This
will build the debug version of the m5 binary (m5.debug) for the Alpha
syscall emulation target, and run the quick regression tests on it.

If you have questions, please send mail to m5-users@m5sim.org

WHAT'S INCLUDED (AND NOT)
-------------------------

The basic source release includes these subdirectories:
 - m5: 
   - src: source code of the m5 simulator
   - tests: regression tests
   - ext: less-common external packages needed to build m5
   - system/alpha: source for Alpha console and PALcode

To run full-system simulations, you will need compiled console,
PALcode, and kernel binaries and one or more disk images.  These files
are collected in a separate archive, m5_system.tar.bz2.  This file
can he downloaded separately.

M5 supports Linux 2.4/2.6, FreeBSD, and the proprietary Compaq/HP
Tru64 version of Unix. We are able to distribute Linux and FreeBSD
bootdisks, but we are unable to distribute bootable disk images of
Tru64 Unix. If you have a Tru64 license and are interested in
obtaining disk images, contact us at m5-dev@eecs.umich.edu.