vcomp: single-threaded implementation of _vcomp_fork (try 6)
Hi, Alexandre Julliard wrote:
+void WINAPIV _vcomp_fork(BOOL ifval, int nargs, void *wrapper, ...) + __ms_va_list valist;
it's ugly to use varargs only as a hack to get a pointer to the first argument.
Would taking the address of &wrapper (as in asm("...","r=&wrapper") or any C code like "void* stack = &wrapper") suffice to tell the x64 compiler to save register parameters into their allocated stack locations? My belief was that this is specifically the magic performed when the compiler sees a [__ms_]va_list. You seem to imply that va_list is superfluous and that taking the address of any parameter (not necessarily &wrapper but &ifval or &nargs too) would achieve the same effect: all 4 registers rcx, rdx, r8 and r9 get saved to the stack such that the & abstraction works even when the user performs pointer arithmetic. This is the effect that Dan Kegel needs for vcomp. In such a case he would use &wrapper, bypass va_list and correct the stack-relative offsets in the x86 and x64 assembly code by one pointer unit. Regards, Jörg Höhle
On Wed, Oct 24, 2012 at 3:26 AM, <Joerg-Cyril.Hoehle(a)t-systems.com> wrote:
Alexandre Julliard wrote:
+void WINAPIV _vcomp_fork(BOOL ifval, int nargs, void *wrapper, ...) + __ms_va_list valist;
it's ugly to use varargs only as a hack to get a pointer to the first argument.
Would taking the address of &wrapper (as in asm("...","r=&wrapper") or any C code like "void* stack = &wrapper") suffice to tell the x64 compiler to save register parameters into their allocated stack locations?
My belief was that this is specifically the magic performed when the compiler sees a [__ms_]va_list.
You seem to imply that va_list is superfluous and that taking the address of any parameter (not necessarily &wrapper but &ifval or &nargs too) would achieve the same effect: all 4 registers rcx, rdx, r8 and r9 get saved to the stack such that the & abstraction works even when the user performs pointer arithmetic.
I don't think he's saying that. It suffices that taking the address of the fourth parameter saves it to the stack. We are lucky in this case that there are already three non-varargs parameter, so after taking the address of the fourth parameter, all the varargs params are in memory. It all just happens to work (at least on ia32 and x64).
In such a case he would use &wrapper, bypass va_list and correct the stack-relative offsets in the x86 and x64 assembly code by one pointer unit.
I don't think it's that complicated. Here's a draft that does what Alexandre suggests. It seems fine to me and to Daniel Lehman, and I was about to submit it when I got Jörg's reply. - Dan
Dan Kegel <dank(a)kegel.com> writes:
I don't think he's saying that. It suffices that taking the address of the fourth parameter saves it to the stack. We are lucky in this case that there are already three non-varargs parameter, so after taking the address of the fourth parameter, all the varargs params are in memory. It all just happens to work (at least on ia32 and x64).
What I'm actually saying is that you should stop playing games with the compiler and implement this in assembler, it's really not hard. -- Alexandre Julliard julliard(a)winehq.org
participants (3)
-
Alexandre Julliard -
Dan Kegel -
Joerg-Cyril.Hoehle＠t-systems.com