On Fri, 2007-01-12 at 15:24 +0100, Ralf Corsepius wrote: > On Fri, 2007-01-12 at 21:29 +0800, David Woodhouse wrote: > > On Fri, 2007-01-12 at 14:08 +0100, Axel Thimm wrote: > > > What is the difference? If a unit has been compiled with altivec and > > > the resulting binary calls something in this unit on a non-altivec > > > system your binary will still boom, or not? > > > > > > E.g. if we need to support non-altivec system then altivec must be > > > strictly banned unless - as you wrote - the software is smart enough > > > to do it at runtime (which is seldom). > > > > Not _so_ seldom, in Altivec-capable code. Programs like xine and mplayer > > get it right. There are parts which are compiled with -maltivec but > > they're conditionally called. > > Conditionally at compile-time or at run-time? > > Normally, packages trying squeeze out cpu-variant specifics apply > compile-time conditionals. i.e. they break on some cpu-variants at > run-time (The reason why rtems has an -maltivec multilib ;) ). Runtime. Here's how it should work: 1: put all altivec functions in their own execution unit (ie, C file) 2: put the code that _calls_ these altivec functions in another file 3: that other file will need to do CPU ID checks at runtime; if it finds that it is running on an altivec capable CPU, it calls the altivec-enabled code from (1) 4: if it finds it is _not_ running on an altivec-enabled CPU, then it must call slowpath functions that are _not_ compiled with altivec So you can certain compile some files with altivec; but at runtime you must _never_, _ever_ unconditionally call any code in those files without first checking that you are running on an altivec-capable CPU. Check out the X server code here: http://gitweb.freedesktop.org/?p=xorg/xserver.git;a=tree specifically, the files "fbpict.c" and "fbmmx.c". Note the function fbHaveMMX() at the bottom of fbpict.c. It returns true if the machine has MMX. There are conditional statements throughout the fbpict.c file that check for MMX, and if so, call a function in 'fbmmx.c' that contains mmx code. There is _no_ MMX code in fbpict.c. if (fbHaveMMX()) func = fbCompositeSolidMask_nx8x0565mmx; else func = fbCompositeSolidMask_nx8x0565; [snip] (*func) (op, pSrc, pMask, pDst, x_src, y_src, x_msk, y_msk, x_dst, y_dst, w_this, h_this); _That_ is the correct way to do it. The fbCompositeSolidMask_nx8x0565mmx() function is in fbmmx.c, which is compiled with MMX flags, but never gets unconditionally called at all. You have to put the stuff that needs the MMX flags in a separate file to ensure that GDB doesn't insert MMX instructions into functions that you don't want it too. Dan > > > Are there relevant numbers of G3 systems out there that we want to > > > support (excluding the unreleased G3+altivec chip)? > > > > I don't know about G3 but there are relevant numbers of Altivec-less > > systems out there, since that includes POWER -- and in particular a > > bunch of our build machines. > > > > Do not build packages which use Altivec unconditionally -- always make > > it check at runtime, just as we do for MMX/SSE/etc. > OK, that's what I wanted to hear. > > => This package is broken, -maltivec is forbidden. > > Ralf > > -- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
