gcl-devel
[Top][All Lists]
Advanced

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

[Gcl-devel] Re: ia64


From: Richard E. Harke
Subject: [Gcl-devel] Re: ia64
Date: Tue, 16 Nov 2010 01:11:48 -0800
User-agent: KMail/1.9.9

ia64 hardware renames registers after a subroutine call.
(registers 0-31 do not get renamed) The alloc
instruction specifies how many registers to protect. The first
one past that number will be renamed r32 after the next call.
In this case r33 is saving some status related to renaming,
r34 is saving the stack pointer, r32 is saving the return address
and r35 is saving the global pointer which resides in r1
The called routine will have its own global pointer. This isn't necessarily
the case but is determined by the compiler depending on
whether the target of the call is in the same compilation unit or not.
It appears that r36 is being used to pass a parameter which will appear
in the called routine as r32
The field in the addl that is being relocated is just 22 bits and he field in
the call is just 21 bits. But note that the call will go to a stub that will
reload the gp register before calling the "real" address.
I believe that both of these relocs would be resolved in the linker
as they do not appear in the dlopen code.
Also modifying a field in an instruction is a very messy business
on ia64. The field to be modified is never on a byte boundary and
sometimes is split into discontiguous parts.

Richard

On Monday 15 November 2010 10:49:38 am you wrote:

> Now a question or two of my own:
>
> In the code:
>
> 0000000000000000 <init_code>:
>    0: 00 08 15 08 80 05       [MII]       alloc r33=ar.pfs,5,4,0
>    6: 20 02 30 00 42 00                   mov r34=r12
>    c: 04 00 c4 00                         mov r32=b0
>   10: 02 18 01 02 00 21       [MII]       mov r35=r1
>                       11: GPREL22     .sdata
>   16: e0 00 04 00 48 80                   addl r14=0,r1;;
>   1c: 04 70 00 84                         mov r36=r14
>   20: 10 00 00 00 01 00       [MIB]       nop.m 0x0
>                       22: PCREL21B    do_init
>   26: 00 00 00 02 00 00                   nop.i 0x0
>   2c: 08 00 00 50                         br.call.sptk.many b0=20
> <init_code+0x20>
>
> I take it r35 is always set to (presumably) the top of the function.
> Are there really only 22/21 bits of relative addressing space from
> this point to both do_init and .sdata?  On other machines with gp
> pointers, one can set the value to a nearby location at function
> beginning.
>
> Take care,
>
> > Richard Harke



reply via email to

[Prev in Thread] Current Thread [Next in Thread]