Need help to address an error report

[Gunther]

I think there's an error inside Windows 7 (32-bit version). According to that source, supports Windows 7, SP1 the AVX instruction set. But my instruction detection procedure, which you could find here,  comes to another result. Here is the screen with Windows 7 (32-bit) as virtual machine under VirtualBox:

                Supported Features
                ==================

Vendor String: GenuineIntel
Brand  String: Intel(R)Core(TM)i7-3770CPU@3.40GHz

                Instruction Sets
                ----------------

MMX  SSE  SSE2  SSE3  SSSE3  SSE4.1  SSE4.2

                Supported Special Instructions
                ------------------------------

Conditional Moves
FXSAVE and FXSTOR
XSAVE and XSTOR for processor extended state management.
POPCNT
RDRAND
AES (Advanced Encryption Standard) Instruction Set
16-bit floating-point Conversion Instructions

Please, press enter to end the application ...

The AVX test failed. The same software brings on the same machine but under Windows 7 (64-bit) that output:

                Supported Features
                ==================

Vendor String: GenuineIntel
Brand  String: Intel(R)Core(TM)i7-3770CPU@3.40GHz

                Instruction Sets
                ----------------

MMX  SSE  SSE2  SSE3  SSSE3  SSE4.1  SSE4.2  AVX

                Supported Special Instructions
                ------------------------------

Conditional Moves
FXSAVE and FXSTOR
XSAVE and XSTOR for processor extended state management.
POPCNT
RDRAND
AES (Advanced Encryption Standard) Instruction Set
16-bit floating-point Conversion Instructions

Please, press enter to end the application ...

Under the 64-bit version, the AVX check had success. I'm not sure if the reason is the virtual machine. Could anyone test the software under a native Windows 7, SP1 (32-bit version) with an appropriate CPU (Sandy Bridge, Ivy Bridge, Haswell, Bulldozer, Steamroller)? That would be a great help. If the reason isn't the VM, the error must be inside the 32-bit version of Windows 7. In that case: Who is the right consignee?

Gunther

[dedndave]

curious, i did a little googling
these articles may interest you

https://software.intel.com/en-us/blogs/2011/04/14/is-avx-enabled/

http://randomascii.wordpress.com/2013/03/11/should-this-windows-7-bug-be-fixed/

http://msdn.microsoft.com/en-us/library/windows/hardware/ff545910%28v=vs.85%29.aspx

[Gunther]

Dave,

thank you for googling.

https://software.intel.com/en-us/blogs/2011/04/14/is-avx-enabled/

I know that source and my software considers it.

http://randomascii.wordpress.com/2013/03/11/should-this-windows-7-bug-be-fixed/

That's interesting. I'll try it.

http://msdn.microsoft.com/en-us/library/windows/hardware/ff545910%28v=vs.85%29.aspx

Seems only interesting for drivers.

Gunther

[Gunther]

Hi Dave,

i did try that

http://randomascii.wordpress.com/2013/03/11/should-this-windows-7-bug-be-fixed/

but it didn't help.

Gunther

[sinsi]

https://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions

The two new VEX prefixes are formed from two obsolete 32-bit instructions-Load Pointer Using DS (LDS-0xC4, 3-byte form) and Load Pointer Using ES (LES-0xC5, two-byte form)-which load the DS and ES segment registers in 32-bit mode. In 64-bit mode, opcodes LDS and LES generate an invalid-opcode exception, but under Intel® AVX, these opcodes are repurposed for encoding new instruction prefixes. As a result, the VEX instructions can only be used when running in 64-bit mode.

So 32-bit code can't use AVX instructions anyway, regardless of the OS, since they would be decoded as LDS/LES.

[Gunther]

Hi sinsi,

https://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions

The two new VEX prefixes are formed from two obsolete 32-bit instructions-Load Pointer Using DS (LDS-0xC4, 3-byte form) and Load Pointer Using ES (LES-0xC5, two-byte form)-which load the DS and ES segment registers in 32-bit mode. In 64-bit mode, opcodes LDS and LES generate an invalid-opcode exception, but under Intel® AVX, these opcodes are repurposed for encoding new instruction prefixes. As a result, the VEX instructions can only be used when running in 64-bit mode.

So 32-bit code can't use AVX instructions anyway, regardless of the OS, since they would be decoded as LDS/LES.

thank you. That seems to be the reason. But MS states other facts.

Gunther

[Gunther]

Sinsi,

another source:

In 32-bit mode VEX encoded instructions can only access the first 8 YMM/XMM registers; the encodings for the other registers would be interpreted as the legacy LDS and LES instructions that are not supported in 64-bit mode.

What's right, what's wrong?

Gunther

[dedndave]

i think i'd believe Intel before i'd believe wikipedia   :P

of course, Intel is careful not to assume responsibilty for whatever microsoft does - or documenting it

[Gunther]

Hi Dave,

i think i'd believe Intel before i'd believe wikipedia   :P

of course, Intel is careful not to assume responsibilty for whatever microsoft does - or documenting it

I'll Forward a question in a MS forum. I hope that helps.

Gunther

[qWord]

Sinsi,

another source:

In 32-bit mode VEX encoded instructions can only access the first 8 YMM/XMM registers; the encodings for the other registers would be interpreted as the legacy LDS and LES instructions that are not supported in 64-bit mode.

What's right, what's wrong?

Gunther

AFAICS the VEX prefixes (2- and 3 byte form) are also valid for 32 bit mode, with the restriction that only x/ymm0-7 can be used:

2.3.5.6 2-byte VEX Byte 1, bits[6:3] and 3-byte VEX Byte 2, bits [6:3]- 'vvvv' the Source or dest Register Specifier

In 32-bit mode the VEX first byte C4 and C5 alias onto the LES and LDS instructions. To maintain compatibility with
existing programs the VEX 2nd byte, bits [7:6] must be 11b. To achieve this, the VEX payload bits are selected to
place only inverted, 64-bit valid fields (extended register selectors) in these upper bits.
The 2-byte VEX Byte 1, bits [6:3] and the 3-byte VEX, Byte 2, bits [6:3] encode a field (shorthand VEX.vvvv) that
for instructions with 2 or more source registers and an XMM or YMM or memory destination encodes the first source
register specifier stored in inverted (1's complement) form.
VEX.vvvv is not used by the instructions with one source (except certain shifts, see below) or on instructions with
no XMM or YMM or memory destination. If an instruction does not use VEX.vvvv then it should be set to 1111b
otherwise instruction will #UD.
In 64-bit mode all 4 bits may be used. See Table 2-8 for the encoding of the XMM or YMM registers. In 32-bit and
16-bit modes bit 6 must be 1 (if bit 6 is not 1, the 2-byte VEX version will generate LDS instruction and the 3-byte
VEX version will ignore this bit).

For me it seems like that the OS wont support it (BTW, I'm curios why one should use a 32 bit OS on such powerful CPUs).

[Gunther]

Hi qWord,

For me it seems like that the OS wont support it ... .

yes, that's clear. You could also check that thread.

...  (BTW, I'm curios why one should use a 32 bit OS on such powerful CPUs).

In case you've legacy 32-bit software and a possibility would be CPU dispatching. Why not use the new registers? But, the entire thing fails, because the OS doesn't support that.

Gunther