On Mon, Aug 27, 2012 at 12:02 AM, Roy Smith <r...@panix.com> wrote: > In article <503a2804$0$6574$c3e8da3$54964...@news.astraweb.com>, > Steven D'Aprano <steve+comp.lang.pyt...@pearwood.info> wrote: > >>>> The mapping of name:address is part of the *compilation* process -- >>>> the compiler knows that variable 'x' corresponds to location >>>> 12345678 > > Just to pick a nit, the compiler probably doesn't know that, but the > linker does (or maybe even the run-time loader). However, we can think > of all of those as just part of the compilation tool chain, and then > we're good.
Hrm. Back when I first started C programming, it was MS-DOS 16-bit work - segmented addressing (one of the most fascinating insanities ever to be perpetrated on unsuspecting consumers - why, oh why, if you want 20-bit addressing, should you invent a system that uses 32 bits of data in such a non-expandable way?). My program would be loaded into whatever segment the loader chose, but offsets within that could be compiled in. With modern x86 systems there are several more layers of complication, but in many cases, you can still hard-code offsets within a logical segment of memory. Set CS to your one code segment and do your jumps and calls at fixed locations. Set [DEFG]S to your single data segment and all your data can be at fixed locations too. (Obviously your stack is referenced relative to SP/BP.) I'm not familiar with other architectures, but it seems likely that there's something similar. The segment / base location may change, but variable 'x' still corresponds to 12345678 within that. Nits can be fun to pick :) ChrisA -- http://mail.python.org/mailman/listinfo/python-list
