I think there's an error inside Windows 7 (32-bit version). According to that source (http://www.drdobbs.com/parallel/windows-7-and-windows-server-2008-r2-ser/229300330), supports Windows 7, SP1 the AVX instruction set. But my instruction detection procedure, which you could find here (http://masm32.com/board/index.php?topic=1418.msg32846#msg32846), comes to another result. Here is the screen with Windows 7 (32-bit) as virtual machine under VirtualBox:
Quote
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:
Quote
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
curious, i did a little googling
these articles may interest you
https://software.intel.com/en-us/blogs/2011/04/14/is-avx-enabled/ (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://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 (http://msdn.microsoft.com/en-us/library/windows/hardware/ff545910%28v=vs.85%29.aspx)
Dave,
thank you for googling.
Quote from: dedndave on May 05, 2014, 02:01:06 AM
https://software.intel.com/en-us/blogs/2011/04/14/is-avx-enabled/ (https://software.intel.com/en-us/blogs/2011/04/14/is-avx-enabled/)
I know that source and my software considers it.
Quote from: dedndave on May 05, 2014, 02:01:06 AM
http://randomascii.wordpress.com/2013/03/11/should-this-windows-7-bug-be-fixed/ (http://randomascii.wordpress.com/2013/03/11/should-this-windows-7-bug-be-fixed/)
That's interesting. I'll try it.
Quote from: dedndave on May 05, 2014, 02:01:06 AM
http://msdn.microsoft.com/en-us/library/windows/hardware/ff545910%28v=vs.85%29.aspx (http://msdn.microsoft.com/en-us/library/windows/hardware/ff545910%28v=vs.85%29.aspx)
Seems only interesting for drivers.
Gunther
Hi Dave,
i did try that
Quote from: Gunther on May 05, 2014, 02:44:25 AM
Quote from: dedndave on May 05, 2014, 02:01:06 AM
http://randomascii.wordpress.com/2013/03/11/should-this-windows-7-bug-be-fixed/ (http://randomascii.wordpress.com/2013/03/11/should-this-windows-7-bug-be-fixed/)
but it didn't help.
Gunther
https://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions
QuoteThe 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.
Hi sinsi,
Quote from: sinsi on May 05, 2014, 07:02:16 AM
https://software.intel.com/en-us/articles/introduction-to-intel-advanced-vector-extensions
QuoteThe 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
Sinsi,
another source (http://en.wikipedia.org/wiki/VEX_prefix):
Quote
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
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
Hi Dave,
Quote from: dedndave on May 06, 2014, 04:47:49 AM
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
Quote from: Gunther on May 05, 2014, 06:46:41 PM
Sinsi,
another source (http://en.wikipedia.org/wiki/VEX_prefix):
Quote
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:
Quote from: Intel® 64 and IA-32 Architectures Software Developer's Manual, Feb 20142.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).
Hi qWord,
Quote from: qWord on May 13, 2014, 05:06:25 AM
For me it seems like that the OS wont support it ... .
yes, that's clear. You could also check that thread (http://masm32.com/board/index.php?topic=3191.0).
Quote from: qWord on May 13, 2014, 05:06:25 AM
... (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