Bernd Petrovitsch wrote:
[...]
In C, there is no type "byte" (unless you typedef oder #define it).
"byte" is usually (but not necessarily) meant as "unsigned char".
The issue here is that sparse is helpful and converts pointer offsets
into byte offsets when generating code for pointer arithmetic. So:
const int* p = (const char*) 1234;
p += 10;
-->
set.32 %p0 <- 1234
add.32 %p1 <- %p0, 40
(In fact, in this example it'd collapse these together and use 1274
instead.)
This appears to be done using hard-coded knowledge that a byte (one unit
of addressingness) is 8 bits wide.
Chris Li wrote:
Byte need to big enough to hold the char. Using bits_in_byte is better.
There might be other place in sparse assume byte is 8 bits.
IIRC C specifies that sizeof() returns values measured in chars, but I
don't believe it specifies any mapping between the size of chars and the
underlying addressing units --- it should be possible to use 16-bit
chars, for example, on an 8-bit byte system. Using 32-bit ints,
sizeof(int) would then return 2; but you wouldn't be able to access
individual bytes from C.
That's assuming I've remembered the spec correctly, of course --- this
stuff is annoying subtle.
If you like I'll go and have a look to see if this can be easily fixed
--- I need to do it anyway. In fact, I have vague recollections that
load and store were actually using offsets like 0, 1, 2, etc (the
'right' values), which means they must have been using bits_per_char to
do their calculations; I need to check up on this.
--
David Given
dg@xxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-sparse" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
