Hello Simon and Ian,
I'm trying to answer my own questions. After looking around I found
that StgRun() is used in RtsStartup.c and Schedule.c so it is pretty
clear that StgRun() needs to be implemented in a separate assembler
module (i.e., no inline asm). I would rather use NASM but if you
want (please ask if you do!) I will implement it in AT&T (GAS
syntax)--that way we might even be able to use it for, say, x86-apple-
darwin and future-proof the stack-pointer alignment problem. So I
have a few questions you might (hopefully) have an answer to--and
save me a lot of time and experimentation. Here is the MASM because
it is a lot clearer here than the gnu stuff:
__asm {
/*
* save callee-saves registers on behalf of the STG code.
*/
mov eax, esp
/* may need: + __LOCAL_SIZE */
add eax, RESERVED_C_STACK_BYTES
mov [eax], ebx
mov [eax+4], esi
mov [eax+8], edi
mov [eax+12], ebp
/*
* Set BaseReg
*/
mov ebx, basereg
/*
* grab the function argument from the stack
*/
mov eax, f
/*
* jump to it -- no delimiter for absolute (not PC-relative) address
* in Intel syntax
*/
jmp [eax]
/* STG_GLOBAL STG_RETURN can't specify with CL inline assembler
* because only recognised directives are EVEN and ALIGN.
*/
STG_RETURN:
/* R1 == esi, see MachRegs.h */
mov eax, esi
mov edx, esp
add edx, RESERVED_C_STACK_BYTES
mov ebx, [edx] /* restore the registers saved above */
mov esi, [edx+4]
mov edi, [edx+8]
mov ebp, [edx+12]
}
(1) for:
add eax, RESERVED_C_STACK_BYTES
-why backtrack up the stack? Is this because gcc inserts extra stack
frames because it thinks you are popping C-stacks? (This would not
happen for CL with inline-MASM if I set StgRun with __declspec(naked)
or if I wrote the assembler explicitly.) If so, how much space does
gcc add; is it implementation-dependant or does it follow the
architecture ABI rules, padding gcc adds to the prologue?
RESERVED_C_STACK_BYTES is hard-coded as:
includes/Constants.h:101:#define RESERVED_C_STACK_BYTES (2048 *
SIZEOF_LONG)
that seems very large.
Thanks
Pete
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
