Objects in Python

[Chris Angelico]

On Mon, Aug 27, 2012 at 12:02 AM, Roy Smith <roy at panix.com> wrote:
> In article <503a2804$0$6574$c3e8da3$5496439d at news.astraweb.com>,
>  Steven D'Aprano <steve+comp.lang.python at 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