search for: modrm

...instruction encoding and disassembling. These fields attempt to classify various aspects of the complicated X86 encoding system. Fields ------ Opcode - Single byte value indicating the opcode within the various X86 opcode maps. For most instructions this the value between prefixes and the ModRM byte. Form - Classifies how operands are encoded into the various fields that encode operands, i.e. modrm.reg, modrm.rm, vex.vvvv, rex.r, rex.x, rex.b, etc. See format list below. ImmT - Determines the size of the immediate, if any at the end of the instruction. OpSize...

I am attempting to create an instruction which takes a single 64-bit immediate. This doesn't seem like a thing that would exist already (because who needs an instruction which just takes an immediate?) How might I implement this easily? Perhaps I could use a format which encodes a register, which is then unused? Thanks for the help. Gus -------------- next part -------------- An HTML

...n"); + for ( j = 1; j <= 2; j++ ) { #if defined(__i386__) --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -176,7 +176,7 @@ static uint8_t twobyte_table[256] = { /* 0x08 - 0x0F */ ImplicitOps, ImplicitOps, 0, 0, 0, ImplicitOps|ModRM, 0, 0, /* 0x10 - 0x17 */ - 0, 0, 0, 0, 0, 0, 0, 0, + ImplicitOps|ModRM, ImplicitOps|ModRM, 0, 0, 0, 0, 0, 0, /* 0x18 - 0x1F */ ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|ModRM, ImplicitOps|M...

...Format.td, we have this: class Format<bits<7> val> { bits<7> Value = val; } def MRMDestReg : Format<3> i think eventually, MRMDestReg is mapped back to ModMRM byte. but this still doesnt make sense to me why MRMDestReg is defined this way, and how it is mapped back to ModRM byte. any hint please? thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140424/2568625f/attachment.html>

...ins i64imm:$b), "cache_operand_b_i64\t$b", [(int_cache_operand_b_i64 i64imm:$b)]>, Requires<[In64BitMode]>; However, when I compile, I'm getting errors of the form: Error: Primary decode conflict: TEST64ri32 would overwrite CACHE_OPERAND_B64i ModRM 199 Opcode 247 Context IC_64BIT_REXW When I look at the definition of TEST64ri32, I see: let Predicates = [In64BitMode] in def TEST64ri32 : BinOpRI_F<0xF6, "test", Xi64, X86testpat, MRM0r>; It looks like TEST64ri32 is using opcode 0xF6 -- why is there a conflict with 0xF1? Ev...

On Tue, Jul 30, 2019 at 12:12:54PM -0700, Thomas Garnier wrote: > if PIE is enabled, switch the paravirt assembly constraints to be > compatible. The %c/i constrains generate smaller code so is kept by > default. > > Position Independent Executable (PIE) support will allow to extend the > KASLR randomization range below 0xffffffff80000000. > > Signed-off-by: Thomas

On Tue, Jul 30, 2019 at 12:12:54PM -0700, Thomas Garnier wrote: > if PIE is enabled, switch the paravirt assembly constraints to be > compatible. The %c/i constrains generate smaller code so is kept by > default. > > Position Independent Executable (PIE) support will allow to extend the > KASLR randomization range below 0xffffffff80000000. > > Signed-off-by: Thomas

...REX.B, but for "por" (0F EB), this should be ignored. there are quite a lot of other instructions taking into account REX like this, while according to the manual, REX should be ignored. i dont see any clean solution for this issue without some significant changes into the way we decode ModRM & providing more information to .td files. any idea? thanks. Jun -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141224/2206cb49/attachment.html>

...be ignored. >> >> there are quite a lot of other instructions taking into account REX like >> this, while according to the manual, REX should be ignored. >> >> i dont see any clean solution for this issue without some significant >> changes into the way we decode ModRM & providing more information to .td >> files. >> >> any idea? >> >> thanks. >> Jun >> > > > -- > ~Craig > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachm...

...relative call is 6 bytes, Well, before it, the relative CALL is a CALL reg/mem64, i.e. the target is mem64. For example: ffffffff81025c45: ff 14 25 68 37 02 82 callq *0xffffffff82023768 That address there is practically pv_ops + offset. Now, in the opcode bytes you have 0xff opcode, ModRM byte 0x14 and SIB byte 0x25, and 4 bytes imm32 offset. And this is 7 bytes. What it becomes is: ffffffff81025cd0: ff 15 fa d9 ff 00 callq *0xffd9fa(%rip) # ffffffff820236d0 <pv_ops+0x30> ffffffff81025cd6: 90 nop which is a RIP-relative, i.e.,...

Hi, Sorry for the newbie question. I downloaded llvm 1.8a and llvm-gcc3.4, tried out the simple "Hello, World" program but got the following error. My system is RedHat 9 $ ./hello lli: /home//llvm/lib/Target/X86/X86CodeEmitter.cpp:208: unsigned char ModRMByte(unsigned int, unsigned int, unsigned int): Assertion `Mod < 4 && RegOpcode < 8 && RM < 8 && "ModRM Fields out of range!"' failed. lli((anonymous namespace)::PrintStackTrace()+0x15)[0x84ab499] /lib/tls/libc.so.6[0x3d7ec8] /lib/tls/libc.so.6(abort+0x...

...loaded llvm and tried out the simple "Hello, World" program but got the following error. What am I missing? I am running RHAS 3 Update 4 with GCC 3.2.3. Thanks, Bharadwaj $ ./hello lli: /home/proj/skokomish/syadaval/ia32/Sandbox/llvm/lib/Target/X86/X86CodeEmitter.cpp:208: unsigned char ModRMByte(unsigned int, unsigned int, unsigned int): Assertion `Mod < 4 && RegOpcode < 8 && RM < 8 && "ModRM Fields out of range!"' failed. lli((anonymous namespace)::PrintStackTrace()+0x15)[0x84ab499] /lib/tls/libc.so.6[0x3d7ec8] /lib/tls/libc.so.6(abort+0x...

...86__) --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -1454,10 +1454,10 @@ x86_emulate( /* VEX */ generate_exception_if(rex_prefix || vex.pfx, EXC_UD, -1); - vex.raw[0] = b; + vex.raw[0] = modrm; if ( b & 1 ) { - vex.raw[1] = b; + vex.raw[1] = modrm; vex.opcx = vex_0f; vex.x = 1; vex.b = 1; @@ -1479,10 +1479,7 @@ x86_emulate( }...

...: /* GS override */ - opnd_sel = read_sreg(regs, gs); + opnd_sel = read_sreg(v, regs, gs); if ( !opnd_sel ) opnd_sel = dpl; continue; @@ -2736,7 +2736,7 @@ static void emulate_gate_op(struct cpu_u switch ( modrm & 7 ) { default: - opnd_sel = read_sreg(regs, ds); + opnd_sel = read_sreg(v, regs, ds); break; case 4: case 5:...

Hi all, I'm trying to simulate an extended x86 architecture on gem5 with several new instructions. My hardware setup is done and now I'd like llvm to accept the existence of the new instruction passed in inline assembly and output the correct opcode and registers. I chose the two-byte opcode 0x0F 0x7A and I would like the instruction to have the same operands and return values as CVTPS2PI

...0/lib/Target -gen-disassembler -o /build/buildd-llvm-3.0_3.0-5-mipsel-jV6EnH/llvm-3.0-3.0/build-llvm/lib/Target/X86/Release/X86GenDisassemblerTables.inc.tmp /build/buildd-llvm-3.0_3.0-5-mipsel-jV6EnH/llvm-3.0-3.0/lib/Target/X86/X86.td Error: Primary decode conflict: ADC16ri would overwrite ADC16mi ModRM 201 Opcode 129 Context IC_OPSIZE Error: Primary decode conflict: ADC16ri would overwrite ADC16mi [pages of similar errors] Any ideas? I am available for testing. LLVM 2.9 was building fine [2]. Thanks, Sylvestre [1] Please note that mips log is available here: https://buildd.debian.org/stat...

...class VEX_W { bit hasVEX_WPrefix = 1; } > [2]. How does vex_w help in instruction selection in-addition to FMA4 > class? > The VEX prefix is part of the instruction encoding. The VEX.W bit modifies the instruction to allow a memory address as a particular source operand, depending on ModRM. The Intel AVX reference calls this "source operand swizzling". [3]. Why does only "rr" and "rm" forms have vex_w but not "mr" ? > In order to accept a memory address as the second source operand, the VEX.W bit must not be set. To accept a memory addre...

The maximum instruction length for both x86-32 and x86-64 is 15 bytes (including all prefixes, opcode, ModRM, SIB, displacement, and immediate bytes). This patch adjusts the MAX_INST_LEN to the correct value. This should reduce the size of some variables in the hypervisor code. This patch also does some minor code clean-up in the vm exit handler for VMX. This patch should apply cleanly to hg tip 9594....

...\ - if ( rep_prefix ) \ + if ( rep_prefix() ) \ __put_rep_prefix(&_regs, ctxt->regs, ad_bytes, reps_completed); \ }) @@ -1328,9 +1332,7 @@ x86_emulate( uint8_t modrm = 0, modrm_mod = 0, modrm_reg = 0, modrm_rm = 0; union vex vex = {}; unsigned int op_bytes, def_op_bytes, ad_bytes, def_ad_bytes; -#define REPE_PREFIX 1 -#define REPNE_PREFIX 2 - unsigned int lock_prefix = 0, rep_prefix = 0; + bool_t lock_prefix = 0; int override_seg = -1, rc...

...instruction, offering greater flexibility. To conceptualize: VFMADDSD xmm1, xmm2, xmm3/mem64, xmm4 VEX.W == 0 VFMADDSD xmm1, xmm2, xmm3, xmm4/mem64 VEX.W == 1 So, logically, one could create the rr pattern with the VEX.W bit set or not. The MemOp4 flag is a similar mechanism for setting the ModRM byte, indicating that the second and third source operands have been swapped. -Cameron -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121108/1ab2ea0b/attachment.html>