As I mentioned before, the instruction is not unimplemented.

Gabe

On Sat, Oct 28, 2017 at 8:20 AM, Sam Xi <[email protected]> wrote:

> I just tried out this change. It seems like it works in that the simulator
> now decodes the instruction correctly, but I would have expected to get an
> unimplemented instruction crash, and I don't. Does gem5 just skip the
> instruction in this case?
>
> On Fri, Oct 27, 2017 at 4:53 PM Gabe Black <[email protected]> wrote:
>
> > https://gem5-review.googlesource.com/c/public/gem5/+/5281
> >
> > On Fri, Oct 27, 2017 at 1:18 PM, Gabe Black <[email protected]>
> wrote:
> >
> > > 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
>
> --
> 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

Reply via email to