unitsync java/python bindings kaput, r7068

[Auswaschbar]

It used to work without stdcall before, why do we need it now?

Besides that:
http://gcc.gnu.org/onlinedocs/gcc/Funct ... butes.html

stdcall
On the Intel 386, the stdcall attribute causes the compiler to assume that the called function will pop off the stack space used to pass arguments, unless it takes a variable number of arguments.

It is ignored on 64bit gcc.

[hoijui]

aha... its the 64bit, not the new gcc version...
yeah, agon also has 64 bit, makes sense. I laso found:

Microsoft dropped stdcall when 64-bit support began

we did have stdcall before, and it is needed to force a common calling convention, if we want to support different compilers binaries to work together.

but as stdcall is not supported on 64 bit anymore...
we need something else, i guess. We can not just leave it blank.
Tobi, what else should we take?
Should we keep sdtcall for 32bit and use.. cdecl for 64bit? :/

[hoijui]

looks like microsoft is using primarily fastcall (at least in 64bit), and in some environments, it is even the only options (eg in the Windows Server 2003 Driver Development Kit, whether that is important or not).
could that cause any problems on linux 64bit?

or in other words, it looks like we have to fill out the following table:

Code: Select all

          ;   32bit   ;   64bit   ;
Unix      ;   ?????   ;   ?????   ;
Windows   ;   ?????   ;   ?????   ;

a try:

Code: Select all

          ;   32bit   ;    64bit    ;
Unix      ;  stdcall  ;   fastcall   ;
Windows   ;  stdcall  ;   fastcall  ;

edit: last table Unit 64bit from stdcall to fastcall

[Auswaschbar]

we did have stdcall before, and it is needed to force a common calling convention, if we want to support different compilers binaries to work together.

Quote from source (unitsync.h) for truth:

Code: Select all

#ifdef WIN32
#  define DLL_EXPORT extern "C" __declspec(dllexport)
#  include <windows.h>
#else
#  define DLL_EXPORT extern "C" __attribute__ ((visibility("default")))
#  define __stdcall
#endif

fastcall
On the Intel 386, the fastcall attribute causes the compiler to pass the first argument (if of integral type) in the register ECX and the second argument (if of integral type) in the register EDX. Subsequent and other typed arguments are passed on the stack. The called function will pop the arguments off the stack. If the number of arguments is variable all arguments are pushed on the stack.

Besides that, you can't use libraries compiled for windows in linux, so why use the same calling conventions then?

[hoijui]

... hmm, guess on 64bit windows we maybe should leave it just blank, do not know about unix yet.

possibly we would just need a 32/64 bit switch, and not care about the OS maybe.

of course, we do not need the same calling convention on windows like on linux, but we need the same calling convention on windows whether we use VS, MinGW or intel, and the same on unix whether we use GCC or intel (or others).
I do not know how important that is for unitsync, but i gues it should also be fixed there. it definatly matters for the C AI interface.

[Tobi]

On Linux we have always used the default (cdecl), I don't think Linux stacks know about stdcall calling convention at all.

For 32 bit windows just stick to stdcall, for 64 bit windows I wouldn't have a clue, maybe the default calling convention is better designed already by default?

In either case there are no 64 bit windows client apps yet, so I don't think this is that important yet.

Fastcall would be bad choice either way because it basically means undefined non-standard calling convention...

[AF]

In either case there are no 64 bit windows client apps yet, so I don't think this is that important yet.

Java 64bit, I started a thread about the lack of 64bit unitsync under windows around a month ago.

[hoijui]

does 64bit spring sync with the 32bit one?

well. as it looks so far, we have it like this:

Code: Select all

          ;   32bit   ;      64bit       ;
Unix      ;   cdecl   ;   (unsepcified)  ;
Windows   ;  stdcall  ;   (unsepcified)  ;

I was talking about fastcall before, cause i read in the microsoft docu and something from AMD, that what they use now comes closer to fastcall then to any of the others from the 32bit options.
well.. i will put this table into action (if i figure out the a define that tells me wether we are compiling 32bit or 64bit).
if (unspecified) solution will cuase problems for 64 bit (we can test that with the AIs) we can still easyly change it to something else (at least on linux, if they support something else).

[AF]

Yes, linux users run a mix of 64bit and 32bit spring depending on their distribution architecture. I myself ran 64bit spring on Ubuntu x64 for a while. The issue is building 64bit mingw build on/for buildbot.

As for the JNA wrappers, they should suffice, but I will have to set aside time to port my classes to use these new wrappers and not JNI, which might be a while.

[aegis]

initial draft of python unitsync wrapper with map/mod loading sample code

works on windows and linux and requires python 2.5 or later, or the ctypes module for earlier python

http://lunixbochs.googlepages.com/unitsync.py

I'll probably make a unitsync helper from my sample code after I implement all of the functions