search for: 0x0f

...) >> (32 - (5)))) + (d ^ (b & (c ^ d))) + 0x5a827999L + x[0]; b = (((b) << (30)) | ((b) >> (32 - (30)))); } while (0); do { d += (((e) << (5)) | ((e) >> (32 - (5)))) + (c ^ (a & (b ^ c))) + 0x5a827999L + (tm = x[16 & 0x0f] ^ x[(16 - 14) & 0x0f] ^ x[(16 - 8) & 0x0f] ^ x[(16 - 3) & 0x0f], (x[16 & 0x0f] = (((tm) << (1)) | ((tm) >> (32 - (1)))))); a = (((a) << (30)) | ((a) >> (32 - (30)))); } while (0); do { e += (((a) <<...

...: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2, %[re]ax > .mmu_read_cr3 = { 0x0f, 0x20, 0xd8 }, // mov %cr3, %[re]ax > -# ifdef CONFIG_X86_64 > .mmu_write_cr3 = { 0x0f, 0x22, 0xdf }, // mov %rdi, %cr3 > .irq_restore_fl = { 0x57, 0x9d }, // push %rdi; popfq > .cpu_wbinvd = { 0x0f, 0x09 }, //...

...: > -# else > - const unsigned char cpu_iret[1]; > -# endif > }; > > static const struct patch_xxl patch_data_xxl = { > @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { > .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax > .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2, %[re]ax > .mmu_read_cr3 = { 0x0f, 0x20, 0xd8 }, // mov %cr3, %[re]ax > -# ifdef CONFIG_X86_64 > .mmu_write_cr3 = { 0x0f, 0x22, 0xdf }, // mov %rdi, %cr3 > .irq_restore_fl = { 0x57, 0x9d }, // push %rdi; popfq > .cpu_wbinvd = { 0x0f, 0x09 }, //...

...e different operand orders for at&t syntax vs intel syntax. Anything after $ matches the name in the outs/in part of the instruction. IIC_SSE_PREFETCH is part of the scheduler system to provide latency/throughput information about the instruction. PD indicates the instruction should be on the 0x0f two byte opcode map with a 0x66 prefix. Most common other values in place of PD TB - 0x0f opcode map no prefix(0x66, 0xf2, 0xf3) and use of one of those prefixes should be ignored by the disassembler. PS - 0x0f opcode map no prefix, but if the disassembler sees a prefix it should not decode to thi...

...rt[set]: (3 bytes) => 0f 00 5e 55.348945 Set report succeeded 55.348956 instcmd: SUCCEED Value 30 is converted to 24064, and this seems the delay that is configured on the device to complete its shutdown: [...] 56.358009 Path: UPS.PowerSummary.DelayBeforeShutdown, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 24064 58.721177 Path: UPS.PowerSummary.DelayBeforeShutdown, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 23865 60.576175 Path: UPS.PowerSummary.DelayBeforeShutdown, Type: Feature, ReportID: 0x0f, Offset: 0, Size: 16, Value: 23864 62.471044 Path: UPS....

Craig, thanks for the quick response. That helps a lot. I had no clue they were buried in there, though I guess I should have looked harder -- the hex should have given me a clue, perhaps! For the sake of my own edification (and not taking up too much of your time) I will try to generate it myself. I've found the definition of the "I" class at line 358 of

...or at&t syntax vs intel syntax. Anything after $ matches the name > in the outs/in part of the instruction. > > IIC_SSE_PREFETCH is part of the scheduler system to provide > latency/throughput information about the instruction. > > PD indicates the instruction should be on the 0x0f two byte opcode map > with a 0x66 prefix. > > Most common other values in place of PD > TB - 0x0f opcode map no prefix(0x66, 0xf2, 0xf3) and use of one of those > prefixes should be ignored by the disassembler. > PS - 0x0f opcode map no prefix, but if the disassembler sees a prefi...

...e -arch=x86-64 <stdin>:1:1: warning: invalid instruction encoding Similarly, 3DNow seems broken, too. $ echo "pavgusb %mm2, %mm1"|./Release+Asserts/bin/llvm-mc -assemble -arch=x86-64 -show-encoding -x86-asm-syntax=att .text pavgusb %mm2, %mm1 # encoding: [0x0f,0x0f,0xca,0xbf] $ echo "0x0f,0x0f,0xca,0xbf" |./Release+Asserts/bin/llvm-mc -disassemble -arch=x86-64 <stdin>:1:1: warning: invalid instruction encoding Or I did not use LLVM-MC properly? Any idea?? Thank you, Jun -------------- next part -------------- An HTML attachment was...

If I'm using the SR-IOV Pool assignment method (from http://wiki.libvirt.org/page/Networking#Assignment_from_a_pool_of_SRIOV_VFs_in_a_libvirt_.3Cnetwork.3E_definition ), how would I check how many virtual functions are already in use? Is there a method other then looping through all the active guests and determining if they're using the SR-IOV interface?

...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 instruction. I have found this link (https://llvm.org/docs/ExtendingLLVM.html) which claims "Before you invest a significant amount of effort into a non-trivial extension, *ask on the list*" so...

...g: invalid instruction encoding > > > Similarly, 3DNow seems broken, too. > > > $ echo "pavgusb %mm2, %mm1"|./Release+Asserts/bin/llvm-mc -assemble -arch=x86-64 -show-encoding -x86-asm-syntax=att > .text > pavgusb %mm2, %mm1 # encoding: [0x0f,0x0f,0xca,0xbf] > > $ echo "0x0f,0x0f,0xca,0xbf" |./Release+Asserts/bin/llvm-mc -disassemble -arch=x86-64 > <stdin>:1:1: warning: invalid instruction encoding > > > > > Or I did not use LLVM-MC properly? Any idea?? > > Thank you, > Jun > ___...

...got no PIN requester on either phone and PC. On the same time on another console I have: [root at miho ~]# hcidump HCI sniffer - Bluetooth packet analyzer ver 1.32 device: hci0 snap_len: 1028 filter: 0xffffffff (scan) < HCI Command: Inquiry (0x01|0x0001) plen 5 > HCI Event: Command Status (0x0f) plen 4 > HCI Event: Inquiry Result with RSSI (0x22) plen 15 > HCI Event: Inquiry Result with RSSI (0x22) plen 15 > HCI Event: Inquiry Result with RSSI (0x22) plen 15 > HCI Event: Inquiry Result with RSSI (0x22) plen 15 > HCI Event: Inquiry Result with RSSI (0x22) plen 15 > HCI Ev...

...gned char cpu_iret[1]; >> -# endif >> }; >> >> static const struct patch_xxl patch_data_xxl = { >> @@ -42,7 +38,6 @@ static const struct patch_xxl patch_data_xxl = { >> .irq_save_fl = { 0x9c, 0x58 }, // pushf; pop %[re]ax >> .mmu_read_cr2 = { 0x0f, 0x20, 0xd0 }, // mov %cr2, %[re]ax >> .mmu_read_cr3 = { 0x0f, 0x20, 0xd8 }, // mov %cr3, %[re]ax >> -# ifdef CONFIG_X86_64 >> .mmu_write_cr3 = { 0x0f, 0x22, 0xdf }, // mov %rdi, %cr3 >> .irq_restore_fl = { 0x57, 0x9d }, // push %rdi; popfq >> .cpu_wbinv...

...y VFs in the pool are using.* <name>hostnet</name> <uuid>6b49be3c-bb91-c16d-b475-2929678720f4</uuid> <forward mode='hostdev' managed='yes'> <pf dev='eth2'/> <address type='pci' domain='0x0000' bus='0x0f' slot='0x10' function='0x0'/> <address type='pci' domain='0x0000' bus='0x0f' slot='0x10' function='0x2'/> <address type='pci' domain='0x0000' bus='0x0f' slot='0x10' function='0x4...

...below. it seems this happens with all SSECC related instructions? thanks, Jun $ echo "cmpps xmm1, xmm2, 23" | ./Release+Asserts/bin/llvm-mc -assemble -triple=x86_64 --output-asm-variant=1 -x86-asm-syntax=intel -show-encoding .text cmpps xmm1, xmm2, 23 # encoding: [0x0f,0xc2,0xca,0x17] $ echo "0x0f,0xc2,0xca,0x17"|./Release+Asserts/bin/llvm-mc -disassemble -triple=x86_64 --output-asm-variant=1 .text <stdin>:1:1: warning: invalid instruction encoding 0x0f,0xc2,0xca,0x17 -------------- next part -------------- An HTML attachment was scrubbed......

0x0f 0x6f 0xc8 And 0x0f 0x7f 0xc1 Should both be movq % mm0, % mm1. (AT&T) However, llvm 3.4 at least does not recognise the second variant as being a valid instruction. We are currently compiling up latest src incase it has been fixed. If not, could someone take a look or recommend how to fix?...

...hanks, >> Jun >> >> >> >> $ echo "cmpps xmm1, xmm2, 23" | ./Release+Asserts/bin/llvm-mc -assemble >> -triple=x86_64 --output-asm-variant=1 -x86-asm-syntax=intel -show-encoding >> .text >> cmpps xmm1, xmm2, 23 # encoding: [0x0f,0xc2,0xca,0x17] >> >> >> $ echo "0x0f,0xc2,0xca,0x17"|./Release+Asserts/bin/llvm-mc -disassemble >> -triple=x86_64 --output-asm-variant=1 >> .text >> <stdin>:1:1: warning: invalid instruction encoding >> 0x0f,0xc2,0xca,0x17 >> >...

...0x4E, 0x96, 0x07, 0x00, 0x07, 0x03, 0x00, 0x00, 0x00, 0x08, 0x00, - 0x3D, 0x17, 0x96, 0x08, 0x00, 0x07, 0x03, 0x00, 0x00, 0x00, 0x02, 0x08, 0x0C, 0x1C, 0x96, 0x02, - 0x00, 0x08, 0x04, 0x4E, 0x96, 0x07, 0x00, 0x07, 0x03, 0x00, 0x00, 0x00, 0x08, 0x06, 0x3D, 0x17, - 0x96, 0x13, 0x00, 0x08, 0x0F, 0x07, 0x02, 0x00, 0x00, 0x00, 0x07, 0x6A, 0x00, 0x00, 0x00, 0x07, - 0x02, 0x00, 0x00, 0x00, 0x08, 0x0D, 0x3D, 0x1D, 0x96, 0x09, 0x00, 0x08, 0x0E, 0x07, 0x6A, 0x00, - 0x00, 0x00, 0x08, 0x0F, 0x1C, 0x96, 0x02, 0x00, 0x08, 0x04, 0x4E, 0x96, 0x07, 0x00, 0x07, 0x03, - 0x00, 0x00, 0x00, 0x08,...

There is a problem on X86 disassembler for instructions beginning with x86 prefix : $ echo "0x66 0x0f 0x6f 0x8f 0x00 0x00 0x00 0x00" | llvm-mc --disassemble movdqa (%edi), %xmm1 $ echo "0x53 0x66 0x0f 0x6f 0x8f 0x00 0x00 0x00 0x00" | llvm-mc --disassemble pushl %ebx <stdin>:1:6: warning: invalid instruction encoding 0x53 0x66 0x0f 0x6f 0x8f 0x00 0x00 0x00 0x...

...; +static int buffer; + #define LSSMagic LSSHeader.LSSMagic #define GraphXSize LSSHeader.GraphXSize #define GraphYSize LSSHeader.GraphYSize @@ -114,15 +117,17 @@ static int vgasetmode(void) static inline char getnybble(void) { - char data = getc(fd); - - if (data & 0x10) { - data &= 0x0F; - return data; + if (buffer_empty) { + buffer_empty = 0; + buffer = getc(fd); + if (buffer == -1) + printf("EOF!\n"); + } else { + buffer >>= 4; + buffer_empty = 1; } - data = getc(fd); - return (data & 0x0F); + return buffer & 0xF; } /* @@ -139,7 +144,9 @@...