[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AClock fork with republican time

From: Banlu Kemiyatorn
Subject: Re: AClock fork with republican time
Date: Thu, 23 Nov 2006 05:26:20 +0700
User-agent: Thunderbird (X11/20060921)

Ingolf Jandt wrote:

> I just try to understand.

Ah, Ok, Actually you are welcome to criticise my code, I was just kidding.
But now, for the sake of humor let's do this :)

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
int main(int argc,char **argv)
double a,b,c;
a = atof(argv[1]);
b = atof(argv[2]);

/* Actually NULL is not allowed, or modf would be slow down by an if.
* And I was thinking, storing something onto stack required more time.
return 0;

gcc -S test.c
wc -l test.s
64 test.s

now let's see my method.

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
int main(int argc,char **argv)
double a,b,c;
a = atof(argv[1]);
b = atof(argv[2]);

c = a - b * floor(a/b);
/* I expect compile to generate the same assembly for the above 2 lines and
* c = (a - b * floor(a/b))/b
* but it didn't. Why not? But N/M it for now.
return 0;

gcc -S test1.c
wc -l test1.s
68 test1.s

Now it looks like my code is actually 4 lines longer than yours but
let's take this further..

gdb a.out

(gdb) break floor
Function "floor" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y

Breakpoint 1 (floor) pending.
(gdb) run 10.0 1.0
Starting program: /home/id/a.out 10.0 1.0
Breakpoint 2 at 0xb7f9b510
Pending breakpoint "floor" resolved

Breakpoint 2, 0xb7f9b510 in floor () from /lib/tls/i686/cmov/libm.so.6
(gdb) disassemble
Dump of assembler code for function floor:
0xb7f9b510 <floor+0>: fldl 0x4(%esp)
0xb7f9b514 <floor+4>: sub $0x8,%esp
0xb7f9b517 <floor+7>: fstcw 0x4(%esp)
0xb7f9b51c <floor+12>: mov $0x400,%edx
0xb7f9b521 <floor+17>: or 0x4(%esp),%edx
0xb7f9b525 <floor+21>: and $0xf7ff,%edx
0xb7f9b52b <floor+27>: mov %edx,(%esp)
0xb7f9b52e <floor+30>: fldcw (%esp)
0xb7f9b531 <floor+33>: frndint
0xb7f9b533 <floor+35>: fldcw 0x4(%esp)
0xb7f9b537 <floor+39>: add $0x8,%esp
0xb7f9b53a <floor+42>: ret

Ok, then do similar thing with the modf()...

Dump of assembler code for function modf:
0xb7ea4dc0 <modf+0>: push %ebp
0xb7ea4dc1 <modf+1>: mov %esp,%ebp
0xb7ea4dc3 <modf+3>: push %edi
0xb7ea4dc4 <modf+4>: push %esi
0xb7ea4dc5 <modf+5>: sub $0x38,%esp
0xb7ea4dc8 <modf+8>: fldl 0x8(%ebp)
0xb7ea4dcb <modf+11>: movl $0x0,0xfffffff0(%ebp)
0xb7ea4dd2 <modf+18>: movl $0x0,0xfffffff4(%ebp)
0xb7ea4dd9 <modf+25>: movl $0x0,0xffffffe8(%ebp)
0xb7ea4de0 <modf+32>: fstl 0xffffffc0(%ebp)
0xb7ea4de3 <modf+35>: mov 0xffffffc4(%ebp),%edi
0xb7ea4de6 <modf+38>: movl $0x0,0xffffffec(%ebp)
0xb7ea4ded <modf+45>: mov 0xffffffc0(%ebp),%esi
0xb7ea4df0 <modf+48>: movl $0x0,0xffffffe0(%ebp)
0xb7ea4df7 <modf+55>: mov %edi,%edx
0xb7ea4df9 <modf+57>: mov %esi,%eax
0xb7ea4dfb <modf+59>: movl $0x0,0xffffffe4(%ebp)
0xb7ea4e02 <modf+66>: mov %edi,%esi
0xb7ea4e04 <modf+68>: mov %eax,%edi
0xb7ea4e06 <modf+70>: movl $0x0,0xffffffd8(%ebp)
0xb7ea4e0d <modf+77>: mov %edx,%eax
0xb7ea4e0f <modf+79>: sar $0x14,%eax
0xb7ea4e12 <modf+82>: movl $0x0,0xffffffdc(%ebp)
0xb7ea4e19 <modf+89>: and $0x7ff,%eax
0xb7ea4e1e <modf+94>: lea 0xfffffc01(%eax),%ecx
0xb7ea4e24 <modf+100>: movl $0x0,0xffffffd0(%ebp)
0xb7ea4e2b <modf+107>: cmp $0x13,%ecx
0xb7ea4e2e <modf+110>: movl $0x0,0xffffffd4(%ebp)
0xb7ea4e35 <modf+117>: movl $0x0,0xffffffc8(%ebp)
0xb7ea4e3c <modf+124>: movl $0x0,0xffffffcc(%ebp)
0xb7ea4e43 <modf+131>: jg 0xb7ea4e83 <modf+195>
0xb7ea4e45 <modf+133>: test %ecx,%ecx
0xb7ea4e47 <modf+135>: js 0xb7ea4f20 <modf+352>
0xb7ea4e4d <modf+141>: mov $0xfffff,%edx
0xb7ea4e52 <modf+146>: mov %esi,%eax
0xb7ea4e54 <modf+148>: sar %cl,%edx
---Type <return> to continue, or q <return> to quit---

Enjoy reading the rest of it...

It looks to me that my method is faster. And it could be worth
a clock that update itself at > 10 FPS.

Hope that answer your question.

Best regards,

PS. Actually I didn't even know what modf() do when I wrote it.
Or could it be Alex M.'s code and if it was his then I am not surprised
by the result of the above investigation :P

reply via email to

[Prev in Thread] Current Thread [Next in Thread]