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

[Dan Kegel]

On Wed, Oct 24, 2012 at 3:26 AM,   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

[Alexandre Julliard]

Dan Kegel  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.

[Dan Kegel]

On Wed, Oct 24, 2012 at 5:38 AM, Alexandre Julliard  wrote:
> What I'm actually saying is that you should stop playing games with the
> compiler and implement this in assembler...

Thanks for the cleartext.