3 ms·

Thats funny because C is a one-to-one mapping over assembly. And frankly its not using any esoteric instructions such as "PUNPCKHQDQ" or "VFNMADD231PS"

TheLoneWolfling 11y ago
What's wrong with "Unpack and interleave high-order quadwords from xmm1 and xmm2/m128 into xmm1." and "Multiply packed single-precision floating-point val-ues from ymm1 and ymm2/mem, negate the multi-plication result and add to ymm0 and put result in ymm0."? It's simple, right? (This is sarcasm, by the way.) Although I will point out that C has its esoterics also.
- vardump 11y ago
  Both "esoteric" examples were just picked from a larger set of data packing and FMA (fused multiply add) operations that high performance real life code needs and uses. Intel doesn't generally add instructions no one needs. Unfortunately, compilers aren't indeed very good at picking optimal instructions when it could take good advantage of instructions such as these. No wonder, though. Packing and unpacking are often needed in SIMD context. There are a lot of such instructions, including shuffles and permutes. Individually they may sound esoteric, but actually cover a nice number of real life data shuffling needs and are extremely fast. Fused-multiply-add instructions can double effective FLOPS.
  - TheLoneWolfling 11y ago
    I am well aware of the potential advantages of such operations. And the difficulties associated with trying to use them well and identify when they can be an advantage. However, just because something is useful does not preclude it from being esoteric. In particular, there are an astounding number of such miscellaneous and less-often-used instructions in x86 and extensions, and trying to remember which ones exist, and which ones have which limitations, is... a fair feat. Hence, esoteric. Understood only by a few with special knowledge or interest.
vezzy-fnord 11y ago
It used to, but it's nowhere near as correspondent with modern architectures that incorporate SIMD/SSE, complicated branching and pipelining strategies, SMT and so on. Nowadays C is a register machine model of its own, with plenty of gotchas and UB that are quite specific to it. The spec isn't terse for a reason.
- pmalynin 11y ago
  *With -O0
  - pcwalton 11y ago
    No, C does not expose a 1:1 mapping to assembly in any architecture, at -O0 or otherwise. To give one simple example, the C pointer types correspond to nothing meaningful in any commonly used ISA.
    - pmalynin 11y ago
      asm("xorl %eax, %eax"); And I'm not sure about your example, a C pointer type would be stored as a number that will be used with "lea" or "mov [pointer], foo". Elaborate.
not_with_retard 11y ago
It is absolutely _NOT_ a one-to-one mapping over assembly. You have no idea how many issues have arisen in ##c because assembly programmers seem to think this is true. Ask there for examples if you need elaboration, there are people much smarter than myself who will gladly show you the error in your ways.

TheLoneWolfling 11y ago

What's wrong with "Unpack and interleave high-order quadwords from xmm1 and xmm2/m128 into xmm1." and "Multiply packed single-precision floating-point val-ues from ymm1 and ymm2/mem, negate the multi-plication result and add to ymm0 and put result in ymm0."? It's simple, right? (This is sarcasm, by the way.) Although I will point out that C has its esoterics also.

vardump 11y ago
Both "esoteric" examples were just picked from a larger set of data packing and FMA (fused multiply add) operations that high performance real life code needs and uses. Intel doesn't generally add instructions no one needs. Unfortunately, compilers aren't indeed very good at picking optimal instructions when it could take good advantage of instructions such as these. No wonder, though. Packing and unpacking are often needed in SIMD context. There are a lot of such instructions, including shuffles and permutes. Individually they may sound esoteric, but actually cover a nice number of real life data shuffling needs and are extremely fast. Fused-multiply-add instructions can double effective FLOPS.
- TheLoneWolfling 11y ago
  I am well aware of the potential advantages of such operations. And the difficulties associated with trying to use them well and identify when they can be an advantage. However, just because something is useful does not preclude it from being esoteric. In particular, there are an astounding number of such miscellaneous and less-often-used instructions in x86 and extensions, and trying to remember which ones exist, and which ones have which limitations, is... a fair feat. Hence, esoteric. Understood only by a few with special knowledge or interest.

vezzy-fnord 11y ago

It used to, but it's nowhere near as correspondent with modern architectures that incorporate SIMD/SSE, complicated branching and pipelining strategies, SMT and so on. Nowadays C is a register machine model of its own, with plenty of gotchas and UB that are quite specific to it. The spec isn't terse for a reason.

pmalynin 11y ago
*With -O0
- pcwalton 11y ago
  No, C does not expose a 1:1 mapping to assembly in any architecture, at -O0 or otherwise. To give one simple example, the C pointer types correspond to nothing meaningful in any commonly used ISA.
  - pmalynin 11y ago
    asm("xorl %eax, %eax"); And I'm not sure about your example, a C pointer type would be stored as a number that will be used with "lea" or "mov [pointer], foo". Elaborate.

not_with_retard 11y ago

It is absolutely _NOT_ a one-to-one mapping over assembly. You have no idea how many issues have arisen in ##c because assembly programmers seem to think this is true. Ask there for examples if you need elaboration, there are people much smarter than myself who will gladly show you the error in your ways.