I can't replicate what you have shown (atleast without your exact compile strings)
$ cat floaty.c
#include <stdio.h>
int main( void )
{
double c0=.6;
double k1;
int t0,t1;
int i=1,j=6;
t0=(1.0-c0)*i+c0*j;
k1=(1.0-c0)*i+c0*j;
t1=k1;
printf("t0=%d\n",t0);
printf("k1=%e\n",k1);
printf("t1=%d\n",t1);
c0=k1-4;
printf("k1-4=%e\n",c0);
return 0;
}
$ gcc -march=athlon-xp -mfpmath=sse floaty.c -o floaty
$ ./floaty
t0=3
k1=4.000000e+00
t1=4
k1-4=0.000000e+00
$ gcc -march=athlon-xp -mfpmath=387 floaty.c -o floaty
$ ./floaty
t0=3
k1=4.000000e+00
t1=4
k1-4=0.000000e+00
I think the athlon-xp sse doesn't have support for double and it is probably using 387 here. Do you happen to have a P4 or newer AMD chip with sse2? Also, with regards to 80bits in 387 and 64 in sse, you want to look at -ffloat-store. Last time I checked, it was supposed to help in these kind of situations.
Regards,
Imran
On 3/4/06, ilLogict <[EMAIL PROTECTED]> wrote:
Le Sat, 4 Mar 2006 11:29:48 +0900, dans son message intitulé Re:
[e-devel] [patch] edje jittery with sse, Carsten Haitzler (The
Rasterman) <[EMAIL PROTECTED]> a eu le courage de nous raconter :
> On Sat, 4 Mar 2006 02:58:48 +0100 ilLogict <[EMAIL PROTECTED]>
> babbled:
>
> > Le Sat, 4 Mar 2006 10:32:22 +0900, dans son message intitulé Re:
> > [e-devel] [patch] edje jittery with sse, Carsten Haitzler (The
> > Rasterman) <[EMAIL PROTECTED]> a eu le courage de nous raconter :
> >
> > > On Sat, 4 Mar 2006 02:25:20 +0100 ilLogict <[EMAIL PROTECTED]>
> > > babbled:
> > >
> > > > Le Sat, 4 Mar 2006 09:49:41 +0900, dans son message intitulé Re:
> > > > [e-devel] [patch] edje jittery with sse, Carsten Haitzler (The
> > > > Rasterman) <[EMAIL PROTECTED]> a eu le courage de nous
> > > > raconter :
> > > >
> > > > > On Fri, 3 Mar 2006 23:49:20 +0100 ilLogict
> > > > > <[EMAIL PROTECTED]> babbled:
> > > > >
> > > > > > Hello!
> > > > > >
> > > > > > Attached is a patch that solves the Edje jittery issue. The
> > > > > > question is, why was it working with 387?
> > > > > > Well, now it seems to work as well with 387 and sse.
> > > > > > But (there's always a but ;D), it now seems that there are
> > > > > > problems with some widgets.
> > > > > > There were positionning issues with ilist items, they
> > > > > > should look as before (thank you again boneyfrog for your
> > > > > > screenshot) with attached patch
> > > > > > (e_ilist_edje_jittery_update.patch). Menu items, when
> > > > > > focused, seem to move down and right by 1px, and of course
> > > > > > don't go back where they should be when unfocused, but I
> > > > > > was unable to find a workaround :'(. I'm pretty sure that
> > > > > > other things may have broken. :(
> > > > >
> > > > > dud u just upgrade compilers? as nothing has changed in edje
> > > > > for a while. did u change CFLAGS?
> > > > >
> > > > > > Cheers!
> > > > > >
> > > > > > ilLogict
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ------------- Codito, ergo sum - "I code, therefore I am"
> > > > > -------------- The Rasterman (Carsten Haitzler)
> > > > > [EMAIL PROTECTED] 裸好多
> > > > > Tokyo, Japan (�|京 日本)
> > > >
> > > > Hello!
> > > >
> > > > Well, it wasn't well formulated.
> > > > My jittery wordkaround patch creates the issues I've listed :).
> > >
> > > ooh - sorry - missed that - yes. i see how it would. you are now
> > > rounding things up where they shouldnt be in many places for
> > > example.
> > >
> > > --
> > > ------------- Codito, ergo sum - "I code, therefore I am"
> > > -------------- The Rasterman (Carsten Haitzler)
> > > [EMAIL PROTECTED] 裸好多
> > > Tokyo, Japan (�|京 日本)
> >
> > Hello!
> >
> > Why shouldn't they be rounded but just floored ?
>
> because flooring is the age-old standard kind of rounding that
> everything expects! a lot of code is built to expect just that. and
> then designs are also made to assume that too.
>
> --
> ------------- Codito, ergo sum - "I code, therefore I am"
> -------------- The Rasterman (Carsten Haitzler)
> [EMAIL PROTECTED] 裸好多
> Tokyo, Japan (�|京 日本)
Hello!
Ok, thank you very much :)
After hacking a little, here is an explanation: for instance, let's
get a code:
double c0=.6;
double k1;
int t0,t1;
int i=1,j=6;
t0=(1.0-c0)*i+c0*j;
k1=(1.0-c0)*i+c0*j;
t1=k1;
printf("t0=%d\n",t0);
printf("k1=%e\n",k1);
printf("t1=%d\n",t1);
Compiling with 387 floating point unit shows:
t0=4
k1=4.000000
t1=4
Nothing special to say ;D. But compiling with sse enabled shows:
t0=3
k1=4.000000e+00
t1=3
Well, this seems stange. Let's display k1-4:
k1-4=-4.440892e-16
That's it! Fact that with sse internals are only 64bits instead of
80bits with 387 propagates errors.
Correcting that will be a bit tricky, imho.
Cheers!
ilLogict
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1642
_______________________________________________
enlightenment-devel mailing list
enlightenment-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
