What are the dire consequences of accessing the fields of __m128i directly?

The MSDN documentation for __m128i says

You should not access the __m128i fields directly.

What are the dire consequences of accessing the fields directly?

The first consequence is portability: The contents of the __m128i structure are not standardized. It is a 16-byte value stored on a 16-byte boundary, but that's all that is required. If you go digging around inside it, you are tying yourself to a particular implementation's definition of __m128i.

The other consequence is performance: If a __m128i value is in an XMM register, and you try to access a field from it, the compiler will store the XMM register to memory, so that it can then extract the appropriate field. If you want to pull out specific fields, you are better-served using an intrinsic if an applicable one is available.

Comments (9)
  1. cheong00 says:

    And the third one is spelt on that documentation page: People running “your code using _m128i” on Pentium III will encounter silent failure (possibly because some possible compiled instruction of mov family will be the same as movdqa from the information provided? not checking how the compiled instruction of both kind of instruction looks really), so you had better not use it.

    1. Rutger Ellen says:

      Pentuim III is 10+ years old. While software usually survives decades hardware doesnt…

      1. cheong00 says:

        We still have “workstation class machine” that designated to be “server” still runs on PIII. :P

    2. ender9 says:

      Pretty much everything modern requires at least SSE2, so you’ll have other problems anyway.

    3. Yuhong Bao says:

      I believe what is technically happening is that many SSE2 instructions are MMX instructions with a prefix like 0xF3 or 0x66 that older processors silently ignore instead of treating it as an illegal opcode.

      1. Xirdus says:

        I used to own Athlon 2600+ that didn’t support SSE2. About 2008, more and more games started having problems on my computer, which I eventually tracked down to SIGILL on SSE2 opcodes. I had to do some weird hacks – replace PhysX DLLs for Borderlands, remove music files from Call of Duty…

  2. Martin says:

    Sorry for OT, but what was behind the decision not to support 80 bit long double by Microsoft compiler (MSVC)? MSVC supports long double data type, but treats them like double (= 64 bit variable). Is there any plan to support it in the future MSVS?

    1. Anon says:

      ” what was behind the decision not to support 80 bit long double by Microsoft compiler”

      It seems like support for them was lost in the move from 16 bits to 32 bits. They’re not portable to non x86 platforms perhaps?

      1. John Doe says:

        You may corerct. Microsoft cited the reason for compatibility in the past.

Comments are closed.

Skip to main content