On Mon, Feb 2, 2015 at 3:45 PM, Yury Norov wrote:
> Alexey,
>
> Yes, ARM has it's own implementation for subj. If you're interested in
> testing
> my patch on your odroid, try this. (Sorry, I have to attach the patch due to
> restrictions on mail agent at office).
Hi Yury,
(please don't drop peo
On Wed, Feb 04 2015, Yury wrote:
> On 02.02.2015 13:43, Rasmus Villemoes wrote:
>>> @@ -23,86 +50,22 @@
>>> unsigned long find_next_bit(const unsigned long *addr, unsigned long size,
>>> unsigned long offset)
>>> {
>>> - const unsigned long *p = addr + BITOP_WORD(offse
On Thu, Feb 05 2015, Yury wrote:
> On 02.02.2015 15:56, Rasmus Villemoes wrote:
>> On Mon, Feb 02 2015, "George Spelvin" wrote:
>>
>>> Rasmus Villemoes wrote:
... and this be part of _find_next_bit? Can find_next_bit not be simply
'return _find_next_bit(addr, size, offset, 1);', and s
On 02.02.2015 15:56, Rasmus Villemoes wrote:
> On Mon, Feb 02 2015, "George Spelvin" wrote:
>
>> Rasmus Villemoes wrote:
>>> ... and this be part of _find_next_bit? Can find_next_bit not be simply
>>> 'return _find_next_bit(addr, size, offset, 1);', and similarly for
>>> find_next_zero_bit? Btw.
On 02.02.2015 06:17, George Spelvin wrote:
> Yury Norov wrote:
>> New implementations takes less space in source file (see diffstat)
>> and in object. For me it's 710 vs 453 bytes of text.
>>
>> Patch was boot-tested on x86_64 and MIPS (big-endian) machines.
>> Performance tests were ran on users
On 02.02.2015 13:43, Rasmus Villemoes wrote:
> On Sat, Jan 31 2015, yury.no...@gmail.com wrote:
>
>> From: Yury Norov
>>
>> New implementations takes less space in source file (see diffstat)
>> and in object. For me it's 710 vs 453 bytes of text.
>>
> New version generally looks good. Please incl
On Mon, Feb 02 2015, "George Spelvin" wrote:
> Rasmus Villemoes wrote:
>> ... and this be part of _find_next_bit? Can find_next_bit not be simply
>> 'return _find_next_bit(addr, size, offset, 1);', and similarly for
>> find_next_zero_bit? Btw., passing true and false for the boolean
>> parameter
Rasmus Villemoes wrote:
> ... and this be part of _find_next_bit? Can find_next_bit not be simply
> 'return _find_next_bit(addr, size, offset, 1);', and similarly for
> find_next_zero_bit? Btw., passing true and false for the boolean
> parameter may be a little clearer.
Looking at the generated c
On Sat, Jan 31 2015, yury.no...@gmail.com wrote:
> From: Yury Norov
>
> New implementations takes less space in source file (see diffstat)
> and in object. For me it's 710 vs 453 bytes of text.
>
New version generally looks good. Please include a summary of the
changes between the versions eithe
Yury Norov wrote:
> New implementations takes less space in source file (see diffstat)
> and in object. For me it's 710 vs 453 bytes of text.
>
> Patch was boot-tested on x86_64 and MIPS (big-endian) machines.
> Performance tests were ran on userspace with code like this:
>
> /* addr[] is
From: Yury Norov
New implementations takes less space in source file (see diffstat)
and in object. For me it's 710 vs 453 bytes of text.
Patch was boot-tested on x86_64 and MIPS (big-endian) machines.
Performance tests were ran on userspace with code like this:
/* addr[] is filled from
11 matches
Mail list logo
