Hi,

David Neary writes:

The new MMX composite code in the 1.3 tree doesn't build for me - am I the only one? My processor is a 350MHz K6-2 with mmx support, and the error says that there are a bunch (6, I think) of unknown registers in the asm (%mm0, %mm1, ...).

The configure check was supposed to check that your compiler/assembler supports the MMX assembly command set. Can you please check the values of USE_MMX and USE_SSE in config.h. There might be a problem with the configure check or the new code is missing an #ifdef.

Sven

Hi,

indeed there was an #ifdef missing. My latest commit should fix the build for you. Can you please check config.log nevertheless since I'd like to make sure that the configure check did it's job correctly.

These new checks could need some more testing. So if you are on an obscure hardware-platform or just use a hopelessly outdated compiler and assembler, please test current CVS.

Sven

Hi,

David Neary writes:

That said, some day soon, the GIMP developers are going to have to get together for a brainstorning session about how we can communicate better with the user base, and vice versa. With IRC, Bugzilla, 2 mailing lists, usenet, the bugs@g.o mail address, the web page and the GUG (wouldn't it be nice to tie in more tightly with those guys?), there is an awful lot of information flying about, but none of it is getting to everybody.

Sven's talked about the dead documentation project, lots of usability issues have cropped up recently on the mailing list, and we seem to have become quite insular in our thinking. I would like us to sit down and talk about how we can make it easier for people to find out what's happenning with the GIMP, and easier for them to let us know what they thing should be happening.

The long-due overhaul of the web-site could help to improve this situation.

Sven

Hi,

David Neary writes:

The new code is missing a #ifdef somewhere, I think - perhaps composite-mmx.c shouldn't be build at all if USE_MMX isn't defined... but that's another issue.

I've added an #ifdef that causes the file content to be skipped. I prefer #ifdefs over automake conditionals since the latter tend to slow down the build and clutter the Makefile.am.

My processor does support mmx. It passes the configure test - when I run the configure test manually (that is, load register %mm0 in a .S file), it works fine. However, the same thing in an asm() in a C file seems to not compile. Really weird...

So config.h defines USE_MMX for you? Looks as if we have to improve the configure test. The check we use now is copied from DirectFB and seems to work there. In DirectFB we include the assembler code as

__asm__ __volatile__ ()

while the new code in The GIMP seems to be using

asm()

I don't know this stuff good enough to know the difference, but I'd say we need to change the configure check so that is uses the same asm constructs that the code in app/composite is using.

Sven

Hi David,

could you please test the attached diff to configure.in. It should find the problem with your compiler and it even simplifies things a bit.

Sven

Index: configure.in =================================================================== RCS file: /cvs/gnome/gimp/configure.in,v retrieving revision 1.465
diff -u -p -r1.465 configure.in
--- configure.in 9 Jul 2003 23:52:46 -0000 1.465 +++ configure.in 10 Jul 2003 13:40:36 -0000 @@ -423,14 +423,10 @@ AC_ARG_ENABLE(sse,
if test "x$enable_mmx" = xyes; then
- dnl Necessary for assembler sources - save_ac_ext="$ac_ext"
- ac_ext=S
-
AC_MSG_CHECKING(whether we can compile MMX code)
- echo " movq 0, %mm0" > conftest.S - if AC_TRY_EVAL(ac_compile); then
+ AC_COMPILE_IFELSE([asm ("movq 0, %mm0");], +
AC_DEFINE(USE_MMX, 1, [Define to 1 if MMX assembly is available.]) AC_MSG_RESULT(yes)

@@ -438,26 +434,21 @@ if test "x$enable_mmx" = xyes; then
AC_MSG_CHECKING(whether we can compile SSE code)
- echo " movntps %xmm0, 0" > conftest.S - if AC_TRY_EVAL(ac_compile); then + AC_COMPILE_IFELSE([asm ("movntps %xmm0, 0");], AC_DEFINE(USE_SSE, 1, [Define to 1 if SSE assembly is available.]) AC_MSG_RESULT(yes)
- else
+ ,
enable_sse=no
AC_MSG_RESULT(no)
AC_MSG_WARN([The assembler does not support the SSE command set.]) - fi
+ )

fi
-
- else
+ ,
enable_mmx=no
AC_MSG_RESULT(no)
AC_MSG_WARN([The assembler does not support the MMX command set.]) - fi
-
- rm conftest*
- ac_ext="$save_ac_ext"
+ )

fi

@@ -472,24 +463,16 @@ AC_ARG_ENABLE(altivec,
if test "x$enable_altivec" = xyes; then
- dnl Necessary for assembler sources - save_ac_ext="$ac_ext"
- ac_ext=S
-
AC_MSG_CHECKING(whether we can compile Altivec code)
- echo " vand %v0, %v0, %v0" > conftest.S - if AC_TRY_EVAL(ac_compile); then
+ AC_COMPILE_IFELSE([asm ("vand %v0, %v0, %v0");], AC_DEFINE(USE_ALTIVEC, 1, [Define to 1 if Altivec assembly is available.]) AC_MSG_RESULT(yes)
- else
+ ,
enable_altivec=no
AC_MSG_RESULT(no)
AC_MSG_WARN([The assembler does not support the Altivec command set.]) - fi
-
- rm conftest*
- ac_ext="$save_ac_ext"
+ )

fi

This isn't quite ready to go yet. But thanks for the note. The default build behaviour right now is to not build the new code.

Helvetix

On Thu, Jul 10, 2003 at 08:36:44AM +0200, David Neary wrote:

Hi,

The new MMX composite code in the 1.3 tree doesn't build for me - am I the only one? My processor is a 350MHz K6-2 with mmx support, and the error says that there are a bunch (6, I think) of unknown registers in the asm (%mm0, %mm1, ...).

I'm mailing this to the list because, to be quite honest, I'm not sure how many people actually look at bugzilla these days apart from Sven and Raphael. But that's another issue...

Cheers, Dave.

Hi,

Helvetix Victorinox writes:

This isn't quite ready to go yet. But thanks for the note. The default build behaviour right now is to not build the new code.

Please, if possible, let the code be build. We need as much testing as possible and we lack experience with building MMX code and the like. I would like the new code to be build even though it is not used yet.

Sven

On Thu, Jul 10, 2003 at 01:17:49PM +0200, Sven Neumann wrote:

__asm__ __volatile__ ()

while the new code in The GIMP seems to be using

asm()

I don't know this stuff good enough to know the difference, but I'd

__keyword__-style keywords are always there, even if gcc extensions should be disabled (strict ansi mode etc..

volatile means that there are side effects that are not (or can not) be properly specified. unless you write a kernel or other arcane magic, the need to use volatile indicates a bug in the constraints (i.e. forgetting to tell the compiler properly about the effects of the statement).

for example, gcc will happily optimize away an asm() if the output operands aren't used, as it can then assume that the computing isn't necessary. volatile will keep it from doing that, but that might also keep useful optimizations from doing their work.

On Fri, Jul 11, 2003 at 12:52:08AM +0200, David Neary wrote:

asm("movq %0, %%mm1"
:
: "m"(rgba8_alpha_mask)
: "%mm1");

breaks on the second %mm1;

I don't think there should be a % in the list of clobbered registers. What's worse, I don't even think most versions of gcc know about MMX registers at all (I might be mistaken, though :-) ) and thus you'd need to simply clobber the entire FPU stack (which the MMX registers get aliased upon).

/* Steinar */

On Fri, Jul 11, 2003 at 12:13:29PM +0200, "Steinar H. Gunderson" wrote:

I don't think there should be a % in the list of clobbered registers.

yupp, there is no %mm1 register :)

worse, I don't even think most versions of gcc know about MMX registers at

versions 2.x (usually) don't know them, versions 3.x generally do know them.

On Fri, 11 Jul 2003, Steinar H. Gunderson wrote:

On Fri, Jul 11, 2003 at 12:52:08AM +0200, David Neary wrote: I don't think there should be a % in the list of clobbered registers. What's worse, I don't even think most versions of gcc know about MMX registers at all (I might be mistaken, though :-) ) and thus you'd need to simply clobber the entire FPU stack (which the MMX registers get aliased upon).

How hard would it be to write an autoconf test for that?

Rockwlrs