Before I start I'd like to point out that vm_x86_64.c is no longer compiled per default, instead vm_x86.c is used, which now fully supports x86_64 machines.
On Monday, 27. June 2011 17:37:03 Ben Noordhuis wrote: > 1. q3asm emits ENTER and LEAVE operations that respectively reserve > and free 8 + currentLocals + currentArgs bytes. Why the extra 8 bytes? > A seemingly obvious optimization is to skip the function prolog/epilog > for functions that don't have locals and don't call other functions - > but that won't happen now because the bytecode never contains ENTER 0 > or LEAVE 0 opcodes. Sorry, I have no idea. > 2. The JIT emits "callq *%rax" instructions, where %rax contains a > value from a lookup table. I suspect that's because it doesn't know > the address of the target yet? Yeah > 3. %rsi, %rdi and %r8 to %r10 are consistently saved across function > calls. Just to be sure, these are "caller saves" right? IOW, the > callee is free to clobber them? Calling conventions differ from OS to OS and arch to arch. As you'll notice, all clobbered registers are entered in the inline asm section, so the C- compiler knows what to do and automatically chooses which registers are saved, based on the calling convention of the compiler. On the other hand, when calling code outside of the VM the important registers are pushed to stack no matter what calling convention is being used so it should work on all systems. > 4. How are arguments passed in and results returned? Most of it takes > place on the stack, it seems, but the exact calling convention isn't > entirely clear to me. Program stack, to be exact. I don't know about the exact calling convention either. Look at the code :) > 4. x86_64 has an abundance of registers compared to x86 - so why does > the JIT use so few? For example, passing more arguments in registers > would appreciably speed up function calls. Is it because it doesn't > play nice with the bytecode's stack-based nature? It would require alot of effort to translate these VM function call arguments into registers and make it work right, for questionable speed improvements. It's not worth it. > Calling convention is the common thread here, it seems. If someone can > enlighten me, I would much appreciate it. Yes, however, I tried to make the calls into and out of VMs as independent from calling conventions as possible, at least in vm_x86.c. vm_x86_64.c only supports the cdecl calling conventions, which makes it more difficult to port this to other platforms or compilers than gcc. -- Thilo Schulz
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ ioquake3 mailing list ioquake3@lists.ioquake.org http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org By sending this message I agree to love ioquake3 and libsdl.
