lkml.org 
[lkml]   [2013]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectThe type of bitops
The type of bitops is currently "int" on most, if not all, architectures
except sparc64 where it is "unsigned long". This already has the
potential of causing failures on extremely large non-NUMA x86 boxes
(specifically if any one node contains more than 8 TiB of memory, e.g.
in an interleaved memory system.)

x86 has hardware bitmask instructions which are signed, this limits the
types to either "int" or "long".

It seems pretty clear to me at least that x86-64 really should use
"long". However, before blindly making that change I wanted to feel
people out for what this should look like across architectures.

Moving this forward, I see a couple of possibilities:

1. We simply change the type to "long" on x86, and let this be a fully
architecture-specific option. This is easy, obviously.

2. Same as above, except we also define a typedef for whatever type is
the bitops argument type (bitops_t? bitpos_t?)

3. Change the type to "long" Linux-wide, on the logic that it should be
the same as the general machine width across all platforms.

4. Do some macro hacks so the bitops are dependent on the size of the
argument.

5. Introduce _long versions of the bitops.

6. Do nothing at all.


Are there any 64-bit architectures where a 64-bit argument would be very
costly?

-hpa


\
 
 \ /
  Last update: 2013-05-07 03:21    [W:0.043 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site