-The JIT already provides a set of instructions that can be easily
-mapped to a great variety of different processor instructions.
-Sometimes it may be necessary or advisable to add a new instruction
-that represent more closely an instruction in the architecture.
-Note that a mini instruction can be used to represent also a short
-sequence of CPU low-level instructions, but note that each
-instruction represents the minimum amount of code the instruction
-scheduler will handle (i.e., the scheduler won't schedule the instructions
-that compose the low-level sequence as individual instructions, but just
-the whole sequence, as an indivisible block).
-New instructions are created by adding a line in the mini-ops.h file,
-assigning an opcode and a name. To specify the input and output for
-the instruction, there are two different places, depending on the context
-in which the instruction gets used.
-If the instruction is used in the tree representation, the input and output
-types are defined by the BURG rules in the *.brg files (the usual
-non-terminals are 'reg' to represent a normal register, 'lreg' to
-represent a register or two that hold a 64 bit value, freg for a
-floating point register).
-If an instruction is used as a low-level CPU instruction, the info
-is specified in a machine description file. The description file is
-processed by the genmdesc program to provide a data structure that
-can be easily used from C code to query the needed info about the
-instruction.
-As an example, let's consider the add instruction for both x86 and ppc:
-
-x86 version:
- add: dest:i src1:i src2:i len:2 clob:1
-ppc version:
- add: dest:i src1:i src2:i len:4
-
-Note that the instruction takes two input integer registers on both CPU,
-but on x86 the first source register is clobbered (clob:1) and the length
-in bytes of the instruction differs.
-Note that integer adds and floating point adds use different opcodes, unlike
-the IL language (64 bit add is done with two instructions on 32 bit architectures,
-using a add that sets the carry and an add with carry).
-A specific CPU port may assign any meaning to the clob field for an instruction
-since the value will be processed in an arch-specific file anyway.
-See the top of the existing cpu-pentium.md file for more info on other fields:
-the info may or may not be applicable to a different CPU, in this latter case
-the info can be ignored.
-The code in mini.c together with the BURG rules in inssel.brg, inssel-float.brg
-and inssel-long32.brg provides general purpose mappings from the tree representation
-to a set of instructions that should be easily implemented in any architecture.
-To allow for additional arch-specific functionality, an arch-specific BURG file
-can be used: in this file arch-specific instructions can be selected that provide
-better performance than the general instructions or that provide functionality
-that is needed by the JIT but that cannot be expressed in a general enough way.
-As an example, x86 has the special instruction "push" to make it easier to
-implement the default call convention (passing arguments on the stack): almost
-all the other architectures don't have such an instruction (and don't need it anyway),
-so we added a special rule in the inssel-x86.brg file for it.
-
-So, one of the first things needed in a port is to write a cpu-$(arch).md machine
-description file and fill it with the needed info. As a start, only a few
-instructions can be specified, like the ones required to do simple integer
-operations. The default rules of the instruction selector will emit the common
-instructions and so we're ready to go for the next step in porting the JIT.
-
+ The JIT already provides a set of instructions that can be
+ easily mapped to a great variety of different processor
+ instructions. Sometimes it may be necessary or advisable to
+ add a new instruction that represent more closely an
+ instruction in the architecture. Note that a mini instruction
+ can be used to represent also a short sequence of CPU
+ low-level instructions, but note that each instruction
+ represents the minimum amount of code the instruction
+ scheduler will handle (i.e., the scheduler won't schedule the
+ instructions that compose the low-level sequence as individual
+ instructions, but just the whole sequence, as an indivisible
+ block).
+
+ New instructions are created by adding a line in the
+ mini-ops.h file, assigning an opcode and a name. To specify
+ the input and output for the instruction, there are two
+ different places, depending on the context in which the
+ instruction gets used.
+
+ If the instruction is used in the tree representation, the
+ input and output types are defined by the BURG rules in the
+ *.brg files (the usual non-terminals are 'reg' to represent a
+ normal register, 'lreg' to represent a register or two that
+ hold a 64 bit value, freg for a floating point register).
+
+ If an instruction is used as a low-level CPU instruction, the
+ info is specified in a machine description file. The
+ description file is processed by the genmdesc program to
+ provide a data structure that can be easily used from C code
+ to query the needed info about the instruction.
+
+ As an example, let's consider the add instruction for both x86
+ and ppc:
+
+ x86 version:
+ add: dest:i src1:i src2:i len:2 clob:1
+ ppc version:
+ add: dest:i src1:i src2:i len:4
+
+ Note that the instruction takes two input integer registers on
+ both CPU, but on x86 the first source register is clobbered
+ (clob:1) and the length in bytes of the instruction differs.
+
+ Note that integer adds and floating point adds use different
+ opcodes, unlike the IL language (64 bit add is done with two
+ instructions on 32 bit architectures, using a add that sets
+ the carry and an add with carry).
+
+ A specific CPU port may assign any meaning to the clob field
+ for an instruction since the value will be processed in an
+ arch-specific file anyway.
+
+ See the top of the existing cpu-pentium.md file for more info
+ on other fields: the info may or may not be applicable to a
+ different CPU, in this latter case the info can be ignored.
+
+ The code in mini.c together with the BURG rules in inssel.brg,
+ inssel-float.brg and inssel-long32.brg provides general
+ purpose mappings from the tree representation to a set of
+ instructions that should be easily implemented in any
+ architecture. To allow for additional arch-specific
+ functionality, an arch-specific BURG file can be used: in this
+ file arch-specific instructions can be selected that provide
+ better performance than the general instructions or that
+ provide functionality that is needed by the JIT but that
+ cannot be expressed in a general enough way.
+
+ As an example, x86 has the special instruction "push" to make
+ it easier to implement the default call convention (passing
+ arguments on the stack): almost all the other architectures
+ don't have such an instruction (and don't need it anyway), so
+ we added a special rule in the inssel-x86.brg file for it.
+
+ So, one of the first things needed in a port is to write a
+ cpu-$(arch).md machine description file and fill it with the
+ needed info. As a start, only a few instructions can be
+ specified, like the ones required to do simple integer
+ operations. The default rules of the instruction selector will
+ emit the common instructions and so we're ready to go for the
+ next step in porting the JIT.
+