Index: src/sdk/as/source/as_context.cpp
===================================================================
--- src/sdk/as/source/as_context.cpp (revision 1840)
+++ src/sdk/as/source/as_context.cpp (working copy)
@@ -2607,7 +2607,7 @@
}
// Add the base offset for multiple inheritance
- currentObject = (void*)(int(currentObject) + sysFunc->baseOffset);
+ currentObject = (void*)(long(currentObject) + sysFunc->baseOffset);
// Keep a reference to the object to protect it
// from being released before the method returns
Index: src/sdk/as/source/as_module.cpp
===================================================================
--- src/sdk/as/source/as_module.cpp (revision 1840)
+++ src/sdk/as/source/as_module.cpp (working copy)
@@ -579,7 +579,7 @@
for( asUINT n = 0; n < globalVarPointers.GetLength(); n++ )
{
if( globalVarPointers[n] >= start && globalVarPointers[n] < (start+index) )
- globalVarPointers[n] = &globalMem[0] + (int(globalVarPointers[n]) - int(start))/sizeof(void*);
+ globalVarPointers[n] = &globalMem[0] + (long(globalVarPointers[n]) - long(start))/sizeof(void*);
}
return index;
🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
Compiling AngelScript in x64
Author
Hi! This is for library developers (Andreas) :)
I'm trying to compile a program (Code::Blocks btw) that uses AngelScript, in Ubuntu Linux 64 bits.
AngelScript requieres some fixes, and most of them are because it assumes that sizeof(void*) == sizeof(int), which is only the case in some 32 bits architectures.
It should assume instead, that sizeof(void*) == sizeof(long). Or maybe, it can be typedef'ed.
BTW, if you want to know other sizeof's, I'm maintaining a list here: http://xjapan.wikispaces.com/Size+of+Primitive+Data+Types
Of course, I had to define AS_MAX_PORTABILITY also.
I get lot's of -7 return codes, which means asNOT_SUPPORTED, when doing the bindings. Should I use asCALL_GENERIC instead?
Here is a little patch:
Quote: Original post by Takeshi Miya
It should assume instead, that sizeof(void*) == sizeof(long). Or maybe, it can be typedef'ed.
Also not true on all compilers. However, sizeof(void *) should be the same as sizeof(size_t)
Author
Quote: Original post by SiCraneQuote: Original post by Takeshi Miya
It should assume instead, that sizeof(void*) == sizeof(long). Or maybe, it can be typedef'ed.
Also not true on all compilers. However, sizeof(void *) should be the same as sizeof(size_t)
That's true, I don't remember, on what header is size_t defined? It is ISO/C++02 or C99?
Because I remember using iso686 typedefs like int32_t and the like, but they are C99, and they aren't part of the ISO/C++ standard (yet).
Hi Takeshi Miya,
Thanks for letting me know about the problems with AngelScript on 64bit platforms. I'll update the library with these corrections that you sent me.
I'd also appreciate any further feedback, because I do not have access to a system with a 64bit OS, so I'm unable to work on the 64bit port myself. I want very much to support 64bit with AngelScript, and I know there are a lot of work to do, but I need help to do it.
Also, when defining AS_MAX_PORTABILITY, all support for native calling conventions (which require inline assembly and exact knowledge of calling conventions) is disabled. The only calling convention that can be used with AS_MAX_PORTABILITY is the asCALL_GENERIC.
Regards,
Andreas
Thanks for letting me know about the problems with AngelScript on 64bit platforms. I'll update the library with these corrections that you sent me.
I'd also appreciate any further feedback, because I do not have access to a system with a 64bit OS, so I'm unable to work on the 64bit port myself. I want very much to support 64bit with AngelScript, and I know there are a lot of work to do, but I need help to do it.
Also, when defining AS_MAX_PORTABILITY, all support for native calling conventions (which require inline assembly and exact knowledge of calling conventions) is disabled. The only calling convention that can be used with AS_MAX_PORTABILITY is the asCALL_GENERIC.
Regards,
Andreas
Author
As SiCrane pointed out, even better than using long instead of int, is using size_t, and #include <cstddef>.
I want to help with any feedback you need, AngelScript rocks :D. (AngelScript in Code::Blocks, can't get any better).
If you can make some regression tests or test units (using boost::test/whatever), then I could send you the results. Or do you mean other kind of feedback?
A question: If the bindings doesn't uses asCALL_GENERIC, but I have defined AS_MAX_PORTABILITY, it automatically uses asCALL_GENERIC? or everything brokes?
Regards,
Takeshi Miya.
I want to help with any feedback you need, AngelScript rocks :D. (AngelScript in Code::Blocks, can't get any better).
If you can make some regression tests or test units (using boost::test/whatever), then I could send you the results. Or do you mean other kind of feedback?
A question: If the bindings doesn't uses asCALL_GENERIC, but I have defined AS_MAX_PORTABILITY, it automatically uses asCALL_GENERIC? or everything brokes?
Regards,
Takeshi Miya.
Keep in mind that if you want to generate portable x86-64 code, you'll probably need to test with at least two compilers: a 64 bit port of gcc and a 64 bit MSVC compiler. Obnoxiously, the two compilers have defined some types to be different sizes, like long. And everything goes straight out the window if you want to support a non-x86 64 bit processor like IA-64.
Takeshi Miya:
I'll probably end up writing my own typedefs to make sure the types use the right size where its necessary. Different compilers will then be detected in as_config.h.
When using AS_MAX_PORTABILITY, you'll not be able to register a function using anything else than asCALL_GENERIC. If you do you'll get an error, and any scripts you try to compile will fail with the error 'Configuration error'. Should you register a function as asCALL_GENERIC, but the function really isn't using the asCALL_GENERIC convention, you'll probably end up crashing the application when the function is called (the function parameters will obviously be completely wrong).
I already have regression tests available in the test_feature folder. If you compile the test_feature app with the AS_MAX_PORTABILITY flag defined, it will only run the tests that work with asCALL_GENERIC. If we can get those tests working on 64bit, we will have come a long way. After that we can test more things.
SiCrane:
Indeed, the library must be tested on various compilers. Not only is the types different on different compilers, but the calling convention is also different. But I'll have to take it one step at a time. If can get the library to work on one 64bit compiler, it will be easier to port to other 64bit compilers afterwards.
I'll probably end up writing my own typedefs to make sure the types use the right size where its necessary. Different compilers will then be detected in as_config.h.
When using AS_MAX_PORTABILITY, you'll not be able to register a function using anything else than asCALL_GENERIC. If you do you'll get an error, and any scripts you try to compile will fail with the error 'Configuration error'. Should you register a function as asCALL_GENERIC, but the function really isn't using the asCALL_GENERIC convention, you'll probably end up crashing the application when the function is called (the function parameters will obviously be completely wrong).
I already have regression tests available in the test_feature folder. If you compile the test_feature app with the AS_MAX_PORTABILITY flag defined, it will only run the tests that work with asCALL_GENERIC. If we can get those tests working on 64bit, we will have come a long way. After that we can test more things.
SiCrane:
Indeed, the library must be tested on various compilers. Not only is the types different on different compilers, but the calling convention is also different. But I'll have to take it one step at a time. If can get the library to work on one 64bit compiler, it will be easier to port to other 64bit compilers afterwards.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
