<div class="gmail_quote">On 6 January 2012 14:56, Martin Nowak <span dir="ltr"><<a href="mailto:dawg@dawgfoto.de">dawg@dawgfoto.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On Fri, 06 Jan 2012 09:43:30 +0100, Walter Bright <<a href="mailto:newshound2@digitalmars.com" target="_blank">newshound2@digitalmars.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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:<br>
<br>
__vdouble2<br>
__vfloat4<br>
__vlong2<br>
__vulong2<br>
__vint4<br>
__vuint4<br>
__vshort8<br>
__vushort8<br>
__vbyte16<br>
__vubyte16<br>
</blockquote>
<br></div></div>
Those could be typedefs, i.e. alias this wrapper.<br>
Still simdop would not be typesafe.<br></blockquote><div><br></div><div>I think they should by well defined structs with lots of type safety and sensible methods. Not just a typedef of the typeless primitive.</div><div> </div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
As much as this proposal presents a viable solution,<br>
why not spending the time to extend inline asm.<br></blockquote><div><br></div><div>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).</div>
<div> * No way to allow the compiler to assign registers (pseudo registers)</div><div> * 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?</div>
<div> * 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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What would be needed?<br>
- Implement the asm allocation logic.<br>
- Functions containing asm statements should participate in inlining.<br>
- Determining inline cost of asm statements.<br></blockquote><div><br></div><div>I raised these points in my other thread, these are all far more complicated problems I think than exposing opcode intrinsics would be.</div>
<div>Opcode intrinsics are almost certainly the way to go.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">When being used with typedefs for __vubyte16 <a href="http://et.al" target="_blank">et.al</a>. this would<br>
allow a really clean and simple library implementation of intrinsics.<br>
</blockquote></div><br><div>The type safety you're imagining here might actually be annoying when working with the raw type and opcodes..</div><div>Consider this common situation and the code that will be built around it:</div>
<div>__v128 vec = { floatX, floatY, floatZ, unsigned int packedColour ); // pack some other useful data in W</div><div>If vec were strongly typed, I would now need to start casting all over the place to use various float and uint opcodes on this value?</div>
<div>I think it's correct when using SIMD at the raw level to express the type as it is, typeless... SIMD regs are infact typeless regs, they only gain concept of type the moment you perform an opcode on it, and only for the duration of that opcode.</div>
<div><br></div><div>You will get your strong type safety when you make use of the float4 types which will be created in the libs.</div>