Hi,

I'd be interested to adjust/write some sophisticated AltiVec code for MorphOS, but ran into the problem that without GCC 4.x it'd be quite... well, impossible, to for example compile an AltiVec-optimized DCT algorithm for e.g. JPEG decoding.

Is anyone aware of progress in this direction, i.e. a truly AltiVec-enabled GCC port, which can be used under MorphOS?

Thanks & Regards.

Well, first of all you would need an AltiVec-enabled
kernel which hasn't been released yet. (MorphOS 1.5)

Second, the MorphOS Team have repeatidly told us
that everything above GCC 2.95 "sucks" and is "full
of bugs".

So don't hold your breath on having GCC 4 to MorphOS.
Chose Gentoo Linux instead. There you have full
AltiVec support and the latest GCC.

And it seems this is unfortunately true for AltiVec support in GCC4. I've got some unofficial GCC4 port from Morgoth (Marcin Kurek). I've compiled fir.filter (a Reggae class) with it and it was 40% slower in tests than version compiled with 2.95.3 + Altivec support. I've looked at disassembled executable and I must say GCC4 generated code is a total disaster, it is three times longer and has some brain-damaged instruction [dis]ordering. Of course it can be broken port, but I doubt it given that the compiler generates working code (but inefficient in case of AltiVec). It may be also caused by some weird optimizations, but I have no time to check every one option out of thousands. At least 2.95.3 compiles exactly what I code :wink:.

It seems that there is no publicly available port of GCC 2.95.x for MOS with AltiVec support. Threre was one on Marcin Kurek projects page, but the link is broken now. Anyway the main obstacle is lack of AltiVec support in public MOS kernels, the only way to get the one with AltiVec enabled is to ask MorphOS Team for one.

It is not true. GCC 2.95.3 (with enabled AltiVec) is enough. I've verified it myself compiling many of Reggae classes for MorphOS.

But as long as the mos-kernel itself doesn't support altivec, there's no need for a altivec-support in mos-gcc...

btw gcc-4.1.1 works very good under my altivec-gentoo...

Frostwork:
Same here. No problems at all with GCC 4.1.1 on
all my Gentoo machines.

Update: AltiVec enabled GCC 2.95.4-6.

That's an interesting statement. I've also tried with the GCC from the MOS SDK but none of the documented AltiVec switches did work. Besides there's no <altivec.h> present. The vector datatype is not known.

Ah, now I see. Sorry, but who cares about unofficial versions anyway? That's exactly the problem, if everyone has to build his own compiler (2.95.x or 4.x) in order to get things working - who knows which other bugs or missing features they have...

Oops. It's surely a problem if AltiVec is not considered in the current ABI and if the MorphOS scheduler does not know about it. Good point.

Besides, as far as I can tell, there are significant differences between how GCC 2.95.x and 3.x/4.x handle AltiVec respectively Motorola and FSF.

When porting/coding AltiVec stuff - let's say with some libjpeg patches as result - of course I'd prefer to do this against the most recent API, for later re-use...

Hi Grzegorz,

I would love to expand somewhere on Power Developer about why gcc 4.x (and 3.x) sucks maybe with an example of bad code generation. It would be nice for us (and maybe a nudge for the GCC guys) to put it on a semi-high-profile website and explain which GCC is the best for producing the most optimized code, especially for AltiVec and especially a comparison between AltiVec hand-tuned code, and GCC 4.x's autovectorisation :)

Okay I am not asking you to go into all of that on your own, but this is what Power Developer is for; we should all sit down and work on something, since documenting these kinds of quirks is fairly important. The next Debians, Ubuntus and Fedoras etc. are all compiled with GCC 4 and if they are producing awful code it will not be very good for Power Architecture performance in general.

We should separate two things here, the first one is what GCC 4 does with hand-tuned code (an this is the subject of the paper below), the second one (beyond my scope for now, as autovectorisation is still poor compared to a code written specifically for SIMD operators) is autovectorisation of scalar code.

Anyway here it is: GCC 2 versus GCC 4 compiling AltiVec code, a detailed discussion of a case. Note however this is not a scientific paper in the strict sense - it hasn't undergone peer-review process, it will also not be published neither on any conference, nor journal.

bump:
iv been following a thread http://www.beyond3d.com/forum/showthrea ... post894499
and pointed several of the coders/readers to your post Grzegorz (and Markos) in the hope to get some interesting threads over here as it seems to be almost dead lately, anyway perhaps you might like to pop over there and comment on the reply i just had from a long time games programmer.

the thread itself is intersting since inefficient
'installed the GNU toolchains for Cell development this evening and I'm having too much fun' on his ps3 and started running and investigating Altivec code.
http://www.beyond3d.com/forum/showthrea ... 058&page=7

i find it odd that the ps3/cell sections here arnt better used as yet, it seems noone knows or cared that this place exists ...

Oh, no, not another messy forum. I have enough already... I've read the posts and I can see all they can relpy to me is "GCC4 works with our code". Maybe, but they missed my two main points:

1. The same code compiled with two versions of compiler - an old one and a new one, is significantly slower on a new one - it is unacceptable IMO.

2. GCC4 "advanced" AltiVec instructions scheduling can be easily beaten out with simple hand-tuning (I mean SIMPLE, so no simulations, cycle counting etc.)

:D 'Oh, no, not another messy forum'

true, but its full of the worlds top games industry coders, i also found it interesting that the admission that the bulk of their gaming code isnt optimised and they rely on the compiler to get better results.

happy cristmas :D