Actually, I remember implementing most if not all of SSE of some particular vintage, so those should work just fine. I even used a test program QEMU has to do some small amount of verification! :-) But unfortunately I think you're right that the AVX instructions which aren't also SSE instructions are basically unimplemented. They should be decoded properly however, so it's probably worth looking into why this one wasn't.
Gabe On Fri, Oct 27, 2017 at 1:07 PM, Sam Xi <[email protected]> wrote: > Ah, I see...I noticed a few commits involving decoding of VEX-prefix > instructions and so I assumed that AVX was supported. Or is the problem > that the decoding is supported to some degree but the actual execution > hasn't been implemented? > > For what I need to do at the moment, not having good x86 SIMD support is a > bit of a pain but not a dealbreaker. > > On Fri, Oct 27, 2017 at 4:02 PM Jason Lowe-Power <[email protected]> > wrote: > > > Hey Sam, > > > > I've got some bad news... I don't think we've implemented any of the AVX > > instructions in gem5. In fact, many of the SSE instructions are still > > unimplemented. > > > > Overall, the SIMD support for x86 is pretty awful, as of the last time I > > checked (some can correct me if things have changed significantly). It's > > much better for ARM. I believe most, if not all, of the NEON instructions > > are implemented. > > > > It would be great for someone to tackle the SIMD instructions on x86! In > > fact, since the ARM SIMD instructions were implemented there is a new > > vector register interface that we should migrate the x86 ISA to use. It's > > possible that AMD has some of this code internally that's not pushed out > > yet. Brad, Tony, care to comment? > > > > Sorry this isn't better news. This has been a pain point for me for a > > while, but I haven't had any time to work on it. > > > > Cheers, > > Jason > > > > On Fri, Oct 27, 2017 at 12:38 PM Sam Xi <[email protected]> wrote: > > > > > Hi all, > > > > > > I ran into a problem today involving an incorrectly decoded AVX > > > instruction. Hoping someone can tell me of a workaround or a quick fix > > > other than disabling AVX (unless that's the only solution). > > > > > > Here's a basic testcase. > > > > > > int main() { > > > float x; > > > __asm__("vxorps %0, %0, %0" : "=x"(x) : "x"(x) :); > > > > > > return x == 0; > > > } > > > > > > Compiled with gcc 5.4: > > > gcc -static -O3 -o test -mavx test.c > > > > > > Produces the following assembly: > > > > > > 00000000004005f0 <main>: > > > 4005f0: 66 0f ef c9 pxor xmm1,xmm1 > > > 4005f4: 31 c0 xor eax,eax > > > 4005f6: 66 0f ef c0 pxor xmm0,xmm0 > > > 4005fa: ba 00 00 00 00 mov edx,0x0 > > > 4005ff: c5 f8 57 c0 vxorps xmm0,xmm0,xmm0 > > > 400603: 0f 2e c1 ucomiss xmm0,xmm1 > > > 400606: 0f 9b c0 setnp al > > > 400609: 0f 45 c2 cmovne eax,edx > > > 40060c: c3 ret > > > 40060d: 0f 1f 00 nop DWORD PTR [rax] > > > > > > gem5 decodes the instruction as XORPS_XMM_M, instead of (something more > > > like) VXORPS_XMM_XMM_XMM. This leads to a segfault in the simulated > > program > > > when it attempts to access an unmapped address > > > > > > Here is the relevant section of the debug trace. > > > > > > 416293000: system.cpu: Fetch > > > 416293000: system.cpu: Translating address 0x4005f0 > > > 416293000: system.cpu: Sending fetch for addr 0x4005f0(pa: 0x5f0) > > > 416293000: system.cpu: -- pkt addr: 0x5f0 > > > 416348000: system.cpu.icache_port: Received fetch response 0x5f0 > > > 416348000: system.cpu: Complete ICache Fetch for addr 0x5f0 > > > 416348000: global: Getting more bytes. > > > 416348000: global: Setting origPC to 0x4005f0 > > > 416348000: global: Found VEX two-byte prefix 0xc5. > > > 416348000: global: Found VEX opcode 0x57. > > > 416348000: global: Found modrm byte 0x57. > > > 416348000: global: Collecting 1 byte displacement, got 1 bytes. > > > 416348000: global: Collected displacement 0xffffffffffffffc9. > > > 416348000: global: Calculating the instruction size: basePC: 0x4005f0 > > > offset: 0x4 origPC: 0x4005f0 size: 4 > > > 416348000: global: XORPS_XMM_M : ldfp: The address is > 0xffffffffffffffca > > > 416348000: system.cpu: Fault occured, scheduling fetch event > > > panic: Tried to read unmapped address 0xffffffffffffffca. > > > > > > > > > Toolchain information > > > ===================== > > > > > > samxi $ gcc --version > > > gcc (Ubuntu 5.4.0-6ubuntu1~16.04.5) 5.4.0 20160609 > > > > > > > > > samxi $ as --version > > > GNU assembler (GNU Binutils for Ubuntu) 2.26.1 > > > > > > gem5 revision: e79c4c6f033581f84072ddb45d2ec9543c31af55 > > > > > > Thanks, > > > Sam > > > > > > -- > > > Thanks, > > > > > > Sam Xi > > > Harvard University > > > Computer Science, Ph.D. Candidate > > > http://www.samxi.org > > > _______________________________________________ > > > gem5-dev mailing list > > > [email protected] > > > http://m5sim.org/mailman/listinfo/gem5-dev > > _______________________________________________ > > gem5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > -- > Thanks, > > Sam Xi > Harvard University > Computer Science, Ph.D. Candidate > http://www.samxi.org > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
