I've pin-pointed a distinct difference in compilation (using x86_64_assembler in standalone with same input.s and printing to a file opcodes and the line they correspond to).
When the assembler sees "-4(%rsi), %ebx on linux, it does: 8B 9E FC FF FF FF when it sees it on windows, it does: 8B 5E FC it appears to be related to the negative sign; if it's positive they emit the same. 2010/2/20 Michael Menegakis <[email protected]>: > 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.
