Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] [ANN] The Missing Library
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Marcin 'Qrczak' Kowalczyk <qrczak@k...>
Subject: Re: [Caml-list] Re: Tail-calls in C code (was: [ANN] The Missing Library)
W li¶cie z pon, 03-05-2004, godz. 13:32 +0200, Wolfgang Lux napisa³:

>    Compiling logic programs to {C} using {GNU C} as a portable assembler,

> as long as you do not want to compile position independent code.

So it's not that portable :-)

Well, I'm worried about violating GCC rules so badly, when jumping to
a label from a different function. What if the functions have different
stack frame sizes?

Are you sure it works e.g. when one function uses a variable length
array, and thus uses %ebp even though -fomit-frame-pointer is in effect
and other functions don't use %ebp? Who is responsible for adjusting
%esp along the jumps?

What if one function has put callee-saved registers on the stack and
happily uses them for local variables, where the other doesn't, and
jumping from the second function to the first and back clobbers %ebx
which is not properly restored later?

Anyway, my scheme in theory works with -fPIC but it generates horrible
code, on x86 at least. The pointer to global variables is computed in
each function separately, and since virtual registers are in global
variables... Normal C functions don't use so many globals so -fPIC
doesn't hurt them that much.

I guess that normal C code doesn't have to recompute the pointer to
globals in all cases when jumping between static functions. But gcc
doesn't know that the address of the function being taken will not be
really returned but will be the target of a jump, so it must prepare
the code to be called from unexpected places.

-- 
   __("<         Marcin Kowalczyk
   \__/       qrczak@knm.org.pl
    ^^     http://qrnik.knm.org.pl/~qrczak/


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners