RE: [PATCHSET][2.6-test4][0/6]Support for HPET based timer - Take 2
From: Pallipadi, Venkatesh
Date: Sat Sep 06 2003 - 14:06:25 EST
> -----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/