Re: [Sablevm-developer] Porting SableVM to ARM: Questions

[Gunda D. <sab...@ho...>]

Archie,

You are right. Dang, don't know how I missed that ! So the test for 
inlineability is more constrained for ARM. I will look at the m4 file again.

Later,
-Gunda


>From: Archie Cobbs <ar...@de...>
>To: Gunda Domlur <sab...@ho...>
>CC: eg...@j-..., ma...@kl..., 
>sab...@li...
>Subject: Re: [Sablevm-developer] Porting SableVM to ARM: Questions
>Date: Fri, 3 Jan 2003 09:33:52 -0800 (PST)
>
>Gunda Domlur wrote:
> > Now I am back after the holidays to look at the problem of making the
> > inlined version working on ARM.
>
>I happen to have been working with ARM assembly lately, on an
>unrelated project. One thing that may present difficulties for
>SableVM inline threading is the way that immediate values are
>handled.
>
>The ARM instruction set does not allow loading of arbitrary
>immediate values; to typically such values are stored in a
>'literals' pool at the end of whatever function, etc. you are
>assembling or compiling, and then they are loaded using a
>PC-relative instruction.
>
>This means that if you move the code, but don't move the
>literals, it won't work. Moreover, it's hard to predict when
>the compiler is going to do this, because some constants
>can be loaded as immediate values (specifically, those that
>can be represented as an 8-bit value shifted an even number
>of bits, or the ones complement of such a value).
>
>Here's an example. Consider this C code:
>
>	extern int x;
>	extern int y;
>	void
>	foo()
>	{
>		x = 0xff000000;	/* can be loaded as immediate */
>		y = 0x12345678;	/* cannot be loaded as immediate */
>	}
>
>Here's what GCC outputs:
>
>		.file   "foo.c"
>		.text
>		.align  2
>		.global foo
>		.type   foo,function
>	foo:
>		@ args = 0, pretend = 0, frame = 0
>		@ frame_needed = 0, uses_anonymous_args = 0
>		@ link register save eliminated.
>		ldr     r3, .L2
>		mov     r2, #-16777216
>		ldr     r1, .L2+4
>		str     r2, [r3, #0]
>		ldr     r3, .L2+8
>		@ lr needed for prologue
>		str     r1, [r3, #0]
>		bx      lr
>	.L3:
>		.align  2
>	.L2:
>		.word   x
>		.word   305419896
>		.word   y
>	.Lfe1:
>		.size   foo,.Lfe1-foo
>		.ident  "GCC: (GNU) 3.2"
>
>
>Note that the 0x12345678 (305419896) constant is stored in the literal
>pool (starting at .L2) but the 0xff000000 (-16777216) constant is not.
>The latter is 'relocatable' but the former is not.
>
>So this is going to be tricky to predict which instructions are
>inlinable; it also depends on how the compiler compiles code.
>
>-Archie
>
>__________________________________________________________________________
>Archie Cobbs     *     Packet Design     *     http://www.packetdesign.com


_________________________________________________________________
Help STOP SPAM: Try the new MSN 8 and get 2 months FREE* 
http://join.msn.com/?page=features/junkmail