Re: x86 inline assembly, position independent code, and globals access
Re: x86 inline assembly, position independent code, and globals access
- Subject: Re: x86 inline assembly, position independent code, and globals access
- From: Greg Guerin <email@hidden>
- Date: Thu, 26 Apr 2007 19:21:02 -0700
Chall Fry wrote:
>I am porting some windows code to the mac; it is a bunch of Visual C+
>+ code that is now being built into a Quicktime component. The
>windows sources make liberal use of Visual Studio style inline
>assembly, which I would like to take advantage of for the x86 build
>(we're building a universal component). However, the code has many
>constructs which look somewhat like this:
>
>static long long g_Some_MMX_Global = 0x8080808080808080LL;
>
>void SomeFunctionMMX(void)
>{
> asm {
> movq mm0, g_Some_MMX_Global
> ...
> }
>}
>
>--Except, imagine 40-50 such global constants per file, and 40-50
>functions that use them.
And imagine no PC-relative addressing mode...
OK, now that I've scared myself silly, here's a trick I used to use with
other CPUs that also lacked PC-relative addressing modes.
Basically, you arrange the constants with some code around them that uses
the call stack to push an address and pop it into a register. I'm using
pseudo-code, because I don't remember much from my 8080 and Z-80
programming days, and those were the last CPUs I had to write assembler for
that were even close to x86-ish.
global_constants:
call epilog
.dc 0x8080808080808080LL
.dc ...more constants in code-section...
epilog:
pop bx .. i.e. pop return-address from 'call epilog' into a pointer reg
ret
The 'epilog' fragment can be anywhere (even before 'global_constants'). It
doesn't have to follow the constants.
Then to get the address of the constant-table into bx:
call global_constants
..more code here..
You can then refer to individual constants as offsets from bx.
BTW, if it isn't clear from the pseudo-code, it's absolutely critical that
the constants are in the CODE section, and IMMEDIATELY following the 'call
epilog' instruction. If you were burning the whole thing into a ROM, I'd
say "in ROM space, not RAM space". I don't know what the asm op is for
that, but all assemblers have them, so it's just a question of finding it
in the manual.
Also, if the return-address on the stack needs any adjustment to point
directly to the first constant, put that after the pop and before the ret.
In particular, I'm thinking of in-memory operand alignment, which may or
may not be relevant to MMX or x86. I have no idea, so I'm only mentioning
it for completeness.
This should work for x86, because it has PC-relative calls (near and short
jumps, in the Wikipedia article I looked up), just not PC-relative anything
else.
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden