[Pythonmac-SIG] CFM vs mach-o

[Doug Landauer]

--Apple-Mail-1-593249237
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	format=flowed;
	charset=us-ascii

>> I think the differences have more to do with CFM's assumptions about
>> RTOC, which comes into play with UPP's etc ...

Here's a two-cent summary "for the rest of us", as far
as I understand it:

Filters between the object and executable file formats
wouldn't be that difficult; the main intractable difference
is that the models that these two worlds use in order to make
code position-independent are too different:  the compilers
generate quite different code to access any static data.

In mach-o, code is made position-independent by setting up
a "PIC base" register, near the start of any function.  (This
is done via a call to the next instruction, in effect loading
a register with a known address that's near the start of the
function.)  Then, any static "nearby" data referenced by this
function is referenced relative to the PIC base, and the code
and data for the function sorta stay together.  Weird glue is
generated for references to data that lives farther away (extern
stuff, outside of this object file).

In CFM, there is no PIC base.  Instead, any static data is referenced
through a "table-of-contents" (TOC).  In this model, compilers will
generate a "reload-the-TOC-register" after any external call, since
any such call might be to a code fragment that uses a different TOC.
The linker can often optimize those reloads by replacing them with
NO-OPs.

   -- Approximately,
   -- Doug L.



--Apple-Mail-1-593249237
Content-Transfer-Encoding: 7bit
Content-Type: text/enriched;
	charset=us-ascii

<excerpt><excerpt><fixed>I think the differences have more to do with
CFM's assumptions about 

RTOC, which comes into play with UPP's etc ...

</fixed></excerpt></excerpt><fixed>

Here's a two-cent summary "for the rest of us", as far

as I understand it:<color><param>0000,63D6,124D</param>

</color>

Filters between the object and executable file formats

wouldn't be that difficult; the main intractable difference

is that the models that these two worlds use in order to make

code position-independent are too different:  the compilers

generate quite different code to access any static data.


In mach-o, code is made position-independent by setting up

a "PIC base" register, near the start of any function.  (This

is done via a call to the next instruction, in effect loading

a register with a known address that's near the start of the

function.)  Then, any static "nearby" data referenced by this

function is referenced relative to the PIC base, and the code

and data for the function sorta stay together.  Weird glue is

generated for references to data that lives farther away (extern

stuff, outside of this object file).


In CFM, there is no PIC base.  Instead, any static data is referenced

through a "table-of-contents" (TOC).  In this model, compilers will

generate a "reload-the-TOC-register" after any external call, since

any such call might be to a code fragment that uses a different TOC.

The linker can often optimize those reloads by replacing them with

NO-OPs.


  -- Approximately,

  -- Doug L.



</fixed>
--Apple-Mail-1-593249237--