News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Need help to address an error report

Started by Gunther, May 05, 2014, 01:47:01 AM

Previous topic - Next topic

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:
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
You have to know the facts before you can distort them.


Gunther

You have to know the facts before you can distort them.

Gunther

You have to know the facts before you can distort them.

sinsi

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.

Gunther

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
You have to know the facts before you can distort them.

Gunther

Sinsi,

another source:
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
You have to know the facts before you can distort them.

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,

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
You have to know the facts before you can distort them.

qWord

Quote from: Gunther on May 05, 2014, 06:46:41 PM
Sinsi,

another source:
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).
MREAL macros - when you need floating point arithmetic while assembling!

Gunther

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.

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
You have to know the facts before you can distort them.