On Sat, 2007-07-21 at 14:27 -0700, David Schwartz wrote:
> > On 7/21/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> > > v & 0x0F <=> v % 16
> > Indeed. (Why would anyone want to mod/div by 15 anyway?). My bad.
>
> Actually, it's the compiler's bad. That's a pretty fundamental equivalence
>
> On 7/21/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> > v & 0x0F <=> v % 16
> Indeed. (Why would anyone want to mod/div by 15 anyway?). My bad.
Actually, it's the compiler's bad. That's a pretty fundamental equivalence that
the compiler should recognize for native integral types.
DS
-
On Sat, 2007-07-21 at 21:58 +0200, Jan-Benedict Glaw wrote:
> On Sat, 2007-07-21 21:31:13 +0200, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > On Sat, 2007-07-21 at 15:21 -0400, Robert P. J. Day wrote:
> >
> > use do_div().
> >
> > 16 works because gcc translates that into a right shift.
>
>
On 7/21/07, Jan Engelhardt <[EMAIL PROTECTED]> wrote:
v & 0x0F <=> v % 16
Indeed. (Why would anyone want to mod/div by 15 anyway?). My bad.
Regards,
--
Alex
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
On Sat, 2007-07-21 21:31:13 +0200, Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> On Sat, 2007-07-21 at 15:21 -0400, Robert P. J. Day wrote:
>
> use do_div().
>
> 16 works because gcc translates that into a right shift.
Right shift? Doesn't it just mask out everything but the low 4 bit?
MfG, JBG
" undefined!
> >
> > and, not surprisingly, when i try to insmod:
> >
> > insmod: error inserting 'seq.ko': -1 Unknown symbol in module
> >
> > (using 16 rather than 15 works fine, as i assume that the modulus
> > call is simply replaced
On Jul 21 2007 23:33, Alexander Shishkin wrote:
> On 7/21/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
>>
>> again, probably displaying my abject ignorance, but i wrote a
>> trivial module that tries to "var % 15", and i get:
>>
>> WARNING: "__moddi3" undefined!
> ...which comes from
On 7/21/07, Robert P. J. Day <[EMAIL PROTECTED]> wrote:
again, probably displaying my abject ignorance, but i wrote a
trivial module that tries to "var % 15", and i get:
WARNING: "__moddi3" undefined!
...which comes from libgcc1 which you obviously don't want to link against.
Does (var &
insmod:
>
> insmod: error inserting 'seq.ko': -1 Unknown symbol in module
>
> (using 16 rather than 15 works fine, as i assume that the modulus
> call is simply replaced by an optimized bitwise comparison.)
>
> so ... from where comes __moddi3? i know there are place
r than 15 works fine, as i assume that the modulus
call is simply replaced by an optimized bitwise comparison.)
so ... from where comes __moddi3? i know there are places in the
kernel source tree that do non-power-of-2 moduli, and they work fine
, as i assume that the modulus
call is simply replaced by an optimized bitwise comparison.)
so ... from where comes __moddi3? i know there are places in the
kernel source tree that do non-power-of-2 moduli, and they work fine,
no? thanks.
rday
Unknown symbol in module
(using 16 rather than 15 works fine, as i assume that the modulus
call is simply replaced by an optimized bitwise comparison.)
so ... from where comes __moddi3? i know there are places in the
kernel source tree that do non-power-of-2 moduli, and they work fine
On 7/21/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
again, probably displaying my abject ignorance, but i wrote a
trivial module that tries to var % 15, and i get:
WARNING: __moddi3 undefined!
...which comes from libgcc1 which you obviously don't want to link against.
Does (var 0x0f)
On Jul 21 2007 23:33, Alexander Shishkin wrote:
On 7/21/07, Robert P. J. Day [EMAIL PROTECTED] wrote:
again, probably displaying my abject ignorance, but i wrote a
trivial module that tries to var % 15, and i get:
WARNING: __moddi3 undefined!
...which comes from libgcc1 which you
to insmod:
insmod: error inserting 'seq.ko': -1 Unknown symbol in module
(using 16 rather than 15 works fine, as i assume that the modulus
call is simply replaced by an optimized bitwise comparison.)
so ... from where comes __moddi3? i know there are places in the
kernel source tree
On Sat, 2007-07-21 21:31:13 +0200, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Sat, 2007-07-21 at 15:21 -0400, Robert P. J. Day wrote:
use do_div().
16 works because gcc translates that into a right shift.
Right shift? Doesn't it just mask out everything but the low 4 bit?
MfG, JBG
--
On 7/21/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
v 0x0F = v % 16
Indeed. (Why would anyone want to mod/div by 15 anyway?). My bad.
Regards,
--
Alex
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
On Sat, 2007-07-21 at 21:58 +0200, Jan-Benedict Glaw wrote:
On Sat, 2007-07-21 21:31:13 +0200, Peter Zijlstra [EMAIL PROTECTED] wrote:
On Sat, 2007-07-21 at 15:21 -0400, Robert P. J. Day wrote:
use do_div().
16 works because gcc translates that into a right shift.
Right shift?
On 7/21/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
v 0x0F = v % 16
Indeed. (Why would anyone want to mod/div by 15 anyway?). My bad.
Actually, it's the compiler's bad. That's a pretty fundamental equivalence that
the compiler should recognize for native integral types.
DS
-
To
On Sat, 2007-07-21 at 14:27 -0700, David Schwartz wrote:
On 7/21/07, Jan Engelhardt [EMAIL PROTECTED] wrote:
v 0x0F = v % 16
Indeed. (Why would anyone want to mod/div by 15 anyway?). My bad.
Actually, it's the compiler's bad. That's a pretty fundamental equivalence
that the compiler
20 matches
Mail list logo
