[macstl-dev] gcc 3.3 on YellowDogLinux

[Glen Low]

On 05/04/2005, at 9:04 PM, Michael LeBlanc wrote:

> Glen,
>
> Below is an "executive" summary of the changes I made to get macstl 
> running on my Linux system, PowerPC 7450 running Terrasoft's 
> YellowDogLinux 3.0, using gcc 3.3.n, where n >= 3.  Item (8) near the 
> bottom is that constructor you don't like.  Attached is a tarball with 
> my version of your source.

Thanks for all your hard work, I'm looking through the tarball as we 
"speak". I know it's not a trivial task to get it to work with a 
finicky compiler.
>
> My higher-ups asked me to get involved with macstl and they are aware, 
> now, that it's been successfully ported.  I will remind them about 
> your licensing options and wait for a straight answer.

That would be good. :-)

> I see from your web site that you're pretty busy through the end of 
> next week.  Nothing will happen here right away.  Maybe I wasn't 
> paying attention - are you located in Australia?  My wife and I will 
> spend most of September in Australia on a whirlwind tour, ending at a 
> conference in Adelaide 9/21 - 25.  I would enjoy meeting you, if it's 
> at all possible.

Yes, if you're down under around Perth (Western Australia), I'd love to 
meet up. Perth is some distance from the East Coast cities though, and 
we often get missed on such Australian tours.

> Mike
>
> Change summary
> --------------
>
> I added a new-line to the last line of each of these to make my
> compiler stop griping.
>     macstl/algorithm.h
>     macstl/boolean.h
>     macstl/com.h
>     macstl/mach.h
>     macstl/refptr.h
>     macstl/impl/mach_allocator.h
>     macstl/impl/valarray_indirect.h
>     macstl/impl/valarray_mask.h
>     macstl/impl/valarray_mmaparray.h
>     macstl/impl/valarray_mmx.h
>     macstl/impl/valarray_shift.h
>     macstl/impl/valarray_statarray.h
>     macstl/impl/vec_mmx.h
>     test/common.h
>
> macstl/impl/config.h
>     (1) #define a couple of flags to fence my changes.
>     (2) Linux also HAS_MMAP.
>
> macstl/impl/data.h
>     Change one use of static_cast.
>
> macstl/impl/valarray_altivec.h
>     Use memalign(16,n) instead of malloc(n) to ensure that
>     vectors are properly aligned.
>
> macstl/impl/vec_altivec.h
>     (1) #include <altivec.h> at the top and then repair some
>         preprocessor damage by #undef-ing vector, bool and pixel.
>     (2) Replace all
>             bool        by MACSTL_BOOL
>             pixel       by MACSTL_PIXEL
>             vector      by MACSTL_VECTOR
>         then
>             #define MACSTL_BOOL __bool
>             #define MACSTL_PIXEL __pixel
>             #define MACSTL_VECTOR __vector
>     (3) Fence the data_vec specializations for vector bool 
> char/short/int
>         & vector pixel.  Ditto type_to_kind.
>     (4) Use a macro MACSTL_CAST_SCALAR_TO_VECTOR to cast a single 
> scalar
>         to a vector type, to hide the controversy of {} vs ().
>     (5) Hoist the return type of operator() out of the generator 
> template, still
>         inside the impl namespace.
>     (6) Use a macro MACSTL_CAST_TO_VECTOR, much like (4), to work 
> around
>         broken static_cast in the uses of (5).
>     (7) Change -16 to 0xf0 to stifle a warning from vec_splat_u32 (-16)
>     (8) And, finally, add the following pornographic constructor to
>         allow conversions to <vec <boolean <int>, 4> >.
>
>                 vec (vec <int, 4> v): data_ (v.data())
>                         {
>                         }

A couple of comments:

1.	I would still like to go with gcc 3.4 since that has more sane 
support for __vector __bool and such. Conflating __vector signed and 
__vector bool will bite us in the medium to long run. Of course, you're 
welcome to the changes you've made so far. (This affects your (1), (2), 
and (8)).

2.	MACSTL_BROKEN_STATIC_CAST and MACSTL_CAST_TO_VECTOR shouldn't be 
necessary, I'm happy to go with your definition i.e. using (xxx) 
globally instead of static_cast <xxx> for vector casting. It's still 
fairly easy to do an editor find on and for humans to say "a ha", which 
was the point of the C++ static_cast. Whereas for functional macros 
that are embedded in code, subsequent readers will have to sit down and 
figure out what a MACSTL_CAST_TO_VECTOR means, 2 seconds longer to 
parse than the old C-style cast.

3.	In valarray_altivec:72, don't use MACSTL_MALLOC and fence the entire 
thing with some condition you define in config.h e.g. HAS_MEMALIGN. I 
want to keep all the conditional macros in config.h and minimize the 
use of functional macros if possible -- I think this is the only spot 
we need to swap in memalign for malloc. Is the corresponding dealloc 
function still "free"?

4.	I'm happy to do a global search & replace of bool (within vector 
context) to __bool, and pixel to __pixel. Apple gcc seems to cope, 
haven't tried Codewarrior but if it's the odd man out we can define it 
for them instead e.g. #define __bool bool, whereas the converse 
defining bool and pixel is dangerous e.g. #define bool __bool.

5.	MACSTL_CAST_SCALAR_TO_VECTOR seems unnecessary, but this time it's 
my fault. I should be consistent and eat my own dog food, so for 
example, in vec_altivec.h:1273, I do:

vector unsigned char zero = (vector unsigned char) (0);

but really I should use my own vector initialization syntax:

vec <unsigned char, 16> zero = vec <unsigned char, 16>::fill <0> ();

This keeps all the macro ugliness of choosing between Motorola-style 
and C99 style initialization in a single spot, the generator 
definition. (And avoid subtle issues about whether { } means initialize 
the element after the first to zero or not.)

6.	Other than that, all looks great and an excellent piece of work! If 
you could make the changes above, I'll try to integrate them back into 
the mainline for 0.2.3, once I confirm that it preserves the unit tests 
on the other systems and compilers.

To accept your contribution into the mainline, you'll need to 
acknowledge the following CLA:

=====

1. The Contributor warrants that he is the sole legal and beneficial 
owner of copyright and all other intellectual property rights in all 
source code and documentation that he has contributed or will in future 
contribute to the masctl project (“the Contributed Code”), except to 
the extent that the Contributed Code contains portions taken from the 
masctl project itself or which are in the public domain.
2. The Contributor warrants that there is no contractual or equitable 
obligation of confidence or any other legal duty that prevents the 
Contributor from assigning his rights to the Contributed Code to 
Pixelglow Software, and agrees to indemnify and hold harmless  
Pixelglow Software against any loss, damage or expense it may incur in 
the event of a breach of this warranty.
3. The Contributor hereby irrevocably assigns joint ownership of all 
his copyright and all other intellectual property rights in the 
Contributed Code to Pixelglow Software.

=====

An email (preferably signed) to that effect will be OK.

Contributors will get some royalties on subsequent sales of macstl, I 
haven't nailed down the system yet but it should be through Paypal 
based on SLOC on the diff corresponding to the changes.


Cheers, Glen Low


---
pixelglow software | simply brilliant stuff
www.pixelglow.com
aim: pixglen