hi.
inspired by the changes jamie has done to GemPixConvertAltivec over the weekend, i have done some more (since jamie's changes only fixed _part_ of the errors we get on the 10.3 build machine). naturally i haven't done any testings, apart from looking whether it compiles fine on my machines.
the change is in GemPixConvertAltivec:669 ( in YUV422_to_BGRA_altivec() ), where i changed the type from (vector signed int) to (vector unsigned int)
this might have weird side effects, or might as well not. i am pretty sure, that there are still some more type errors - let's wait for tomorrow's autobuild log....
mfg.adsr IOhannes
PS: oh, and i finally found a solution for the weird "\p" character warning in GemWinCreateMac: add "-fpascal-strings" to the CXXFLAGS.
On Oct 30, 2006, at 4:06 AM, IOhannes m zmoelnig wrote:
...snip...
the change is in GemPixConvertAltivec:669 ( in YUV422_to_BGRA_altivec() ), where i changed the type from (vector signed int) to (vector unsigned int)
this might have weird side effects, or might as well not. i am pretty sure, that there are still some more type errors - let's wait for tomorrow's autobuild log....
...good idea, I'd already tried it, and indeed it does have weird side effects, so I didn't commit it :-P It screwed with the brightness levels, especially at lower values...maybe some compensation could make it work, but I haven't found it...
...in any event, I'm still poking around on it!
PS: oh, and i finally found a solution for the weird "\p" character warning in GemWinCreateMac: add "-fpascal-strings" to the CXXFLAGS.
...cool! I've got some more flags I'd like to add to the configure process on mac, now that I'm trying to compile Gem that way...basically, I'm starting to switch from xcode for gem: it's funny how one unsolvable error (which has been around for awhile) can be the final straw...
jamie
james tittle wrote:
On Oct 30, 2006, at 4:06 AM, IOhannes m zmoelnig wrote:
this might have weird side effects, or might as well not. i am pretty sure, that there are still some more type errors - let's wait for tomorrow's autobuild log....
...good idea, I'd already tried it, and indeed it does have weird side effects, so I didn't commit it :-P It screwed with the brightness
darn, i should have known...
levels, especially at lower values...maybe some compensation could make it work, but I haven't found it...
...in any event, I'm still poking around on it!
so should i revert the changes (so it works again at least with more tolerant compilers) or should we just wait for you to come up with a real solution?
PS: oh, and i finally found a solution for the weird "\p" character warning in GemWinCreateMac: add "-fpascal-strings" to the CXXFLAGS.
...cool! I've got some more flags I'd like to add to the configure process on mac, now that I'm trying to compile Gem that way...basically, I'm starting to switch from xcode for gem: it's funny how one
good to hear. i think that the configure-stuff has become pretty usable (esp. since configure-flags are preserved over configure-regenerations)
unsolvable error (which has been around for awhile) can be the final straw...
what would that be? (i thought the pascal-strings is really cosmetic (though probably not))
mfg.adsr IOhannes
On Oct 30, 2006, at 12:26 PM, IOhannes m zmoelnig wrote:
so should i revert the changes (so it works again at least with more tolerant compilers) or should we just wait for you to come up with a real solution?
...well, revert for the moment, unless you absolutely need a working 10.3 compatible binary...I'll be working on it over the next while, but it's hard to say when inspiration arrives while sitting up in the hospital ;-\
unsolvable error (which has been around for awhile) can be the final straw...
what would that be? (i thought the pascal-strings is really cosmetic (though probably not))
...there are some linker flags that are being forced which I have no way of changing/manipulating, and it's currently preventing me to use pix_2pdp/pdp2gem :-( Ultimately, I still like xcode for gui editing, but will be using it with the external configure/makefile for the build system...
...the other flags I've fallen into using are:
-Os -fno-builtin -falign-loops=32 -falign-functions=32 -falign- jumps=32 -freg-struct-return -mpowerpc-gfxopt
...-Os is preferred for optimized builds over -O2 or -O3, and - mpowerpc-gfxopt is supposed to be a powerpc speed up...
jamie
james tittle wrote:
On Oct 30, 2006, at 12:26 PM, IOhannes m zmoelnig wrote:
so should i revert the changes (so it works again at least with more tolerant compilers) or should we just wait for you to come up with a real solution?
...well, revert for the moment, unless you absolutely need a working
done
10.3 compatible binary...I'll be working on it over the next while, but it's hard to say when inspiration arrives while sitting up in the hospital ;-\
i hope this will be all over soon...
unsolvable error (which has been around for awhile) can be the final straw...
what would that be? (i thought the pascal-strings is really cosmetic (though probably not))
...there are some linker flags that are being forced which I have no way of changing/manipulating, and it's currently preventing me to use pix_2pdp/pdp2gem :-( Ultimately, I still like xcode for gui editing, but will be using it with the external configure/makefile for the build system...
...the other flags I've fallen into using are:
-Os -fno-builtin -falign-loops=32 -falign-functions=32 -falign-jumps=32 -freg-struct-return -mpowerpc-gfxopt
ok, i have added most of them to the configure checks. what i have not added is "-fno-builtin" since there is usually no real reason to do so.
...-Os is preferred for optimized builds over -O2 or -O3, and
"-Os" is now the default on Darwin; however autoconf usually sets up "-g -O2" by itself, and it is hard to suppress this (you can do, by calling 'CXXFLAGS="" ./configure ...'
-mpowerpc-gfxopt is supposed to be a powerpc speed up...
i added this, but i disabled it by default (use "./configure --enable-powerpc" to turn it on manually), since i am a bit afraid of it...
mfg.adr IOhannes
jamie
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On Mon, 30 Oct 2006, james tittle wrote:
...-Os is preferred for optimized builds over -O2 or -O3,
Why? the GCC manual says that -Os is for "optimising for size", which isn't exactly optimising for speed. If code size has such a positive impact on speed, does that mean that the PowerPC caches are small and/or the bus of the main RAM is slow ?
Btw, -Os disables most alignment optimisations. I thought that most processors are quite sensitive to alignment; is that belief outdated?
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
Mathieu Bouchard wrote:
On Mon, 30 Oct 2006, james tittle wrote:
...-Os is preferred for optimized builds over -O2 or -O3,
Why? the GCC manual says that -Os is for "optimising for size", which isn't exactly optimising for speed. If code size has such a positive impact on speed, does that mean that the PowerPC caches are small and/or the bus of the main RAM is slow ?
Btw, -Os disables most alignment optimisations. I thought that most processors are quite sensitive to alignment; is that belief outdated?
no, i don't think so. that is the reason, why the other flags (-falign-loops=32 -falign-functions=32 -falign-jumps=32) turn alignment on again.
mfg.adr IOhannes
On Tue, 31 Oct 2006, IOhannes m zmoelnig wrote:
On Mon, 30 Oct 2006, james tittle wrote:
...-Os is preferred for optimized builds over -O2 or -O3,
Btw, -Os disables most alignment optimisations. I thought that most processors are quite sensitive to alignment; is that belief outdated?
no, i don't think so. that is the reason, why the other flags (-falign-loops=32 -falign-functions=32 -falign-jumps=32) turn alignment on again.
Ah, but a majority of what -Os disables (according to the GCC manual) is the alignment options; so instead of -Os, -O2 could be used, and it could be figured out which of the remaining three options of -Os are making the difference:
-freorder-blocks -freorder-blocks-and-partition -fprefetch-loop-arrays
_ _ __ ___ _____ ________ _____________ _____________________ ... | Mathieu Bouchard - tél:+1.514.383.3801 - http://artengine.ca/matju | Freelance Digital Arts Engineer, Montréal QC Canada
-
IOhannes m zmoelnig -
james tittle -
Mathieu Bouchard