On Feb 9 2007 15:29, linux-os (Dick Johnson) wrote:
>>
>> I was referring to "absolute memory", not the offset magic that assembler
>> allows. After all, (reg+relativeOffset) will yield an absolute address.
>> What I was out at: for machines that have more than 2 GB of memory, you
>> don't call the address that is given by 0x80000000U actually "byte
>> -2147483648", but "byte 2147483648".
>
>Don't make any large bets on that!
>
>char foo()
>{
>    volatile char *p = (char *)0x80000000;
>    return *p;
>}
>Optimized....
>       .file   "zzz.c"
>       .text
>       .p2align 2,,3
>.globl foo
>       .type   foo, @function
>foo:
>       pushl   %ebp
>       movb    -2147483648, %al
>       movl    %esp, %ebp
>       movsbl  %al,%eax
>       leave
>       ret
>       .size   foo, .-foo
>       .section        .note.GNU-stack,"",@progbits
>       .ident  "GCC: (GNU) 3.3.3 20040412 (Red Hat Linux 3.3.3-7)"

00000000 <foo>:
   0:   55                      push   %ebp
   1:   0f b6 05 00 00 00 80    movzbl 0x80000000,%eax
   8:   89 e5                   mov    %esp,%ebp
   a:   5d                      pop    %ebp
   b:   0f be c0                movsbl %al,%eax
   e:   c3                      ret    

You do know that there is a bijection between the set of signed [32bit] 
integers and unsigned [32bit] integers, don't you?
For the CPU, it's just bits. Being signed or unsigned is not important 
when just accessing memory. It will, when a comparison is involved, but 
that was not the point here. void* comparisons are unsigned. Period.
Because a compiler doing signed comparisons will "map" the memory [from 
2 GB to 4 GB] as part of the signed comparison before the memory [from 0 
GB to 2 GB], which collides with - let's call it - "the world view".


Jan
-- 
ft: http://freshmeat.net/p/chaostables/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Reply via email to