From glen.low at pixelglow.com Tue Mar 1 08:11:54 2005 From: glen.low at pixelglow.com (Glen Low) Date: Tue Mar 1 08:35:45 2005 Subject: [macstl-dev] Re: [AGG] Re: [Fwd: Multiplication?] In-Reply-To: <20050228163807.86081.qmail@web51510.mail.yahoo.com> References: <20050228163807.86081.qmail@web51510.mail.yahoo.com> Message-ID: <7221adaf38256ae6911a332718521f00@pixelglow.com> Maxim: On 01/03/2005, at 12:38 AM, Maxim Shemanarev wrote: >> vec ::operator* is currently undefined but planned. As >> Tony has said, this would require the PMULUDQ, but because PMULUDQ >> produces a 64-bit element result, I would have to shuffle, do two >> PMULUDQ's and then do an unpack (pack?). So if it's important to you >> guys, I will explore this in 0.2.2, or alternatively you could >> contribute code to that effect (hint: vec_mmx.h:2640). >> >> Altivec is similar, it requires several instructions to get the same >> effect. > > AFAICS Alitivec is much better for alpha-blend operations. In general > what we > need is 4x32 unsigned multiplications (16bit arguments and 32bit > result), in > Altivec it's vmulouh. In SSE2 there is no such instruction. The use of > PMULUDQ > doesn't make much sense because it allows to parallel only 2 color > components > (Red, Green), then you have to calculate Blue separately. Alpha is > calculated > differently. That's would be the perfect fit for both, 8- and > 16-bit-per-component colors (for 8bpc we could calculate up to 4 > pixels in > parallel). > > However, for 8-bit-per-component colors we can use MMX and PMULLW, 16 > bits is > enough here. But there's no instruction to multiply 4 16-bit values > and get 4 > 32-but ones, alas. I'm a little confused here, do you want a half multiply e.g. 32 bit x 32 bit = 32 bit OR 16 bit x 16 bit = 16 bit (based on your like of the PMULLW opcode, and my guess that you want to stuff the result back into a similarly sized pixel), or a full multiply 16 bit x 16 bit = 32 bit (based on your like of the vmulouh opcode)? The former is planned, but the latter isn't for macstl -- although I can certainly consider it, since the implementation has the flexibility for it. So, the missing types in macstl::vec<> is quite explainable. > > I honestly do not understand why they abandoned such useful operations > with > 4x32 bits. PMULLD and PMULHD would be perfect. > >> Indeed, you can use macstl's valarray >> implementation to do calculations on entire arrays transparently and >> efficiently -- you declare valarrays of the scalar element, but the >> implementation transparently upscales using the equivalent SIMD >> vectors >> if available. > > Sorry for possibly silly question. > Can I map a raw memory area that has logical structure R-G-B-A (one > byte per > component) to a valarray? Of course, the starting adress must be > aligned to 16 > bytes. > > The problem is we have an RGBA frame buffer in memory. Each row can be > aligned > to 16 bytes, and the width of the buffer can be aligned too. But the > problem is > we need to blend, say, 20 pixels starting from 10th. In this case we > blend two > first pixels as usual (to get the aligned start from 12th pixel) and > perform 4 > pixel parallel blend operation. Then we process the unaligned end. > > Is this trick possible with valarray? Some (Paul Baxter) have asked for similar things, I'm contemplating how best to get this functionality. For now, the easiest way to get what you want is to derive from the stdext::impl::array_term class, which lets you wrap any arbitrary piece of memory, although it needs vector type memory instead of scalar type because of aliasing and alignment issues. This transparently handles the use of scalar ops for the unaligned end. http://www.pixelglow.com/macstl/reference/ classstdext_1_1impl_1_1array__term.html valarray_base.h:355 valarray_vec.h:263 Your resulting type can then participate in expressions largely interchangeably with valarray and friends -- they are all built upon this foundation. I'm contemplating making this easier by implementing a refarray, which will allow you simply to pass in raw memory area as you suggest. For severely non-contiguous access, you can try deriving from stdext::impl::term instead, but then you have to supply your own iterator that steps through the memory in chunks. Cheers, Glen Low --- pixelglow software | simply brilliant stuff www.pixelglow.com From glen.low at pixelglow.com Wed Mar 2 09:14:04 2005 From: glen.low at pixelglow.com (Glen Low) Date: Wed Mar 2 09:45:40 2005 Subject: [macstl-dev] Re: [AGG] Re: [Fwd: Multiplication?] In-Reply-To: <20050301231941.65634.qmail@web51503.mail.yahoo.com> References: <20050301231941.65634.qmail@web51503.mail.yahoo.com> Message-ID: <3a66b439127f2a2ae69f1625fdbc9394@pixelglow.com> Maxim: On 02/03/2005, at 7:19 AM, Maxim Shemanarev wrote: > > It's a very common thing. I need to use 8 bit source values and > produce 8 bit > results. But for intermediate results there must be at least 16 bits. > AFAIU, U8x16 will truncate the result of the multiplication to 8 bits, > so, the > only correct way is to use U16x8, keeping the range of all input values > 0...255. An example is as follows: > r = (int8u)((((cr - r) * (int16u)alpha) + (r << 8)) >> 8); > g = (int8u)((((cg - g) * (int16u)alpha) + (g << 8)) >> 8); > b = (int8u)((((cb - b) * (int16u)alpha) + (b << 8)) >> 8); > > Here all values are unsigned bytes, but as soon as you perform > (cr-r)*alpha > there will be overflow (this is why "alpha" is converted int16u, to > make the > compiler use int16u for the whole expression). > > The same is for 16 bit input values and results (U32x4): > r = (int16u)((((cr - r) * (int32u)alpha) + (r << 16)) >> 16); > g = (int16u)((((cg - g) * (int32u)alpha) + (g << 16)) >> 16); > b = (int16u)((((cb - b) * (int32u)alpha) + (b << 16)) >> 16); > > The problem is SSE2 (unlike Altivec) doesn't have such commands, to > multiply > four 16*16=32 or just 32*32=32, there's only two 32*32=64, so, it will > need 2 > consecutive commands, which will definitely be slower. Hmm... given your specific expression above, it seems you really want the high byte (or word) of the multiplication as with the SSE PMULHUW opcode? Something like mulhi (cr - r, alpha) + r That could be arranged... On the other hand, C (unsigned) integer arithmetic rules work modulo n+1, where n is the largest unsigned integer for that type. So something like a * b where a and b are 8 bit integers may indeed overflow, but if you work "conservatively" with the result it doesn't matter e.g. mullo (a, b) + c == (a * b) mod 256 + c == (a * b + c) mod 256 which is the result you'd get anyway if you ignored the overflow of a * b in the first place. > The problem here is with dependencies. If I use valarray, I'll make > the very > basic things in my library (and as the result, the whole library) > dependent on > macstl. This will make the library useless on SGI, Sun, HP, IBM, etc. > In case > if I could map raw memory (preserving the alignment rules of course), > it's only > a single file, like agg_pixfmt_rgba_vec.h. So, if the application uses > this > file it depends on macstl, but the other parts of the library don't. > If you for > some reason can't use macstl (sacrificing the speed), you just don't > use the > parts dependent on it. There are a couple of ways of managing dependencies. You could do as you say, through a single file that brings in macstl for the people who want to use it. Alternatively, the macstl implementation of valarray is largely a simple superset of std::valarray, which of course is available on the C++ standard library. Thus a simple statement like this: #ifdef USE_MACSTL #include namespace std { using namespace stdext; } #else #include #endif is sufficient to switch between macstl's stdext::valarray and the hosted std::valarray. Of course from tests I see that std::valarray fares much poorer than hand-coded scalar loops on all tested compilers except gcc 3.3, where Gabriel Dos Reis's excellent ET implementation achieves close to hand-coded scalar loop performance. Also, I'd like to see macstl compile and work correctly on as many compilers as possible, so it would be good to see results on those compilers you mentioned -- can someone try compiling macstl on those other compilers. The main requirement is a close-to-standard C++98 compiler, e.g. VC 6.0 and 7.0 fare badly but 7.1 is OK. There might be licensing issues as well. macstl is RPL and I originally thought AGG was BSD, but the SF page lists you as CPL. We'd have to work something out, if you're the owner of AGG, that including macstl is OK but anyone who wants the optimizations of macstl should respect its RPL rules. I'll work on a refarray for 0.2.2. Cheers, Glen Low --- pixelglow software | simply brilliant stuff www.pixelglow.com From glen.low at pixelglow.com Thu Mar 3 07:16:09 2005 From: glen.low at pixelglow.com (Glen Low) Date: Thu Mar 3 07:36:50 2005 Subject: [macstl-dev] Re: [AGG] Re: [Fwd: Multiplication?] In-Reply-To: <20050302170612.24809.qmail@web51503.mail.yahoo.com> References: <20050302170612.24809.qmail@web51503.mail.yahoo.com> Message-ID: Maxim: On 03/03/2005, at 1:06 AM, Maxim Shemanarev wrote: >> Hmm... given your specific expression above, it seems you really want >> the high byte (or word) of the multiplication as with the SSE PMULHUW >> opcode? >> >> Something like >> >> mulhi (cr - r, alpha) + r >> >> That could be arranged... > > Absolutely! I'm not sure about losing accuracy, but I don't think it's > too > important in this case. > > What important is this operation is rather specific and I don't think > it makes > sense to support it on the high level. Although, it'd be nice to have > such an > operation. That is, > > macstl::vec v1 = . . .; > v1.mulhi(alpha); > > Here we multiply a vector of say, 8x16 bit values to a scalar value > and have > the elder 16 bits as the result. The mulhi operation makes sense to me since there are also variants of the same on Altivec and/or vecLib, so it's something that should be standardized. We just need to agree on a name :-) -- any comments from the others? Once the operation is implemented on the low-level vec interface, it's only another line away from being implemented in the high-level valarray, so it will be in both. > > BTW, does macstl::vec support arithmetic operations with scalars? Like > v1 >> 8? > v1 *= alpha, etc? It's very important too. vec doesn't support arithmetic with scalars directly because it's a close-to-the-metal solution. On Altivec especially, there are two ways to create a vector out of a scalar, depending on whether you have a compiler constant (which may invoke the faster constant generation routines) or a variable. So you'd have to do: v1 *= vec ::fill <8> (); // 8 is a compile-time constant v1 *= vec ::fill (alpha); // alpha is a variable If you use the high-level valarray, then yes, you can simply pass in a scalar which gets transparently splatted into the appropriate vector. Since valarrays are expected to run for longer, the overhead of not using a generated constant would be barely seen. >> Also, I'd like to see macstl compile and work correctly on as many >> compilers as possible, so it would be good to see results on those >> compilers you mentioned -- can someone try compiling macstl on those >> other compilers. The main requirement is a close-to-standard C++98 >> compiler, e.g. VC 6.0 and 7.0 fare badly but 7.1 is OK. > > But there won't be any SIMD optimizations, will there? If the processor targets did not have SIMD, then there won't be any optimizations. However my valarray uses expression templates for speed, so that even without SIMD optimization, their use is almost equivalent to a scalar hand-coded loop. And if you're familiar with template metaprogramming, you can use that (instead of coarse-grained and platform-specific macros like __VEC__ or __SSE__) to see if a particular vec class exists on that platform and call through to your appropriate code; vectest.cpp demonstrates this technique. I'm interested in code contributions for the other SIMD architectures of course, and am mildly (!) exploring using GPU's. >> There might be licensing issues as well. macstl is RPL and I >> originally >> thought AGG was BSD, but the SF page lists you as CPL. We'd have to >> work something out, if you're the owner of AGG, that including macstl >> is OK but anyone who wants the optimizations of macstl should respect >> its RPL rules. > > Exactly! This is a dependence too. The AGG license is very liberal, > yours is > more strict. It means that if AGG natively used macstl, the only legal > way to > use it is to obey the requirements of the most restrictive license, > that is, > macstl. And you don't have a choice in this case. If there are only a > couple of > files that depend on macstl, you do have a choice - you can remove > those files > and do without macstl (sacrificing the performance). It's how I handle > the Alan > Murta's General Polygon Clipper. I include it into AGG (the GPC > license allows > for that), but it's the user's responsibility whether to use GPC or > not. If > not, you just remove it and do without this functionality. OK. Sounds good to me. >> I'll work on a refarray for 0.2.2. > > BTW, do you consider submitting macstl to BOOST? http://www.boost.org > They have liberal license arrangements too, and require that the libraries be free. On the other hand, I need to eat :-). Cheers, Glen Low --- pixelglow software | simply brilliant stuff www.pixelglow.com From glen.low at pixelglow.com Wed Mar 9 07:38:35 2005 From: glen.low at pixelglow.com (Glen Low) Date: Wed Mar 9 07:46:10 2005 Subject: [macstl-dev] IIf function -- opinions wanted Message-ID: <2ee202b038eb9c1656e38e20df5e15d0@pixelglow.com> Hi all John Terrell wanted a "merge conditional" function akin to Altivec's vec_sel opcode (and the inbuilt C++ ternary logic operator ?:) to be in the vec common interface, and I think it's a reasonable request for 0.2.2. Any takers for the name? So e.g. iif (condition, true_clause, false_clause) 1. iif -- inspired by Visual Basic, somewhat terse though. 2. if_then -- seen this in Boost Lambda. However so far nothing in the common interface has an underscore, so far. 3. if_then_else -- more explicit what it does 4. sel or select -- show its similarity to vec_sel, however may be confusing as vec_sel (and thus altivec::sel) has a different order of parameters. 5. cond or condition -- doesn't read off as easily The main focus of the common interface is to introduce functions that do not require a thorough knowledge of the underlying SIMD architecture, so a name that rings familiar to the target audience would be best. Cheers, Glen Low --- pixelglow software | simply brilliant stuff www.pixelglow.com From hobold at informatik.uni-bremen.de Wed Mar 9 09:30:25 2005 From: hobold at informatik.uni-bremen.de (Holger Bettag) Date: Wed Mar 9 09:52:08 2005 Subject: [macstl-dev] IIf function -- opinions wanted In-Reply-To: <2ee202b038eb9c1656e38e20df5e15d0@pixelglow.com> References: <2ee202b038eb9c1656e38e20df5e15d0@pixelglow.com> Message-ID: On Wed, 9 Mar 2005, Glen Low wrote: > 1. iif -- inspired by Visual Basic, somewhat terse though. > 2. if_then -- seen this in Boost Lambda. However so far nothing in the > common interface has an underscore, so far. > 3. if_then_else -- more explicit what it does > 4. sel or select -- show its similarity to vec_sel, however may be > confusing as vec_sel (and thus altivec::sel) has a different order of > parameters. > 5. cond or condition -- doesn't read off as easily > AFAIK 'select' is the usual name for this type of operation. A 'conditional move' would be something else, and 'if then else' changes control flow rather than data flow. Holger From glen.low at pixelglow.com Sat Mar 12 16:11:35 2005 From: glen.low at pixelglow.com (Glen Low) Date: Sat Mar 12 16:32:35 2005 Subject: [macstl-dev] IIf function -- opinions wanted In-Reply-To: References: <2ee202b038eb9c1656e38e20df5e15d0@pixelglow.com> Message-ID: On 09/03/2005, at 9:30 AM, Holger Bettag wrote: > On Wed, 9 Mar 2005, Glen Low wrote: > >> 1. iif -- inspired by Visual Basic, somewhat terse though. >> 2. if_then -- seen this in Boost Lambda. However so far nothing in the >> common interface has an underscore, so far. >> 3. if_then_else -- more explicit what it does >> 4. sel or select -- show its similarity to vec_sel, however may be >> confusing as vec_sel (and thus altivec::sel) has a different order of >> parameters. >> 5. cond or condition -- doesn't read off as easily >> > AFAIK 'select' is the usual name for this type of operation. A > 'conditional move' would be something else, and 'if then else' changes > control flow rather than data flow. > Andrew has the same opinion as you. However, I'm worried about the ease of mistyping and argument order. If we follow the VB iif and C++ ternary operator standard and "natural" argument placement, then it is different from Altivec's vec_sel and it might be too easy for a programmer to mistype it. select (if_part, then_part, else_part); // this would be in the common interface sel (else_part, then_part, if_part); // this would be in the Altivec platform interface, corresponding to vec_sel As I see it, there are two solutions: 1. Give the common interface function some other name, or at least not a proper superset of sel. 2. Let the common interface function have the same argument order as Altivec sel. I'm rather partial to iif, although that and any variant that includes "if" in it may carry the false sense that a control flow is meant (as you said) i.e. that if_part is a boolean and either then_part or else_part is entirely selected and/or the other is not evaluated [control flow], rather than selecting elements of then_part and elements of else_part according to the elements of if_part [data flow]. Then again, && and || now operate on valarray and vec with data flow, even though the original meanings in C++ were control flow. I haven't been able to google out any other direct equivalents in other languages. It seems all the C descendants went for "if_part ? then_part : else_part", and all the Basic descendants and variants went for "iif (if_part, then_part, else_part)". Python seems to have an even stranger "if_part and then_part or else_part". Don't see any other "conditional select" data flow variants except Altivec's vec_sel. The minor danger with iif is that Microsoft will go and patent it, just like they did with AndNot :-) Further opinions, especially from the non-Altivec users here? Cheers, Glen Low --- pixelglow software | simply brilliant stuff www.pixelglow.com From bob at redivi.com Sun Mar 13 07:25:22 2005 From: bob at redivi.com (Bob Ippolito) Date: Sun Mar 13 07:32:55 2005 Subject: [macstl-dev] IIf function -- opinions wanted In-Reply-To: References: <2ee202b038eb9c1656e38e20df5e15d0@pixelglow.com> Message-ID: <6e9b1aa52495a30f7fea31e0a29c3c15@redivi.com> On Mar 12, 2005, at 3:11, Glen Low wrote: > I'm rather partial to iif, although that and any variant that includes > "if" in it may carry the false sense that a control flow is meant (as > you said) i.e. that if_part is a boolean and either then_part or > else_part is entirely selected and/or the other is not evaluated > [control flow], rather than selecting elements of then_part and > elements of else_part according to the elements of if_part [data > flow]. Then again, && and || now operate on valarray and vec with data > flow, even though the original meanings in C++ were control flow. > > I haven't been able to google out any other direct equivalents in > other languages. It seems all the C descendants went for "if_part ? > then_part : else_part", and all the Basic descendants and variants > went for "iif (if_part, then_part, else_part)". Python seems to have > an even stranger "if_part and then_part or else_part". Don't see any > other "conditional select" data flow variants except Altivec's > vec_sel. Python's "if foo and bar or baz" is not on purpose, and isn't identical to the equivalent in any other language because If bar is a false value, then baz will be chosen regardless of foo. An actual Python equivalent would be "if (foo and [bar] or [baz])[0]", but really, in Python you are just supposed to write it out. -bob From leblanc at skycomputers.com Thu Mar 24 04:56:20 2005 From: leblanc at skycomputers.com (Michael LeBlanc) Date: Thu Mar 24 05:28:22 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: References: Message-ID: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> Folks, I am extremely new to macstl. I get zillions of compile-time errors building a simple test. Am I expecting too much? <---------- make your window this wide ---------------------------------------------------------------> One sort from impl/vec_altivec.h complains that the 2nd redefines the 1st: template <> struct data_vec <__vector signed char> { typedef vec type; }; template <> struct data_vec <__vector bool char> { typedef vec , 16> type; }; Another concerns these lines in the same header: template struct generator { __vector unsigned int operator() () const The error message is: /home/leblanc/MACSTL/macstl/macstl/impl/vec_altivec.h:59: sorry, unimplemented: ` integer_cst' not supported by dump_type That's all for now. Thanks. Mike LeBlanc From glen.low at pixelglow.com Thu Mar 24 07:56:20 2005 From: glen.low at pixelglow.com (Glen Low) Date: Thu Mar 24 08:06:23 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> Message-ID: <2568046963269f11e136f9857f2de9e6@pixelglow.com> On 24/03/2005, at 4:56 AM, Michael LeBlanc wrote: > Folks, I am extremely new to macstl. I get zillions of compile-time > errors building a simple test. Am I expecting too much? Not at all. I don't have a Linux box handy but would love to get macstl to work with Linux, if you're willing to be the guinea pig. :-) > > <---------- make your window this wide > ---------------------------------------------------------------> > > One sort from impl/vec_altivec.h complains that the 2nd redefines the > 1st: > > template <> struct data_vec <__vector signed char> { typedef vec > type; }; > template <> struct data_vec <__vector bool char> { typedef vec > , 16> type; }; Hmmm... are you targeting PowerPC/Altivec on Linux (I'm assuming from your use of YellowDog and __vector)? gcc on that platform may require using the -maltivec switch instead of Apple's -faltivec switch, and #including . The first lot of errors looks to me that mainline gcc isn't defining the vector types as distinct C types, you might need to check altivec.h for this, or try compiling this simple test: __vector signed char x; __vector bool char y = x; The above won't compile on Apple gcc since they are distinct types, but perhaps not on mainline gcc? I recall seeing some discussion in gcc.gnu.org about making the bool types equivalent to the signed types. It is generally OK to comment out a couple of data_vec declarations since they are to guide the compiler in doing conversions between the native vector types and the object-oriented vec types -- if the type system isn't strong e.g. with MMX, there's not much that can be done. > Another concerns these lines in the same header: > > template int v3> struct generator > { > __vector unsigned int operator() () const > > The error message is: > > /home/leblanc/MACSTL/macstl/macstl/impl/vec_altivec.h:59: sorry, > unimplemented: ` > integer_cst' not supported by dump_type There are two ways of initializing native vector types, one way looks like C99 array initialization so I call the macro that controls it "USE_C99_VEC_INIT_IN_TEMPL"; the other way looks like C++ initialization and comes from Motorola, so I call that "USE_MOT_VEC_INIT_IN_TEMPL". Quite possibly the library is choosing the wrong syntax for your compiler. (I think mainline gcc is USE_C99_VEC_INIT_IN_TEMPL, which is #defined in impl/config.h) Additionally USE_MOT_VEC_INIT_IN_TEMPL requires that the compiler realize its parameters are constant, and most Motorola-respecting compilers don't for template non-type parameters. *sigh* So it's OK for both to be undefined, and the library will use a conservative load from a static constant. > That's all for now. Thanks. Hope that's enough to get you started. When you get it work successfully, I'd appreciate a diff for the changes (although you'll have to acknowledge a CLA). Cheers, Glen Low --- pixelglow software | simply brilliant stuff www.pixelglow.com aim: pixglen From leblanc at skycomputers.com Thu Mar 24 21:03:55 2005 From: leblanc at skycomputers.com (Michael LeBlanc) Date: Thu Mar 24 21:16:02 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: <2568046963269f11e136f9857f2de9e6@pixelglow.com> References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> <2568046963269f11e136f9857f2de9e6@pixelglow.com> Message-ID: <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> On Mar 23, 2005, at 6:56 PM, Glen Low wrote: > On 24/03/2005, at 4:56 AM, Michael LeBlanc wrote: > >> Folks, I am extremely new to macstl. I get zillions of compile-time >> errors building a simple test. Am I expecting too much? > > Not at all. I don't have a Linux box handy but would love to get > macstl to work with Linux, if you're willing to be the guinea pig. :-) I volunteer. Although our hardware is not Mac, it's PPC G4 running YDL 3.0. The OS comes with GCC 3.2.2. We build 3.3 configured with --enable-altivec. > The first lot of errors looks to me that mainline gcc isn't defining > the vector types as distinct C types, you might need to check > altivec.h for this, or try compiling this simple test: > > __vector signed char x; > __vector bool char y = x; It compiles OK. And, yes, I have to prepend #include which contains #define bool signed #define pixel unsigned short #define __pixel unsigned short >> Another concerns these lines in the same header: >> >> template > int v3> struct generator >> { >> __vector unsigned int operator() () const >> >> The error message is: >> >> /home/leblanc/MACSTL/macstl/macstl/impl/vec_altivec.h:59: sorry, >> unimplemented: ` >> integer_cst' not supported by dump_type > > There are two ways of initializing native vector types, one way looks > like C99 array initialization so I call the macro that controls it > "USE_C99_VEC_INIT_IN_TEMPL"; the other way looks like C++ > initialization and comes from Motorola, so I call that > "USE_MOT_VEC_INIT_IN_TEMPL". The first was being #define-d. Now they are both #undef-d, but I still get the same error. From leblanc at skycomputers.com Thu Mar 24 23:12:00 2005 From: leblanc at skycomputers.com (Michael LeBlanc) Date: Thu Mar 24 23:22:11 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> <2568046963269f11e136f9857f2de9e6@pixelglow.com> <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> Message-ID: <8dc3ef43ddb422c1c1083999bd54eaba@skycomputers.com> I tried to cut the problem down to size. It looks like __vector is being dropped from the return type of operator(). When using an explicit type, it draws the weird error. $ cat -n y.cpp 1 #include 2 3 template struct generator 4 { 5 #ifdef USE_TYPEDEF 6 typedef __vector unsigned int T; 7 T 8 #else 9 __vector unsigned int 10 #endif 11 operator() () const 12 { 13 union union_type 14 { 15 unsigned int val [4]; 16 __vector unsigned int vec; 17 }; 18 static const union_type un = {v0, v0, v0, v0}; 19 return un.vec; 20 } 21 }; 22 23 __vector unsigned char zz = 24 static_cast <__vector unsigned char> 25 (generator <0> () ()) 26 ; 27 $ gcc -c y.cpp y.cpp:12: sorry, unimplemented: `integer_cst' not supported by dump_type y.cpp:25: error: non-template type `generator' used as a template $ gcc -c y.cpp -DUSE_TYPEDEF y.cpp:25: error: invalid static_cast from type `unsigned int' to type `vector unsigned char' y.cpp: In member function `unsigned int generator::operator()() const [with unsigned int v0 = 0]': y.cpp:25: instantiated from here y.cpp:19: error: cannot convert `vector unsigned int' to `unsigned int' in return From glen.low at pixelglow.com Thu Mar 24 23:41:03 2005 From: glen.low at pixelglow.com (Glen Low) Date: Thu Mar 24 23:53:46 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> <2568046963269f11e136f9857f2de9e6@pixelglow.com> <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> Message-ID: <47d01f24c35be91ae0238b98d0630665@pixelglow.com> On 24/03/2005, at 9:03 PM, Michael LeBlanc wrote: > > On Mar 23, 2005, at 6:56 PM, Glen Low wrote: > >> On 24/03/2005, at 4:56 AM, Michael LeBlanc wrote: >> >>> Folks, I am extremely new to macstl. I get zillions of compile-time >>> errors building a simple test. Am I expecting too much? >> >> Not at all. I don't have a Linux box handy but would love to get >> macstl to work with Linux, if you're willing to be the guinea pig. >> :-) > > I volunteer. Although our hardware is not Mac, it's PPC G4 running > YDL 3.0. The OS comes with GCC 3.2.2. We build 3.3 configured with > --enable-altivec. Great! macstl should be a good fit for you guys, because it's trig and transcendental function implementation is independent of Apple's vecLib. > >> The first lot of errors looks to me that mainline gcc isn't defining >> the vector types as distinct C types, you might need to check >> altivec.h for this, or try compiling this simple test: >> >> __vector signed char x; >> __vector bool char y = x; > > It compiles OK. And, yes, I have to prepend #include > which contains > > #define bool signed > #define pixel unsigned short > #define __pixel unsigned short At the very least the first #define is problematic for pure C++ code since bool is a reserved word. Is that particular #define fenced in any way? I suggest adding a #ifdef test for mainline gcc and non-Apple code in config.h, then #define'ing several conditions that can be used in the actual code e.g. the way I did #define USE_MOT_VEC_INIT_IN_TEMPL. You can then fence the appropriate definitions of data_vec with the condition. > >>> Another concerns these lines in the same header: >>> >>> template >> unsigned int v3> struct generator >>> { >>> __vector unsigned int operator() () const >>> >>> The error message is: >>> >>> /home/leblanc/MACSTL/macstl/macstl/impl/vec_altivec.h:59: sorry, >>> unimplemented: ` >>> integer_cst' not supported by dump_type >> >> There are two ways of initializing native vector types, one way looks >> like C99 array initialization so I call the macro that controls it >> "USE_C99_VEC_INIT_IN_TEMPL"; the other way looks like C++ >> initialization and comes from Motorola, so I call that >> "USE_MOT_VEC_INIT_IN_TEMPL". > > The first was being #define-d. Now they are both #undef-d, but I > still get the same error. Hmmm, where exactly is the error occurring? A few things you could try: in the struct generator, do a typedef of __vector unsigned int, and let the operator() have that as the return type. Some of the compilers have difficulty parsing the __vector constructs especially with complicated C++ expressions, Apple's done a stellar job with Apple gcc but obviously not all the patches have been returned to mainline. Try changing it to just int to see if the compiler will get past that line. Cheers, Glen Low --- pixelglow software | simply brilliant stuff www.pixelglow.com aim: pixglen From glen.low at pixelglow.com Fri Mar 25 08:47:46 2005 From: glen.low at pixelglow.com (Glen Low) Date: Fri Mar 25 08:52:56 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: <8dc3ef43ddb422c1c1083999bd54eaba@skycomputers.com> References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> <2568046963269f11e136f9857f2de9e6@pixelglow.com> <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> <8dc3ef43ddb422c1c1083999bd54eaba@skycomputers.com> Message-ID: On 24/03/2005, at 11:12 PM, Michael LeBlanc wrote: > I tried to cut the problem down to size. It looks like __vector is > being dropped from the return type of operator(). When using an > explicit type, it draws the weird error. > > $ cat -n y.cpp > 1 #include > 2 > 3 template struct generator > 4 { > 5 #ifdef USE_TYPEDEF > 6 typedef __vector unsigned int T; > 7 T > 8 #else > 9 __vector unsigned int > 10 #endif > 11 operator() () const > 12 { > 13 union union_type > 14 { > 15 unsigned int val [4]; > 16 __vector unsigned int vec; > 17 }; > 18 static const union_type un = {v0, v0, v0, v0}; > 19 return un.vec; > 20 } > 21 }; > 22 > 23 __vector unsigned char zz = > 24 static_cast <__vector unsigned char> > 25 (generator <0> () ()) > 26 ; > 27 > > $ gcc -c y.cpp > y.cpp:12: sorry, unimplemented: `integer_cst' not supported by > dump_type > y.cpp:25: error: non-template type `generator' used as a template > > $ gcc -c y.cpp -DUSE_TYPEDEF > y.cpp:25: error: invalid static_cast from type `unsigned int' to type > `vector > unsigned char' > y.cpp: In member function `unsigned int generator::operator()() > const [with > unsigned int v0 = 0]': > y.cpp:25: instantiated from here > y.cpp:19: error: cannot convert `vector unsigned int' to `unsigned > int' in > return Totally weird is right. Looks like the mainline gcc Altivec parser is seriously, um, buggered. Try declaring the typedefs outside of a class. I sometimes find gcc is a little silly about its C extensions scoped within a C++ class (e.g. I tried the no_alias attribute but it caused ICE's and other unpleasantness if used in a typedef scoped within a C++ class). Try within a namespace (stdext::impl) first, and if that fails, declare them at global scope. If that fails, I'd suggest doing some typedefs with the gcc inbuilt vector types e.g. typedef int v4si __attribute__ ((mode(V4SI))); and see if that will work. We can fence the declarations appropriately for Apple gcc and mainline gcc if it comes to that. Cheers, Glen Low --- pixelglow software | simply brilliant stuff www.pixelglow.com aim: pixglen From leblanc at skycomputers.com Fri Mar 25 20:51:45 2005 From: leblanc at skycomputers.com (Michael LeBlanc) Date: Fri Mar 25 21:00:02 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> <2568046963269f11e136f9857f2de9e6@pixelglow.com> <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> <8dc3ef43ddb422c1c1083999bd54eaba@skycomputers.com> Message-ID: <0b3689304755ba34813d0f7bc4c84243@skycomputers.com> On Mar 24, 2005, at 7:47 PM, Glen Low wrote: > Try declaring the typedefs outside of a class. I sometimes find gcc is > a little silly about its C extensions scoped within a C++ class (e.g. > I tried the no_alias attribute but it caused ICE's and other > unpleasantness if used in a typedef scoped within a C++ class). Try > within a namespace (stdext::impl) first, and if that fails, declare > them at global scope. Silly is right! I'll try inside namespaces shortly. About the cast, is the intent just to change type? You don't want any code generated, do you? ~/valarray]$ cat -n y.cpp 1 #include 2 3 #ifdef USE_TYPEDEF 4 typedef __vector unsigned int VUT; 5 #endif 6 7 template struct generator 8 { 9 #ifdef USE_TYPEDEF 10 VUT 11 #else 12 __vector unsigned int 13 #endif 14 operator() () const 15 { 16 union union_type 17 { 18 unsigned int val [4]; 19 __vector unsigned int vec; 20 }; 21 static const union_type un = {v0, v0, v0, v0}; 22 return un.vec; 23 } 24 }; 25 26 __vector unsigned char zz = 27 static_cast <__vector unsigned char> 28 (generator <0> () ()) 29 ; 30 $ gcc -c y.cpp -DUSE_TYPEDEF y.cpp:28: error: invalid static_cast from type `vector unsigned int' to type ` vector unsigned char' From leblanc at skycomputers.com Fri Mar 25 21:42:59 2005 From: leblanc at skycomputers.com (Michael LeBlanc) Date: Fri Mar 25 22:03:14 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: <0b3689304755ba34813d0f7bc4c84243@skycomputers.com> References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> <2568046963269f11e136f9857f2de9e6@pixelglow.com> <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> <8dc3ef43ddb422c1c1083999bd54eaba@skycomputers.com> <0b3689304755ba34813d0f7bc4c84243@skycomputers.com> Message-ID: > About the cast, is the intent just to change type? You don't want any > code generated, do you? A simple cast compiles. Here's the generated code code: lis 11,_ZZNK9generatorILj0EEclEvE2un@ha la 11,_ZZNK9generatorILj0EEclEvE2un@l(11) lis 9,zz@ha la 9,zz@l(9) lvx 0,0,11 stvx 0,0,9 which is as simple as you can get. More silliness. On line 29 below, replace "VUC" by "(VUC)", a C-style cast, and it draws a parse error. 1 #include 2 3 #ifdef USE_TYPEDEF 4 typedef __vector unsigned int VUT; 5 typedef __vector unsigned char VUC; 6 #endif 7 8 template struct generator 9 { 10 #ifdef USE_TYPEDEF 11 VUT 12 #else 13 __vector unsigned int 14 #endif 15 operator() () const 16 { 17 union union_type 18 { 19 unsigned int val [4]; 20 __vector unsigned int vec; 21 }; 22 static const union_type un = {v0, v0, v0, v0}; 23 return un.vec; 24 } 25 }; 26 27 __vector unsigned char zz = 28 // static_cast 29 VUC 30 (generator <0> () ()) 31 ; From glen.low at pixelglow.com Fri Mar 25 22:33:05 2005 From: glen.low at pixelglow.com (Glen Low) Date: Fri Mar 25 22:34:47 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> <2568046963269f11e136f9857f2de9e6@pixelglow.com> <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> <8dc3ef43ddb422c1c1083999bd54eaba@skycomputers.com> <0b3689304755ba34813d0f7bc4c84243@skycomputers.com> Message-ID: <9f00c1eaf9d1d54ea2a199680799d800@pixelglow.com> On 25/03/2005, at 9:42 PM, Michael LeBlanc wrote: >> About the cast, is the intent just to change type? You don't want >> any code generated, do you? > > A simple cast compiles. Here's the generated code code: > > lis 11,_ZZNK9generatorILj0EEclEvE2un@ha > la 11,_ZZNK9generatorILj0EEclEvE2un@l(11) > lis 9,zz@ha > la 9,zz@l(9) > lvx 0,0,11 > stvx 0,0,9 > > which is as simple as you can get. Now we're getting somewhere, at least we know mainline gcc borks when typedef'ing a __vector type within a C++ scope (class scope). Need to test whether this is OK for a namespace that surrounds the struct generator, since I'd rather the typedef be hidden in stdext::impl. As for the cast, it's just changing type. All constant generation is bottlenecked at compile time through the generator class, so there's opportunity to substitute generation sequences via explicit specialization that avoids the slow L2 cache loads. At the generator level it really doesn't matter whether it's a char, short, int or float, we just want the bit pattern. > More silliness. On line 29 below, replace "VUC" by "(VUC)", a C-style > cast, and it draws a parse error. > > 1 #include > 2 > 3 #ifdef USE_TYPEDEF > 4 typedef __vector unsigned int VUT; > 5 typedef __vector unsigned char VUC; > 6 #endif > 7 > 8 template struct generator > 9 { > 10 #ifdef USE_TYPEDEF > 11 VUT > 12 #else > 13 __vector unsigned int > 14 #endif > 15 operator() () const > 16 { > 17 union union_type > 18 { > 19 unsigned int val [4]; > 20 __vector unsigned int vec; > 21 }; > 22 static const union_type un = {v0, v0, v0, v0}; > 23 return un.vec; > 24 } > 25 }; > 26 > 27 __vector unsigned char zz = > 28 // static_cast > 29 VUC > 30 (generator <0> () ()) > 31 ; Perhaps, but just plain VUC is a syntax error since it's not a cast. You need to cast with (VUC). I've seen a gcc version 4.0 that doesn't like static_cast to a __vector type, and prefers the C-style cast as you've said. If (VUC) doesn't work, then you have to use (__vector unsigned char) after all. After all this messiness, take heart. The evil that lies in the heart of SIMD compilers was meant to be well hidden in vec_altivec.h and vec_mmx.h. If we do our job well, the library clients need never see or touch this stuff themselves. Cheers, Glen Low --- pixelglow software | simply brilliant stuff www.pixelglow.com aim: pixglen From leblanc at skycomputers.com Fri Mar 25 23:28:15 2005 From: leblanc at skycomputers.com (Michael LeBlanc) Date: Fri Mar 25 23:37:54 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: <9f00c1eaf9d1d54ea2a199680799d800@pixelglow.com> References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> <2568046963269f11e136f9857f2de9e6@pixelglow.com> <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> <8dc3ef43ddb422c1c1083999bd54eaba@skycomputers.com> <0b3689304755ba34813d0f7bc4c84243@skycomputers.com> <9f00c1eaf9d1d54ea2a199680799d800@pixelglow.com> Message-ID: > Now we're getting somewhere, at least we know mainline gcc borks when > typedef'ing a __vector type within a C++ scope (class scope). Need to > test whether this is OK for a namespace that surrounds the struct > generator, since I'd rather the typedef be hidden in stdext::impl. This works. 1 #include 2 3 namespace mike 4 { 5 typedef __vector unsigned int VUT; 6 typedef __vector unsigned char VUC; 7 8 template struct generator 9 { 10 VUT 11 operator() () const 12 { 13 union union_type 14 { 15 unsigned int val [4]; 16 __vector unsigned int vec; 17 }; 18 static const union_type un = {v0, v0, v0, v0}; 19 return un.vec; 20 } 21 }; 22 } 23 24 __vector unsigned char zz = 25 mike::VUC 26 (mike::generator <0> () ()) 27 ; But *sigh* see line 25. If I wrap () around the type, I get gcc -c y2.cpp y2.cpp:27: error: parse error before `;' token > Perhaps, but just plain VUC is a syntax error since it's not a cast. > You need to cast with (VUC). You and I know that, but gcc is doing something like a cast. Or a constructor? From leblanc at skycomputers.com Sat Mar 26 00:09:40 2005 From: leblanc at skycomputers.com (Michael LeBlanc) Date: Sat Mar 26 00:41:23 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> <2568046963269f11e136f9857f2de9e6@pixelglow.com> <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> <8dc3ef43ddb422c1c1083999bd54eaba@skycomputers.com> <0b3689304755ba34813d0f7bc4c84243@skycomputers.com> <9f00c1eaf9d1d54ea2a199680799d800@pixelglow.com> Message-ID: Here's a version that hides the casting inside generator. I added a template parameter R, the desired return type. See line 15 where, now, the legal cast form works. static_cast still won't work. This would ding every use of generator. Do you create generator.h from a higher level form? I'm an AWK junkie. 1 #include 2 3 template 4 struct generator 5 { 6 R 7 operator() () const 8 { 9 union union_type 10 { 11 unsigned int val [4]; 12 __vector unsigned int vec; 13 }; 14 static const union_type un = {v0, v0, v0, v0}; 15 return (R) (un.vec); 16 } 17 }; 18 19 __vector unsigned char zz = 20 generator <0,__vector unsigned char> () () 21 ; From glen.low at pixelglow.com Mon Mar 28 02:07:03 2005 From: glen.low at pixelglow.com (Glen Low) Date: Mon Mar 28 02:28:55 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> <2568046963269f11e136f9857f2de9e6@pixelglow.com> <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> <8dc3ef43ddb422c1c1083999bd54eaba@skycomputers.com> <0b3689304755ba34813d0f7bc4c84243@skycomputers.com> <9f00c1eaf9d1d54ea2a199680799d800@pixelglow.com> Message-ID: On 26/03/2005, at 12:09 AM, Michael LeBlanc wrote: > Here's a version that hides the casting inside generator. I added a > template parameter R, the desired return type. See line 15 where, > now, the legal cast form works. static_cast still won't work. > > This would ding every use of generator. Do you create generator.h > from a higher level form? I'm an AWK junkie. > > 1 #include > 2 > 3 template > 4 struct generator > 5 { > 6 R > 7 operator() () const > 8 { > 9 union union_type > 10 { > 11 unsigned int val [4]; > 12 __vector unsigned int vec; > 13 }; > 14 static const union_type un = {v0, v0, v0, v0}; > 15 return (R) (un.vec); > 16 } > 17 }; > 18 > 19 __vector unsigned char zz = > 20 generator <0,__vector unsigned char> () () > 21 ; > That looks good, however it would make all the explicit specializations of generator into partial specializations, which may in turn slow the compiler down. Is it at all possible to compile __vector unsigned char zz = (__vector unsigned char) generator <0> () (); // declared "template struct generator" The compiler should parse this as a cast to vector of the result of generator <0> () () -- and not having any brackets around generator <0> () () it should not think it is a vector initialization. If that doesn't work, looks like we will go with your suggestion. Cheers, Glen Low --- pixelglow software | simply brilliant stuff www.pixelglow.com aim: pixglen From glen.low at pixelglow.com Mon Mar 28 02:10:41 2005 From: glen.low at pixelglow.com (Glen Low) Date: Mon Mar 28 02:28:55 2005 Subject: [macstl-dev] [ANN] macstl 0.2.2 -- multiply high, redesign of ET & iterators Message-ID: <750be7ba723f998ca00b0ea3dedb0fbb@pixelglow.com> Hi All, Just released version 0.2.2, check out: http://www.pixelglow.com/macstl/download/. The multiply high design was inspired by the good folk at Antigrain Geometry, and the redesign of expression templates and iterators should make them easier to extend, especially for optimizing particular expressions. Cheers, Glen Low --- pixelglow software | simply brilliant stuff www.pixelglow.com aim: pixglen From leblanc at skycomputers.com Mon Mar 28 20:59:54 2005 From: leblanc at skycomputers.com (Michael LeBlanc) Date: Mon Mar 28 21:25:25 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> <2568046963269f11e136f9857f2de9e6@pixelglow.com> <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> <8dc3ef43ddb422c1c1083999bd54eaba@skycomputers.com> <0b3689304755ba34813d0f7bc4c84243@skycomputers.com> <9f00c1eaf9d1d54ea2a199680799d800@pixelglow.com> Message-ID: That almost works. I think I never tried removing the outer ()-s. I'm using typedef __vector unsigned int generator_returns; template struct generator { generator_returns operator() () const Cross your fingers. I think that leaves one issue! /usrb/leblanc/macstl/macstl/impl/vec_altivec.h: In function ` macstl::vec macstl::altivec::impl::estimate_divide(const macstl::vec&, const macstl::vec&)': /usrb/leblanc/macstl/macstl/impl/vec_altivec.h:1263: error: conversion from ` const macstl::vec' to non-scalar type ` macstl::vec, 4>' requested This, and others like it, are caused by my "fencing" a few bool things. Recall that GCC stomps on the keyword bool in altivec.h by making it a macro. #ifndef MACSTL_BOOL_IS_SIGNED template <> struct data_vec <__vector bool char> { typedef vec , 16> type; }; template <> struct data_vec <__vector bool short> { typedef vec , 8> type; }; template <> struct data_vec <__vector bool int> { typedef vec , 4> type; }; template <> struct data_vec <__vector pixel> { typedef vec type; }; #endif Any ideas? On Mar 27, 2005, at 1:07 PM, Glen Low wrote: > That looks good, however it would make all the explicit > specializations of generator into partial specializations, which may > in turn slow the compiler down. > > Is it at all possible to compile > > __vector unsigned char zz = (__vector unsigned char) generator <0> () > (); // declared "template struct generator" > > The compiler should parse this as a cast to vector of the result of > generator <0> () () -- and not having any brackets around generator > <0> () () it should not think it is a vector initialization. > > If that doesn't work, looks like we will go with your suggestion. From glen.low at pixelglow.com Mon Mar 28 22:14:21 2005 From: glen.low at pixelglow.com (Glen Low) Date: Mon Mar 28 22:22:55 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> <2568046963269f11e136f9857f2de9e6@pixelglow.com> <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> <8dc3ef43ddb422c1c1083999bd54eaba@skycomputers.com> <0b3689304755ba34813d0f7bc4c84243@skycomputers.com> <9f00c1eaf9d1d54ea2a199680799d800@pixelglow.com> Message-ID: <92ceafe4c0bedcf4f326d1773a0700fc@pixelglow.com> On 28/03/2005, at 8:59 PM, Michael LeBlanc wrote: > That almost works. I think I never tried removing the outer ()-s. > I'm using > > typedef __vector unsigned int generator_returns; > > template int v2, unsigned int v3> > struct generator > { > generator_returns > operator() () const > > Cross your fingers. I think that leaves one issue! Excellent. > > /usrb/leblanc/macstl/macstl/impl/vec_altivec.h: In function ` > macstl::vec > macstl::altivec::impl::estimate_divide(const > macstl::vec&, const macstl::vec 4>&)': > /usrb/leblanc/macstl/macstl/impl/vec_altivec.h:1263: error: conversion > from ` > const macstl::vec' to non-scalar type ` > macstl::vec, 4>' requested > > This, and others like it, are caused by my "fencing" a few bool > things. Recall that GCC stomps on the keyword bool in altivec.h by > making it a macro. > > #ifndef MACSTL_BOOL_IS_SIGNED > template <> struct data_vec <__vector bool char> > { typedef vec , 16> type; }; > template <> struct data_vec <__vector bool short> > { typedef vec , 8> type; }; > template <> struct data_vec <__vector bool int> > { typedef vec , 4> type; }; > template <> struct data_vec <__vector pixel> > { typedef vec type; }; > #endif Side point: does stomping on the C++ reserved word bool mean that altivec.h is useless for C++ work? Line 1263 is a mule or mulo function call, unlikely that it would involve data_vec. Instead I use some SFINAE techniques to automatically make the function mule or mulo parallel the types of the inbuilt vec_mule and vec_mulo, so you might have to do a bit more fencing. Look at line 1006 onwards for example. The type_to_kind and kind_to_type functions assume a 1-1 mapping between native types and vec wrappers; if this is no longer true (since e.g. __vector signed int corresponds to both vec and vec , 4>), we might have to work a bit harder to maintain the relationship. Is there any way, perhaps using a command-line switch or equivalent, to keep the old Motorola style definition of bool? Cheers, Glen Low --- pixelglow software | simply brilliant stuff www.pixelglow.com aim: pixglen From leblanc at skycomputers.com Mon Mar 28 23:13:36 2005 From: leblanc at skycomputers.com (Michael LeBlanc) Date: Mon Mar 28 23:26:14 2005 Subject: [macstl-dev] gcc 3.3 on YellowDogLinux In-Reply-To: <92ceafe4c0bedcf4f326d1773a0700fc@pixelglow.com> References: <874b11fe3c8d70de5f963beecbac6ace@skycomputers.com> <2568046963269f11e136f9857f2de9e6@pixelglow.com> <7dac7cd2c736d155b0f0c370f25ee313@skycomputers.com> <8dc3ef43ddb422c1c1083999bd54eaba@skycomputers.com> <0b3689304755ba34813d0f7bc4c84243@skycomputers.com> <9f00c1eaf9d1d54ea2a199680799d800@pixelglow.com> <92ceafe4c0bedcf4f326d1773a0700fc@pixelglow.com> Message-ID: <483faadbb725c3d5014dbe2ca0180259@skycomputers.com> > Side point: does stomping on the C++ reserved word bool mean that > altivec.h is useless for C++ work? As it is, it clobbers any later use of C++ bool. See below. > Line 1263 is a mule or mulo function call, unlikely that it would > involve data_vec. Sorry. That's 1263 in my hacked up version. 59 #define MACSTL_VEC_BOOLEAN_INT_4 vec 60 61 #ifdef USE_C99_VEC_INIT_IN_TEMPL 62 # define MACSTL_CAST_SCALAR_TO_VECTOR(typ,val) ((vector typ) {val}) 63 #else 64 # define MACSTL_CAST_SCALAR_TO_VECTOR(typ,val) ((vector typ) (val)) 65 #endif .... 1263 MACSTL_VEC_BOOLEAN_INT_4 two_minus_divisor_reciprocal_high = 1264 altivec::cmplt (data_cast > (divisor_reciprocal_low), MACSTL_CAST_SCALAR_TO_VECTOR(signed int, 1)); I changed all instances of "vec >, 4>" as above and ... your benchmark test compiles and links! Of course *sigh* it traps at run-time. > Is there any way, perhaps using a command-line switch or equivalent, > to keep the old Motorola style definition of bool? Not that I know of. After including I can add #undef bool to unhide the reserved word. But that clobbers any legitimate "vector bool ...". This is a problem in GCC < 3.4. In that version, GCC treats vector, bool and pixel as Apple does.