|
From: Julian S. <js...@ac...> - 2012-02-23 09:14:44
|
On Wednesday, February 22, 2012, Patrick J. LoPresti wrote: > On Wed, Feb 22, 2012 at 3:52 AM, Julian Seward <js...@ac...> wrote: > >> > * if a helper "returns" a V128, then it will be given an pointer to it > >> > as the first arg, and it must park the result there > >> > > >> > * if a helper takes a V128 arg, then it gets a pointer to it in the > >> > relevant arg position. But this is a readonly arg; writes to it > >> > will be ignored. (IOW we can't use the standard C scheme of > >> > getting a pointer to something which the routine both reads and > >> > writes) > > By the way, for the helpers I need, passing a V128 is not needed, > because addresses are still "only" 64 bits. > > So if and when I do take a crack at this, I will most likely implement > the return path first. Sure. Of course, you'll wind up with a temporary asymmetry between how the 128 bit load and store helpers work, until such time as the store path uses direct V128 passing. But that's no big deal. Yeah, so looks like x86_64 ELF uses rdx:rax for 128 bit integer returns, which means you could probably copy the relevant code fragments more or less directly from host_x86_isel.c (the 32 bit insn selector) for 64 bit returns, since 64 bit returns on x86 are done in edx:eax. If you see what I mean. J |