Just a small list of issues working on getting angelscript working here (VS2010sp1 in 64 bit):

1) Standard microsoft insanity: I had to #undef GetObject before <angelscript.h> due to WinGDI.h defining it for UNICODE variants GetObjectA vs GetObjectW

2) In warning level 4, I had to wrap struct asSFuncPtr with #pragma warning(disable:4371)

3) In warning level 4, I had to wrap template function asFunctionPtr with #pragma warning(disable:4191) (even a reinterpret_cast generates this warning!)

4) In scriptstdstring.cpp, the std::string in local scope looks like it is suspiciously begin stuffed into a pointer that outlives the scope of the local. Its hard to say since I don't know the guts of AngelScript yet, but that seems to be what SetReturnObject does.

5) as_callfunc_x64_msvc.cpp and as_callfunc_x64_msvc.asm generate collisions in the generated .obj file, its probably easier to rename one of the source files than hacking up the vcxproj settings to use an alternate output filename. Changing this reduces the number of steps it takes to make the 32bit-centric vcxproj work in 64 bit

The asm code in CallX64 is doing something to the rsp register, that causes RtlCaptureStackBackTrace (and the visual studio debugger!) to think the oldest function in the stack frame is CallX64. The good news is the code works, the bad news is crash dumps or unwinding the stack to a logfile is not very nice from a usability standpoint.


Stack going into CallX64

> tess-x64-DebugAVX.exe!CallX64() Line 62 Asm
tess-x64-DebugAVX.exe!CallSystemFunctionNative(asCContext * context, asCScriptFunction * descr, void * obj, unsigned long * args, void * retPointer, unsigned __int64 & __formal) Line 173 + 0x21 bytes C++
tess-x64-DebugAVX.exe!CallSystemFunction(int id, asCContext * context, void * objectPointer) Line 424 + 0x61 bytes C++
tess-x64-DebugAVX.exe!asCContext::ExecuteNext() Line 1954 + 0x17 bytes C++
tess-x64-DebugAVX.exe!asCContext::Execute() Line 983 + 0xa bytes C++
tess-x64-DebugAVX.exe!cSubsystem_Initialize() Line 53 C++
tess-x64-DebugAVX.exe!MingineInit() Line 61 C++
tess-x64-DebugAVX.exe!WinMainSEH(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * cmdLine, int nShowCmd) Line 106 C++
tess-x64-DebugAVX.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * cmdLine, int nShowCmd) Line 202 + 0x19 bytes C++
tess-x64-DebugAVX.exe!__tmainCRTStartup() Line 547 + 0x42 bytes C
tess-x64-DebugAVX.exe!WinMainCRTStartup() Line 371 C
kernel32.dll!BaseThreadInitThunk() + 0xd bytes
ntdll.dll!RtlUserThreadStart() + 0x21 bytes


Stack coming out of CallX64

> tess-x64-DebugAVX.exe!sFormat(const unsigned char * message, const sFormatArgs & items) Line 1194 C++
tess-x64-DebugAVX.exe!sFormat(const char * message, const sFmtItem & item1) Line 1328 + 0x2a bytes C++
tess-x64-DebugAVX.exe!PrintNumber(int num) Line 21 + 0x3c bytes C++
tess-x64-DebugAVX.exe!CallX64() Line 133 Asm


Hi Zoner,

thanks a lot for the feedback. I'll look into these, and make the appropriate adjustments.

Any idea what needs to be changed in CallX64 to make it play nicer with the debugger?



PS. I noticed your signature. Could it be that AngelScript is making it's way into the office of Gearbox Software? Even if not on any official project? I would be very honored if that is the case.

Hi Zoner,

thanks a lot for the feedback. I'll look into these, and make the appropriate adjustments.

Any idea what needs to be changed in CallX64 to make it play nicer with the debugger?



PS. I noticed your signature. Could it be that AngelScript is making it's way into the office of Gearbox Software? Even if not on any official project? I would be very honored if that is the case.

I read up on the ABI and the MSDN on the ABI a bit and I think I have corrected MASM code, it seems to work for me, though I haven't hooked much up to my pet project to really stress calling a bunch of natives yet:

http://codepad.org/F3rzDa5i


New and improved callstack:

> tess-x64-DebugAVX.exe!tStackBuffer<sFmtItem const * __ptr64,32,tDefaultStackSpilloverAllocatorStrategy,tDefaultStackSpilloverAllocator>::constructorCommon() Line 41 C++
tess-x64-DebugAVX.exe!sFormatArgs::sFormatArgs(const sFmtItem & item1) Line 802 C++
tess-x64-DebugAVX.exe!sFormat(const char * message, const sFmtItem & item1) Line 1328 + 0x12 bytes C++
tess-x64-DebugAVX.exe!PrintString(const sUTF8 & str) Line 17 + 0x3c bytes C++
tess-x64-DebugAVX.exe!CallX64() Line 139 Asm
tess-x64-DebugAVX.exe!CallSystemFunctionNative(asCContext * context, asCScriptFunction * descr, void * obj, unsigned long * args, void * retPointer, unsigned __int64 & __formal) Line 173 + 0x21 bytes C++
tess-x64-DebugAVX.exe!CallSystemFunction(int id, asCContext * context, void * objectPointer) Line 424 + 0x61 bytes C++
tess-x64-DebugAVX.exe!asCContext::ExecuteNext() Line 1954 + 0x17 bytes C++
tess-x64-DebugAVX.exe!asCContext::Execute() Line 983 + 0xa bytes C++
tess-x64-DebugAVX.exe!cSubsystem_Initialize(unsigned int numstackbytes) Line 55 C++
tess-x64-DebugAVX.exe!MingineInit() Line 61 C++
tess-x64-DebugAVX.exe!WinMainSEH(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * cmdLine, int nShowCmd) Line 106 C++
tess-x64-DebugAVX.exe!WinMain(HINSTANCE__ * hInstance, HINSTANCE__ * hPrevInstance, char * cmdLine, int nShowCmd) Line 202 + 0x19 bytes C++
tess-x64-DebugAVX.exe!__tmainCRTStartup() Line 547 + 0x42 bytes C
tess-x64-DebugAVX.exe!WinMainCRTStartup() Line 371 C
kernel32.dll!BaseThreadInitThunk() + 0xd bytes
ntdll.dll!RtlUserThreadStart() + 0x21 bytes


PS. I noticed your signature. Could it be that AngelScript is making it's way into the office of Gearbox Software? Even if not on any official project? I would be very honored if that is the case.

At work we use Unreal Engine pretty much exclusively, but I finally managed to quit playing WOW last year, so have been spending the time catching up on tech we don't normally use or won't use for a while: (D3D11, pure 64 bit programming, AVX, various scripting tech (AngelScript, lua etc), and assorted other tech Ruby, Powershell, etc).

I actually ran into AngelScript by accident when I was looking for a usable font generator, since Microsoft in their infinite wisdom didn't make D2D1/DirectWrite interop correctly with D3D11, forcing me to find alternate means to draw debug text

As for AngelScript itself, it looks good so far. Most of the time when I download code from the internet it either looks like it was code rejected from the STL for being unreadable, is peppered with more ifdefs than code, or is written by linux fanatics who think portable code means it only needs to run on linux because 'linux is portable'. So it passes all those smell tests (and has a few bonuses like not linking against the STL runtime dlls, supports user defined allocation).

Thanks for the fix for CallX64. I'll run it through the regression tests before I check it in, but based on the changes done I don't really see anything that could go wrong.


I'm glad to hear you approve of the coding.


I hope you'll spread the word about AngelScript and BMFont. Please let me know if you have any suggestions for further improvements or new features for either of the projects.

Thanks for the fix for CallX64. I'll run it through the regression tests before I check it in, but based on the changes done I don't really see anything that could go wrong.


I'm glad to hear you approve of the coding.


I hope you'll spread the word about AngelScript and BMFont. Please let me know if you have any suggestions for further improvements or new features for either of the projects.

Supporting C++0x move constructors and operators might be worthwhile, they are pretty awesome for passing heavy objects around more sanely.