> >On Sun, Aug 15, 2010 at 7:23 PM, Tyler Tricker <[email protected]> >wrote: >> Instead of SIMD built into the compiler, what would be the downsides >in >> having a generic assembly function( like C's asm but with a type >signature) >> and putting SIMD into a support library (a support library that could >be >> made to support things like OpenCL)? A support library could also have >a >> reference implementation for vanilla instruction sets. > >My personal opinion as a language user (rather than a language >implementor) is the "use our partially reliable research prototype >syntax, or else do absolutely everything yourself in assembly" is a >dichotomy that new languages often seem to end up presentingthe user >with, and it's precisely because I don't want either that I still >program in C++. It's a shame, because I'd really like to use a >language with more programmer support and higher level features. > >The example routine that I posted earlier in the thread shows the kind >of things that a programmer might want to do: it combines intrinsics >with "scalar" bit-shifting and looping that I'd both prefer not to >write in raw assembly and which don't seem to need it. >
Completelely agree here , a language that can do 80% of this SIMD in the language makes a strong argument for adoption especially for cross platform. Regarding the support lib what language would it be ? We want to write less assembly not more.. Learning all the SIMD instructions for a number of platforms and idiosyncrasies is not something devs should need to do. Ben _______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
