[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Good documentation on c/c++ pointers? -- hardcore stuff ...



On Tue, 2004-12-07 at 23:44, Bryan J. Smith wrote:
>   ...
> [ NOTE:  Hard core guys -- this is a mega-oversimplification, I know. 
> But don't bombard this guy just yet, okay? ;-]
>   ...
>   printf("%d\n",pA)   // prints address (e.g., 0023:31A23C51)
>   [ NOTE:  this last command might require "(void *)&pA" to avoid
>     syntax errors -- long story]

First off, I had a bug:  
  printf("%p\n",pA) <- should be %p, not %d

Secondly ...

> To the C compiler, an address is an address.  In x86, both standard
> 32-bit/4GB and even PAE36/64MB (4-bit overhang) programming, 48-bit
> segmented (16:32) addresses (virtually 256TB) are used.  It doesn't
> matter if we are pointing at a char, integer, float, long, etc...  An
> address is what we are actually storing in the variable location.
> 
> -- Bryan
> 
> BTW, in case you are curious, for x86-64 "Long" mode programming, we use
> PAE52 partially segmented (4-bit overhang), even though it's only
> 48-bit.  The 48-bit is for compatibility with the i386 segmentation
> 16:32, which is implemented with support for the i486+ TLB (translation
> lookahead buffer) with a massive compile-time improvement (hence why
> most programs today are built "march=i486").  At the same time,
> PAE36/64GB expects a "4-bit overhang" (long story, but it has to do with
> how the last 12 bits of the 16 portion of 16:32 map into the 32 portion,
> leaving 4 bits overhang -- hence how Intel gets 36-bit/64GB addressing,
> PAE36, on a 32-bit/4GB processor).  The result is PAE52 -- 52-bit
> programmer/register addressing.

And I said "no hardcore stuff"???

I said that, then went _way_off_ on x86-64.  Duh!  Sorry.

Kyle -- just _ignore_ this last stuff I wrote about 32/36/48/52-bit.


-- 
Bryan J. Smith                                 b.j.smith@ieee.org 
------------------------------------------------------------------ 
Beware of advocates who justify their preference not in terms of
what they like about their "choice," but what they did not like
about another option.  Such advocacy is more hurtful than helpful.



-
To unsubscribe, send email to majordomo@silug.org with
"unsubscribe silug-discuss" in the body.