Στις Σάβ, 29 Δεκ 2018 στις 10:24 μ.μ., ο/η Richard Henderson <richard.hender...@linaro.org> έγραψε: > I did have a beginner in mind when guessing 4 months. Don't take that as a > fully speced out answer, but it may well be that full avx2 support cannot be > done within the 3 months of gsoc. I would certainly expect avx512 to take > even > longer.
Right, that's ok. Bit of context, the reason I'm interested in this feature (other than GSoC potential and general interest) is Orbital, a Sony PlayStation 4 emulator that implements a QEMU fork. Normally we use virtualization as anything else would be too slow, but TCG would help with debugging and such. The PS4's APU doesn't support AVX2 or AVX-512 so I'd be fine if I didn't have enough time to implement them. > The tcg-op-gvec.h infrastructure allows for the different modes that avx+mmx > allows: > > (1) 64-bit operations, > (2) 128-bit operations, modifying only the low 128 bits, > (3) 128-bit operations, zeroing bits beyond the first 128, > (4) N*128-bit operations, zeroing bits beyond the first N*128. I assume you mean 256-bit ops on (2) and (3), and N*256 on (4)? Low 128 bits of a 128-bit number is just the number. > so we should not need a great proliferation of helper functions, merely a > re-organization of what we have now. So, I would need to implement every SSE instruction that isn't SSE_SPECIAL at the moment, using tcg-op-gvec.h? Or more instructions than that? Assuming I do this for SSE and AVX, I would not need to touch anything else like the TCG back-end, as every gvec/vec op is already implemented for i386, correct? PS: I'm 'vel0city' on IRC, if that'd be more convenient.
