Was just looking again at the assembly file generated by GCC, and noted
 this pattern I have already seen - maybe beginning with 4.0.
 In short:

[EMAIL PROTECTED]:~/projet/gujin$ /home/etienne/projet/toolchain/bin/gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/home/etienne/projet/toolchain
--enable-languages=c
Thread model: posix
gcc version 4.1.1 20060517 (prerelease)

[EMAIL PROTECTED]:~/projet/gujin$ cat tmp.c
unsigned short nbinch (unsigned short Hsize_cm)
  {
  return (3 * Hsize_cm / 4 + 2) / 3;
  }

[EMAIL PROTECTED]:~/projet/gujin$ /home/etienne/projet/toolchain/bin/gcc tmp.c 
-S -Os -o
tmp.s -fomit-frame-pointer -fverbose-asm -march=i386

[EMAIL PROTECTED]:~/projet/gujin$ cat tmp.s
        .file   "tmp.c"
# GNU C version 4.1.1 20060517 (prerelease) (i686-pc-linux-gnu)
#       compiled by GNU C version 4.1.1 20060517 (prerelease).
# GGC heuristics: --param ggc-min-expand=62 --param ggc-min-heapsize=60570
# options passed:  -iprefix -march=i386 -auxbase-strip -Os
# -fomit-frame-pointer -fverbose-asm
# options enabled:  -falign-loops -fargument-alias -fbranch-count-reg
# -fcaller-saves -fcommon -fcprop-registers -fcrossjumping
# -fcse-follow-jumps -fcse-skip-blocks -fdefer-pop
# -fdelete-null-pointer-checks -fearly-inlining
# -feliminate-unused-debug-types -fexpensive-optimizations -ffunction-cse
# -fgcse -fgcse-lm -fguess-branch-probability -fident -fif-conversion
# -fif-conversion2 -finline-functions -finline-functions-called-once
# -fipa-pure-const -fipa-reference -fipa-type-escape -fivopts
# -fkeep-static-consts -fleading-underscore -floop-optimize
# -floop-optimize2 -fmath-errno -fmerge-constants -fomit-frame-pointer
# -foptimize-register-move -foptimize-sibling-calls -fpcc-struct-return
# -fpeephole -fpeephole2 -fregmove -freorder-functions
# -frerun-cse-after-loop -frerun-loop-opt -fsched-interblock -fsched-spec
# -fsched-stalled-insns-dep -fshow-column -fsplit-ivs-in-unroller
# -fstrength-reduce -fstrict-aliasing -fthread-jumps -ftrapping-math
# -ftree-ccp -ftree-copy-prop -ftree-copyrename -ftree-dce
# -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im
# -ftree-loop-ivcanon -ftree-loop-optimize -ftree-lrs -ftree-salias
# -ftree-sink -ftree-sra -ftree-store-ccp -ftree-store-copy-prop -ftree-ter
# -ftree-vect-loop-version -ftree-vrp -funit-at-a-time -fverbose-asm
# -fzero-initialized-in-bss -m32 -m80387 -m96bit-long-double
# -malign-stringops -mfancy-math-387 -mfp-ret-in-387 -mieee-fp
# -mno-red-zone -mpush-args -mtls-direct-seg-refs

# Compiler executable checksum: b39e0195e7cdfc211bb5a7d4c9f1eb60

        .text
.globl nbinch
        .type   nbinch, @function
nbinch:
        movzwl  4(%esp), %eax   # Hsize_cm, Hsize_cm
        leal    (%eax,%eax,2), %eax     #, tmp63
        movl    $4, %edx        #, tmp67
        movl    %edx, %ecx      # tmp67,
        cltd
        idivl   %ecx    #
        addl    $2, %eax        #, tmp68
        movl    $3, %edx        #, tmp72
        movl    %edx, %ecx      # tmp72,
        cltd
        idivl   %ecx    #
        movzwl  %ax, %eax       # tmp70, tmp61
        ret
        .size   nbinch, .-nbinch
        .ident  "GCC: (GNU) 4.1.1 20060517 (prerelease)"
        .section        .note.GNU-stack,"",@progbits

  The extra options "-fomit-frame-pointer -fverbose-asm -march=i386" are just 
there to
 simplify the output; the temporary variables tmp67 and tmp72 are created even 
without,
 and the %edx register is only used once to initialise the %ecx register.
 The %edx register is cleared by "cltd" instruction because "%eax" is positive.

 Is there any reason why:
        movl    $4, %edx        #, tmp67
        movl    %edx, %ecx      # tmp67,
 is not replaced by:
        movl    $4, %ecx

 and:
        movl    $3, %edx        #, tmp72
        movl    %edx, %ecx      # tmp72,
 is not replaced by:
        movl    $3, %ecx

  Etienne.


        

        
                
___________________________________________________________________________ 
Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son 
interface révolutionnaire.
http://fr.mail.yahoo.com

Reply via email to