I had put a __attribute__ ((sysv_abi)) on the declaration of callAsmCall and only then (plus on the declarations of the few other functions called in the assembly), and only then it was able to run and get into the game with only 3D rendering being completely distorted (basically you can see almost nothing (mainly 'ghosts' of graphics and that only if you move around)) though 2D, gameplay, audio, mostly anything else seeming right.
Do you mean it may still need rearrangement of registers' data (for function calls)? As I think of it now, sysv_abi attribute 'tells' callAsmCall the registers data assembly inputs to it are in the 'right' order (sysv) and when it goes out of the call, assembly gets them 'right' again. 2010/2/19 Matthias Bentrup <[email protected]>: > I don't think that the printf function prints numbers differently on Linux > and Windows. The different masks depend on the size of the memory allocated > for the QVM, so maybe this is just allocated a bit different between the > Windows and Linux systems. > > I think the call from C code to QVM is ok, as the arguments are moved into > the right registers for the QVM via inline assembly, but the call from QVM > to C-code (syscalls) moves the arguments to %rdi and %rsi and then jumps to > the C-Function CallAsmCall. In the linux ABI the first two integer arguments > of the function are passed in %rdi and %rsi, but in the Win64 ABI the first > arguments are expected in %rcx and %rdx, so maybe you have to insert movq > %rdi,%rcx; movq %rsi,%rdx before the call. > > 2010/2/18 Michael Menegakis <[email protected]> >> >> 2010/2/15 Michael Menegakis <[email protected]>: >> > The bins appear to be different; I've uploaded them here: >> > http://www0.org/vm/bins.tar.bz2 >> >> I've put a fputs in emit() and I see some differences. >> >> // >> andl $0x1fffffc, %ecx on linux, >> >> andl $0xffffc, %ecx on windows >> >> when referring to emit("andl $0x%x, %%ecx", vm->dataMask &~(bytes-1)); >> // >> >> (callq's pointer is normally different) >> >> this portion is different: >> >> // >> linux: >> addq $4, %rsi >> movl $1004, 0(%rsi) >> subq $4, %rsi >> >> windows: >> addq $4, %rsi >> movl $4, 0(%rsi) >> subq $4, %rsi >> >> when referring to emit("movl $%d, 0(%%rsi)", const_value); >> // >> >> //again >> linux >> addq $4, %rsi >> movl $6, 0(%rsi) >> addl $28, %edi >> windows >> addq $4, %rsi >> movl $4, 0(%rsi) >> addl $28, %edi >> ret >> // >> >> shortly after than there's deviation from the flow itself >> >> //linux >> ret >> movq $0, %rax >> jmpq *%rax >> movl %edi, %ebx >> addl $40,%ebx >> addq $4, %rsi >> movl %ebx, 0(%rsi) >> movl 0(%rsi), %eax >> movl %eax, %ecx >> andl $0x1fffffc, %ecx >> cmpl %eax, %ecx >> //-linux >> //windows >> ret >> movq $0, %rax >> jmpq *%rax >> movl %edi, %ecx >> andl $0xffffc, %ecx >> cmpl %edi, %ecx >> jz rc_ok_i_0000001a >> movq $5381734, %rax >> callq *%rax >> rc_ok_i_0000001a: >> movl $27, 0(%r8, %rdi, 1) >> movq $0, %rax >> callq *%rax >> //-windows >> >> etc. >> >> I suspect printf being inconsistent, or at least i hope it's that simple. >> >> Assembly code in its core *seems* to be compatible, registers are >> probably not violated provided one assumes the whole thing emulates >> sysv abi though not sure either. _______________________________________________ ioquake3 mailing list [email protected] http://lists.ioquake.org/listinfo.cgi/ioquake3-ioquake.org By sending this message I agree to love ioquake3 and libsdl.
