OK, after a few bureaucratic issues with comparing the files that shouldn't exist in the first place (d'oh!), I've managed to see two very-very similar "emit.s" outputs for linux x86_64 and win.
The two files (11M on no debug) are identical in line numbers and type of registers and operations being done. The differences are - integer being printed on rax before being called - representing a pointer,normal. - number in movq $%"PRIu64", %%rbx from (uint64_t)vm->instructionPointers, - again a pointer, most probably normal. If assembly is ok it leaves - Assembler - Something else I guess 'something else' can be a lot of things. 2010/2/19 Michael Menegakis <[email protected]>: > 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.
