[Qemu-devel] 3 new x86 instructions

[Qemu-devel] 3 new x86 instructions

[Torbjorn Granlund]

There are 3 instructions, MULX, ADCX, and ADOX, which would be very
useful to see in qemu.  I looked into putting them in myself, but the
startup time for hacking qemu is longer than I can affort in this
period.

Apparently, MULX is implemented in Haswell, while ADCX and ADOX will
appear in Broadwell (or so says the rumours).

I need these instructions for hacking the GMP library (GNUs bignum
library).

Documentation for the instructions is available at
http://software.intel.com/file/45088.

Would some kind qemu hacker consider adding these instructions?

There is support in binutils 23.1 for these instructions, but I think it
is there already in version 22.x.

In the meantime, I'm using an inferior, comparatively slow emulator.
:-)

-- 
Torbjörn

Re: [Qemu-devel] 3 new x86 instructions

[Blue Swirl]

On Thu, Jan 10, 2013 at 1:46 PM, Torbjorn Granlund <tg@gmplib.org> wrote:
> There are 3 instructions, MULX, ADCX, and ADOX, which would be very
> useful to see in qemu.  I looked into putting them in myself, but the
> startup time for hacking qemu is longer than I can affort in this
> period.
>
> Apparently, MULX is implemented in Haswell, while ADCX and ADOX will
> appear in Broadwell (or so says the rumours).
>
> I need these instructions for hacking the GMP library (GNUs bignum
> library).
>
> Documentation for the instructions is available at
> http://software.intel.com/file/45088.
>
> Would some kind qemu hacker consider adding these instructions?

MULX implies a bunch of other instructions due to CPUID flag grouping.
ADCX and ADOX can be implemented separately. None of these and the
other instructions in the MULX group look very complex.

The other extensions like 256 bit float and extending existing SSE
instructions to use them would need much more work. FMA looks simple
except for the YMM variants. Random number instructions increase
demand of cryptographically secure random number supply from the host.

It would be nice if the implementer had access to the real HW which
implements the instructions for comparison tests.

> There is support in binutils 23.1 for these instructions, but I think it
> is there already in version 22.x.
>
> In the meantime, I'm using an inferior, comparatively slow emulator.
> :-)
>
> --
> Torbjörn
>

Re: [Qemu-devel] 3 new x86 instructions

[Torbjorn Granlund]

Blue Swirl <blauwirbel@gmail.com> writes:

  MULX implies a bunch of other instructions due to CPUID flag grouping.
  ADCX and ADOX can be implemented separately. None of these and the
  other instructions in the MULX group look very complex.
  
I had not realised that qemu disabled instructions when emulating a CPU
not supposed to support them.

  The other extensions like 256 bit float and extending existing SSE
  instructions to use them would need much more work. FMA looks simple
  except for the YMM variants. Random number instructions increase
  demand of cryptographically secure random number supply from the host.
  
I strongly doubt that cryptographically secure random numbers can in
general be supplied by qemu.  I would strongly suggest that these
instructions are not enabled by default, not to cause unintensional
abuse of them.  Some scary flag could enable them, perhaps
"--enable-supposedly-cryptographically-secure-random-number-instructions-in-an-unsafe-manner".
:-)

Of course, if the host claims to have such random instructions,
executing these and passing on the result makes some sense.

I don't think cryptographers trust these instructions anyway.  They
might very well be generated with a PRNG, and nobody could tell.

http://dilbert.com/strips/comic/2001-10-25/

There is no public silicon yet.  Haswell release is supposedly going to
happen on June 2.  Broadwell (with ADCX and ADOX) will not happen until
perhaps 2015.

-- 
Torbjörn

Re: [Qemu-devel] 3 new x86 instructions

[Richard Henderson]

On 01/12/2013 03:40 AM, Blue Swirl wrote:
> MULX implies a bunch of other instructions due to CPUID flag grouping.
> ADCX and ADOX can be implemented separately. None of these and the
> other instructions in the MULX group look very complex.

I've got a patch for (most of?) the bmi[12] insns:

   git://repo.or.cz/qemu/rth.git x86-next

This includes general support for the VEX prefixes.

But before I did anything else for the adx extension,
I thought I'd have a look back at Paolo's eflags optimization
patch series that he posted in October.  Otherwise we'll
not be able to get really good emulation of these insns.


r~

Re: [Qemu-devel] 3 new x86 instructions

[Torbjorn Granlund]

Richard Henderson <rth@twiddle.net> writes:

  > MULX implies a bunch of other instructions due to CPUID flag grouping.
  > ADCX and ADOX can be implemented separately. None of these and the
  > other instructions in the MULX group look very complex.
  
  I've got a patch for (most of?) the bmi[12] insns:
  
    git://repo.or.cz/qemu/rth.git x86-next
  
  This includes general support for the VEX prefixes.
  
Nice!

Is it in such a state that grabbing that repo and building a
qemu-system-x86_64 would give me MULX support?

I realise things might not be as stable as a release, but I can deal
with that.

  But before I did anything else for the adx extension,
  I thought I'd have a look back at Paolo's eflags optimization
  patch series that he posted in October.  Otherwise we'll
  not be able to get really good emulation of these insns.
  
I see.  ADCX and ADOX are several years away, IIUC.

-- 
Torbjörn

Re: [Qemu-devel] 3 new x86 instructions

[Richard Henderson]

On 01/14/2013 10:14 AM, Torbjorn Granlund wrote:
> Is it in such a state that grabbing that repo and building a
> qemu-system-x86_64 would give me MULX support?

Yes, and "-cpu Haswell" will enable the BMI extensions.

A review of the code and docs reveals that I missed RORX
from the BMI2 insns, but that's the only one I missed.

Note that I also incorrectly set the overflow flag in
several of the BMI insns.  It ought to be 0, and I currently
set it as if by a standard arithmetic insn.

I can also suggest using "qemu-x86_64" for userland linux
emulation, rather than full system emulation, for testing
something as well-behaved as gmp.  In partiular, the way
memory accesses are translated is significantly faster.

> I see.  ADCX and ADOX are several years away, IIUC.

Yes, in the Broadwell shrink.


r~

Re: [Qemu-devel] 3 new x86 instructions

[Torbjorn Granlund]

Richard Henderson <rth@twiddle.net> writes:

  On 01/14/2013 10:14 AM, Torbjorn Granlund wrote:
  > Is it in such a state that grabbing that repo and building a
  > qemu-system-x86_64 would give me MULX support?
  
  Yes, and "-cpu Haswell" will enable the BMI extensions.
  
  A review of the code and docs reveals that I missed RORX
  from the BMI2 insns, but that's the only one I missed.
  
  Note that I also incorrectly set the overflow flag in
  several of the BMI insns.  It ought to be 0, and I currently
  set it as if by a standard arithmetic insn.
  
  I can also suggest using "qemu-x86_64" for userland linux
  emulation, rather than full system emulation, for testing
  something as well-behaved as gmp.  In partiular, the way
  memory accesses are translated is significantly faster.
  
I compiled your version.  It does not work for me:

        tutu$ gcc -static^C/foo.s && qemu-x86_64 -cpu Haswell ./a.out

        tutu$ cat ~/foo.s
                .text
                .globl	main
                .type	main, @function
        main:	mulx	%rax, %r8, %r9
                ret

        tutu$ gcc ~/foo.s

        tutu$ qemu-x86_64 -cpu Haswell ./a.out
        qemu: uncaught target signal 4 (Illegal instruction) - core dumped
        Illegal instruction

If I remove the mulx, the example runs.

I copied your sources using this command:

  git clone git://repo.or.cz/qemu/rth.git qemu-x86-rth  

There seem to be no mention of MULX in the i386 subdirectory.

-- 
Torbjörn

Re: [Qemu-devel] 3 new x86 instructions

[Richard Henderson]

On 01/15/2013 09:14 AM, Torbjorn Granlund wrote:
> There seem to be no mention of MULX in the i386 subdirectory.

Then you got the wrong branch from the repository:

translate.c:4055:            case 0x3f6: /* mulx By, Gy, rdx, Ey */

You need the "x86-next" branch.


r~

Re: [Qemu-devel] 3 new x86 instructions

[Torbjorn Granlund]

Richard Henderson <rth@twiddle.net> writes:

  Then you got the wrong branch from the repository:
  
  translate.c:4055:            case 0x3f6: /* mulx By, Gy, rdx, Ey */
  
  You need the "x86-next" branch.
  
I am not a git user, and misundersand the command.

Now I have the correct version, and can confirm that at least mulx seems
to work as I expect from the docs.  Thanks!

I tried to build things on FreeBSD 9.1 and FreeBSD 8.3.  The build fails
is various ways.  The first few problems are related to usb, where
FreeBSD declares many constants (as enums) which have previously been
#defined in the qemu sources.  I started fixing these, but ended up
making larger and larger changes, without getting very far into the
compilation.

I now run this qemu on a GNU/Linux system instead.

-- 
Torbjörn