search for: modr

...CTargetDesc/X86MCCodeEmitter.cpp > b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp > index 7952607..12a30cf 100644 > --- a/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp > +++ b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp > @@ -402,6 +402,56 @@ void X86MCCodeEmitter::EmitMemModRMByte(const MCInst > &MI, unsigned Op, > > unsigned BaseRegNo = BaseReg ? GetX86RegNum(Base) : -1U; > > + // 16-bit addressing forms of the ModR/M byte have a different encoding > for > + // the R/M field and are far more limited in which registers can be > used. &gt...

On Mon, 2013-12-16 at 19:46 +0000, Eric Christopher wrote: > > I'm catching up on email at the moment so I don't know if you've done > this, but patches should go to llvm-commits for review if you wouldn't > mind. I have done so. I've since worked out that the signed 16-bit relocation is probably entirely pointless and I should just drop the assert() from the

...--git a/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp index 7952607..12a30cf 100644 --- a/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp +++ b/lib/Target/X86/MCTargetDesc/X86MCCodeEmitter.cpp @@ -402,6 +402,56 @@ void X86MCCodeEmitter::EmitMemModRMByte(const MCInst &MI, unsigned Op, unsigned BaseRegNo = BaseReg ? GetX86RegNum(Base) : -1U; + // 16-bit addressing forms of the ModR/M byte have a different encoding for + // the R/M field and are far more limited in which registers can be used. + if (Is16BitMemOperand(MI, Op)) { +...

...16 XMM registers XMM16-XMM31 and 16 YMM registers YMM16-YMM31. In order to encode the new registers of 16-31 and the additional instructions, a new encoding prefix called EVEX, which extends the existing VEX encoding, was introduced as shown below: The EVEX encoding format: EVEX Opcode ModR/M [SIB] [Disp32] / [Disp8*N] [Immediate] # of bytes: 4 1 1 1 4 / 1 1 The existing VEX encoding format: [VEX] OPCODE ModR/M [SIB] [DISP] [IMM] # of bytes: 0,2,3 1 1 0,1 0,1,2,4 0,1 Note that the EVEX prefix requires 4 bytes whereas the...

...YMM16-YMM31. > > In order to encode the new registers of 16-31 and the additional > instructions, a new encoding prefix called EVEX, which extends the > existing VEX encoding, was introduced as shown below: > > > > The EVEX encoding format: > > EVEX Opcode ModR/M [SIB] [Disp32] / [Disp8*N] [Immediate] > > # of bytes: 4 1 1 1 4 / 1 1 > > > > The existing VEX encoding format: > > [VEX] OPCODE ModR/M [SIB] [DISP] [IMM] > > # of bytes: 0,2,3 1 1 0,1 0,1,2,4 0,1 > &...

Nav?tivte na?e webov? str?nky infotigra a objevte, jak JEDNA jedin? mal? modr? pilulka m??e do?ivotn? zm?nit VA?I sexu?ln? v?konnost! ? V??en? z?kazn?k! V?deck? testy prok?zaly, ?e TIGRA funguje l?pe ne? jak?koli jin? pilulka. Test na 800 mu??ch ve v?ku 21 a? 80 let prok?zal ohromuj?c? v?sledky: ? 1. A? o 71 %...

...16 XMM registers XMM16-XMM31 and 16 YMM registers YMM16-YMM31. In order to encode the new registers of 16-31 and the additional instructions, a new encoding prefix called EVEX, which extends the existing VEX encoding, was introduced as shown below: The EVEX encoding format: EVEX Opcode ModR/M [SIB] [Disp32] / [Disp8*N] [Immediate] # of bytes: 4 1 1 1 4 / 1 1 The existing VEX encoding format: [VEX] OPCODE ModR/M [SIB] [DISP] [IMM] # of bytes: 0,2,3 1 1 0,1 0,1,2,4 0,1 Note that the EVEX prefix requires 4 bytes whereas the...

...16 XMM registers XMM16-XMM31 and 16 YMM registers YMM16-YMM31. In order to encode the new registers of 16-31 and the additional instructions, a new encoding prefix called EVEX, which extends the existing VEX encoding, was introduced as shown below: The EVEX encoding format: EVEX Opcode ModR/M [SIB] [Disp32] / [Disp8*N] [Immediate] # of bytes: 4 1 1 1 4 / 1 1 The existing VEX encoding format: [VEX] OPCODE ModR/M [SIB] [DISP] [IMM] # of bytes: 0,2,3 1 1 0,1 0,1,2,4 0,1 Note that the EVEX prefix requires 4 bytes whereas the...

- we used the C4/C5 (first prefix) byte instead of the apparent ModR/M one as the second prefix byte - early decoding normalized vex.reg, thus corrupting it for the main consumer (copy_REX_VEX()), resulting in #UD on the two-operand instructions we emulate Also add respective test cases to the testing utility plus - fix get_fpu() (the fall-through order was i...

...ndex, ///< Target-dependent index+offset operand. At https://llvm.org/docs/CodeGenerator.html#x86-addressing-mode The x86 has a very flexible way of accessing memory. It is capable of forming memory addresses of the following expression directly in integer instructions (which use ModR/M addressing): SegmentReg: Base + [1,2,4,8] * IndexReg + Disp32 In order to represent this, LLVM tracks no less than 5 operands for each memory operand of this form. This means that the “load” form of ‘mov’ has the following MachineOperands in this order: Index: 0 | 1...

...k it is. For each instruction: 1. Compute how many bytes of prefix. The code is there in X86CodeEmitter except all you need is the size, not the prefixes being emitted. 2. For each instruction format, e.g AddRegFrm, MRMDestReg, it's either only one single byte for opcode or one additional ModR/M byte. Again, all the information is right there. 3. Some memory instructions needs a SIB byte. 4. Process the operands! Some special handling for operands that made up of the memory address. But the logic is all there in emitMemModRMByte. What do you think? Evan > > >> >&g...

Evan Cheng wrote: > On Apr 1, 2008, at 12:50 AM, Nicolas Geoffray wrote: > > > That's a hack. :-) It is if you think that code emitter should only be used for actually writing somewhere the data. It is not if you find it another useful utility ;-) > Some targets already have ways to compute the exact > size of a function. See ARM::GetFunctionSize()

...tion: > 1. Compute how many bytes of prefix. The code is there in > X86CodeEmitter except all you need is the size, not the prefixes being > emitted. > 2. For each instruction format, e.g AddRegFrm, MRMDestReg, it's either > only one single byte for opcode or one additional ModR/M byte. Again, > all the information is right there. > 3. Some memory instructions needs a SIB byte. > 4. Process the operands! Some special handling for operands that made > up of the memory address. But the logic is all there in > emitMemModRMByte. > > What do you think...

...ytes of prefix. The code is there in >> X86CodeEmitter except all you need is the size, not the prefixes >> being >> emitted. >> 2. For each instruction format, e.g AddRegFrm, MRMDestReg, it's >> either >> only one single byte for opcode or one additional ModR/M byte. Again, >> all the information is right there. >> 3. Some memory instructions needs a SIB byte. >> 4. Process the operands! Some special handling for operands that made >> up of the memory address. But the logic is all there in >> emitMemModRMByte. >> >...

...t; if (CurOp != NumOps) > - emitConstant(MI.getOperand(CurOp++).getImm(), sizeOfImm(Desc)); > + emitConstant(MI.getOperand(CurOp++).getImm(), > X86InstrInfo::sizeOfImm(Desc)); > break; > } > case X86II::MRMDestMem: { > @@ -706,7 +571,7 @@ > emitMemModRMByte(MI, CurOp, getX86RegNum(MI.getOperand(CurOp > +4).getReg())); > CurOp += 5; > if (CurOp != NumOps) > - emitConstant(MI.getOperand(CurOp++).getImm(), sizeOfImm(Desc)); > + emitConstant(MI.getOperand(CurOp++).getImm(), > X86InstrInfo::sizeOfImm(Desc)); >...

OK, here's a new patch that adds the infrastructure and the implementation for X86, ARM and PPC of GetInstSize and GetFunctionSize. Both functions are virtual functions defined in TargetInstrInfo.h. For X86, I moved some commodity functions from X86CodeEmitter to X86InstrInfo. What do you think? Nicolas Evan Cheng wrote: > > I think both of these belong to TargetInstrInfo. And