On 6 January 2012 14:56, Martin Nowak <dawg@dawgfoto.de> wrote:

On Fri, 06 Jan 2012 09:43:30 +0100, Walter Bright <newshound2@digitalmars.com> wrote:
One caveat is it is typeless; a __v128 could be used as 4 packed ints or 2 packed doubles. One problem with making it typed is it'll add 10 more types to the base compiler, instead of one. Maybe we should just bite the bullet and do the types:

__vdouble2
__vfloat4
__vlong2
__vulong2
__vint4
__vuint4
__vshort8
__vushort8
__vbyte16
__vubyte16

Those could be typedefs, i.e. alias this wrapper.
Still simdop would not be typesafe.

I think they should by well defined structs with lots of type safety and sensible methods. Not just a typedef of the typeless primitive.

As much as this proposal presents a viable solution,
why not spending the time to extend inline asm.

I think there are too many risky problems with the inline assembler (as raised in my discussion about supporting pseudo registers in inline asm blocks).

* No way to allow the compiler to assign registers (pseudo registers)

* Assembly blocks present problems for the optimiser, it's not reliable that it can optimise around an inline asm blocks. How bad will it be when trying to optimise around 100 small inlined functions each containing its own inline asm blocks?

* D's inline assembly syntax has to be carefully translated to GCC's inline asm format when using GCC, and this needs to be done PER-ARCHITECTURE, which Iain should not be expected to do for all the obscure architectures GCC supports.

What would be needed?
- Implement the asm allocation logic.
- Functions containing asm statements should participate in inlining.
- Determining inline cost of asm statements.

I raised these points in my other thread, these are all far more complicated problems I think than exposing opcode intrinsics would be.

Opcode intrinsics are almost certainly the way to go.

When being used with typedefs for __vubyte16 et.al. this would
allow a really clean and simple library implementation of intrinsics.