RE: [PATCHSET][2.6-test4][0/6]Support for HPET based timer - Take 2

[Pallipadi, Venkatesh]

> -----Original Message-----
> From: George Anzinger [mailto:george@xxxxxxxxxx]
> 
> Pallipadi, Venkatesh wrote:
> > 
> > 
> >>-----Original Message-----
> >>From: Andrew Morton [mailto:akpm@xxxxxxxx] 
> >>
> >>We seem to keep on proliferating home-grown x86 64-bit math 
> functions.
> >>
> >>Do you really need these?  Is it possible to use do_div() and 
> >>the C 64x64
> >>`*' operator instead?
> >>
> > 
> > 
> > 
> > We can change these handcoded 64 bit divs to do_div, with just an
> > additional data copy 
> 
> We already have this in .../include/asm-i386/div64.h.  Check usage in 
> .../posix-timers.c to cover archs that have not yet included it in 
> there div64.h.
>


Yes. We can surely use div_long_long_rem from div64 in place of defining 
this again. This kind of code is already there in the existing ia32 timer
code too. I will try and come up with a cleanup patch to replace all 
these individual asm div statements.


> > (as do_div changes dividend in place). But, changing mul 
> into 64x64 '*'
> > may be tricky. 
> > Gcc seem to generate a combination of mul, 2imul and add, 
> where as we
> > are happy with 
> > using only one mull here.
> 
> You just need to do the right casting.  It should like 
> u64=u32*(u64)u32  as in .../kernel/posix-timers.c.  This 
> could also be 
> signed with the same results.  If you really need to do a u64*u32, it 
> will do that as well but takes two mpys.  In this case you will need 
> to do it unsigned to eliminate the third mpy.


Interesting. Is this casting to generate proper mul instruction
some sort of C standard or is it a gcc feature. I just want to
make sure doing this way won't break on some other compiler 
(or on some other version of gcc itself).


Thanks,
-Venkatesh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/