Hello, Has anyone started working on 64 bit support for Windows (Visual C 2005/2008) (based on the existing GCC support)? I just wanted to know what's the status on that and I know many asked for this support. Regards, Adrian L.

I am not sure what exactly you mean.

visual c++ == c++ compiler by microsoft

GNU == not unix
GCC == the gnu compiler collection
gcc == the gnu c compiler
g++ == the gnu c++ compiler

GNU + Microsoft == incompatible

Hi,

I was asking if someone is working on AngelScript support for native calls on 64 bit compilation under Visual Studio. I know that with the latest AngelScript version there is support for 64 compilation under x86 gcc compiler.

Someone posted that one can use that support and modify to be adapted for Visual C++ compiler:

http://www.gamedev.net/community/forums/topic.asp?topic_id=523353

Regards,
Adrian L.

Argh, sorry Licu, I didn't see that this is in AngeScript forums, happens all the time to me; cannot help on that topic unfortunately :S

No one has announced himself/herself as working on the 64bit Windows support. Though I'm quite sure it wouldn't be difficult to add it now that 64bit Linux support is already working.

I've yet to aquire a 64bit platform to develop on, otherwise I would do it myself.

By the way, can Visual C++ 2008 Express edition do 64bit compilation or do you need the full version for that?

Hi Andreas,


About Express and 64 bit, this is what I've found on Wikipedia:

"The Visual C++ 2008 Express Edition can be used to compile .NET as well as Win32 applications immediately after installation. However, natively compiling 64-bit applications through the IDE is not supported without some involved configurations. If the freely available Windows SDK is installed, 64-bit applications can be built on the command line using the x64 cross-compiler (Cl.exe) supplied with the SDK. [6] True integration of 64bit compilers to the Visual C++ 2008 Express Edition is possible, but remains cumbersome. [7]

Visual C++ 2008 Express does not include OpenMP support, 64-bit compilers, or a resource editor. The higher-end commercial editions of Visual Studio, specifically the Professional and Team Suite editions, have these features.[8]"


About generic calls (which is a way to make AngelScript work on 64bit), are there any speed differences between these and native calls? Also are there any AngelScript features not supported for generic calls?


Regards,
Adrian L.

I believe the generic calls are slower than the native calls, but I haven't actually tested this. It also depends on how the support for the native calls have been implemented. On 64bit, where the parameters must be placed in different registers depending on the type, it may very well be that generic calls are faster than the native calls. But on 32bit where the parameters are just pushed on the stack the native calls are almost certainly faster.

No, you don't lose any features by using the generic calling convention.

Ok, thanks. I was also assuming that generic calls are a littler slower (since there are some virtual functions involved for getting parameters and returning the function value with asIScriptGeneric).

Quote: Original post by WitchLord
No one has announced himself/herself as working on the 64bit Windows support. Though I'm quite sure it wouldn't be difficult to add it now that 64bit Linux support is already working.

I'm not sure that having the 64-bit linux code is going to be that much help. One of the things that Microsoft did with MSVC is disable inline assembly with x64 builds. While there are quite a few 64-bit intrinsics that mimic a lot of the x64 assembly instructions, notably missing are any form of push and pop. Microsoft recommends moving the inline assembler into external files, but using a function call to implement push or pop doesn't sound like something that would work cleanly since the stack frame from the function call would mess with things. There also doesn't seem to be a clean way to do an unconditional jump with intrinsics. Off the top of my head, that only leaves implementing most of the functions in as_callfunc completely in assembly, which is what you might call a non-trivial exercise.

On the plus side, register usage and calling conventions are pretty well documented.

Any one know the reasoning behind Microsoft dropping inline support in x64?