<div class="gmail_quote">On 13 January 2012 08:34, Norbert Nemec <span dir="ltr"><<a href="mailto:Norbert@nemec-online.de">Norbert@nemec-online.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 12.01.2012 23:10, Peter Alexander wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 12/01/12 8:13 PM, Norbert Nemec wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Considering these hardware details of the SSE architecture alone, I fear<br>
that portable low-level support for SIMD is very hard to achieve. If you<br>
want to offer access to the raw power of each architecture, it might be<br>
simpler to have machine-specific language extensions for SIMD and leave<br>
the portability for a wrapper library with a common front-end and<br>
various back-ends for the different architectures.<br>
</blockquote>
<br>
You are right, but don't forget that the same is true for instructions<br>
already in the language. For example, (1 << x) is a very slow operation<br>
on PPUs (it's micro-coded).<br>
<br>
It's simply not possible to be portable and achieve maximum performance<br>
for any language features, not just vectors. Algorithms must be tuned<br>
for specific architectures in version statements. However, you can get a<br>
decent baseline by providing the lowest common denominator in<br>
functionality. This v128 type (or whatever it will be called) does that.<br>
</blockquote>
<br></div></div>
Actually, my essential message is: The single v128 is too simplistic for the SSE architecture. You actually need different types because the compiler needs to know what type is stored in any given register to be able to move it around.<br>

</blockquote></div><br><div>This has already been concluded some days back, the language has a quite of types, just like GCC.</div>