🎉 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!
AngelScript 2.6.0 released
It seemed I was wrong about size_t. It's an unsigned int after all ^^ sorry. I compiled with both AS_MAX_PORTABILITY and AS_64BIT_PTR. I tried 2.6.0 and HEAD but both give me the same error. Same error on the same line...
The 64bit support is new and not heavily tested (since I do not have a 64bit system myself). I'll need your help in order to try to find whatever bug it might be.
First, I need to know what the script you're using looks like.
Would it be possible for you to write a small test app that reproduces the problem with a minimal of other stuff, so that I can try to figure out what's going on?
First, I need to know what the script you're using looks like.
Would it be possible for you to write a small test app that reproduces the problem with a minimal of other stuff, so that I can try to figure out what's going on?
The script that I'm using ... well it's just _any_ statement, I tried a "float i;" which already made it crash. As soon as the script is valid it crashes, if it contains errors like "floooat i;" it works fine.
J
J
So you're compiling a script with only a global variable? Then the problem is with the execution of the @init function which is called automatically by the engine after compiling the scripts.
It seems that the bytecode is not properly attributed for this function for some reason. The code breaks on line 1031, which is "switch( *(asBYTE*)l_bc )", right? What is the value of l_bc at this moment? Is it null (shouldn't be)?
Could you compile the library with AS_DEBUG flag defined, and then show me the output file __@init.txt that should be generated in the folder AS_DEBUG (under the working directory). This ought to show the bytecode for the function that was compiled. It will probably look something like this:
At least if you're compiling the script "float i;".
Another thing. Would it be possible for you to try the test_feature project, compiled with the flag AS_MAX_PORTABILITY? That should run a few tests that works on my machine and hopefully on yours as well.
Regards,
Andreas
It seems that the bytecode is not properly attributed for this function for some reason. The code breaks on line 1031, which is "switch( *(asBYTE*)l_bc )", right? What is the value of l_bc at this moment? Is it null (shouldn't be)?
Could you compile the library with AS_DEBUG flag defined, and then show me the output file __@init.txt that should be generated in the folder AS_DEBUG (under the working directory). This ought to show the bytecode for the function that was compiled. It will probably look something like this:
Temps: 0 0 * RET 0At least if you're compiling the script "float i;".
Another thing. Would it be possible for you to try the test_feature project, compiled with the flag AS_MAX_PORTABILITY? That should run a few tests that works on my machine and hopefully on yours as well.
Regards,
Andreas
The debugger shows me:
l_bc asDWORD 0xff
*l_bc u int nil
Sorry, but it seems to be null :-/
If I compile with AS_DEBUG it gives me sooo much errors. I tried it before.
I also tried to file you asked me to try... same thing although it crashes on a different line then:
line 1961
*(l_fp - SWORDARG0(l_bc)) = int(*(double*)(l_fp - SWORDARG1(l_bc)));
*l_bc is not null there, it's 1836083564
J
l_bc asDWORD 0xff
*l_bc u int nil
Sorry, but it seems to be null :-/
If I compile with AS_DEBUG it gives me sooo much errors. I tried it before.
I also tried to file you asked me to try... same thing although it crashes on a different line then:
line 1961
*(l_fp - SWORDARG0(l_bc)) = int(*(double*)(l_fp - SWORDARG1(l_bc)));
*l_bc is not null there, it's 1836083564
J
Is it GCC you 're using in OS X?
If yes, could you run the following in a terminal and post its output here?
Yiannis.
If yes, could you run the following in a terminal and post its output here?
touch foo.hcpp -dM foo.hYiannis.
Jeffrey,
I think it will be very difficult for me to discover what's going on because I have no way of debugging the code. Would it be possible for you to debug the library to see if you can discover why the l_bc pointer is null?
Also, how about registering a username on GDNet? It's free. [smile]
mandrav,
Just out of curiousity, what would that show you? I'm not as familiar with GCC as you are. I know that touch will create an empty file (if it doesn't exist already) but what will 'cpp -dM' do?
Also, could you confirm that the latest version still works on 64bit systems without your changes? If it does, then it is likely that I need to do something slightly different on PPC 64, than for AMD 64. Perhaps it is due to the little-endian/big-endian differences?
Regards,
Andreas
I think it will be very difficult for me to discover what's going on because I have no way of debugging the code. Would it be possible for you to debug the library to see if you can discover why the l_bc pointer is null?
Also, how about registering a username on GDNet? It's free. [smile]
mandrav,
Just out of curiousity, what would that show you? I'm not as familiar with GCC as you are. I know that touch will create an empty file (if it doesn't exist already) but what will 'cpp -dM' do?
Also, could you confirm that the latest version still works on 64bit systems without your changes? If it does, then it is likely that I need to do something slightly different on PPC 64, than for AMD 64. Perhaps it is due to the little-endian/big-endian differences?
Regards,
Andreas
Quote: Original post by WitchLord
mandrav,
Just out of curiousity, what would that show you? I'm not as familiar with GCC as you are. I know that touch will create an empty file (if it doesn't exist already) but what will 'cpp -dM' do?
Also, could you confirm that the latest version still works on 64bit systems without your changes? If it does, then it is likely that I need to do something slightly different on PPC 64, than for AMD 64. Perhaps it is due to the little-endian/big-endian differences?
Regards,
Andreas
Could be an endianness issue but that is for you to check Andreas :)
The command I posted above will dump all built-in preprocessor symbols so we can see if _LP64 is defined or, if not, which symbol is defined that tells us it's 64bit system. This way we can better refine the preprocessor conditionals inside AngelScript. So instead of using "#ifdef _LP64" in code, we could define a "#define AS64" (for example) in as_config.h (based on more than _LP64) so at least the pointer arithmetic works as expected...
As for my changes:
I 've decided that the coming weekend I 'll send you all my changes, no matter what state they 'll be in (i.e. not finished). I think it might be better if we could get one or two more helping hands on this as I 'm nearing the release date for Code::Blocks 1.0rc3 and my free time will be limited.
So, anyone who has posted the interest to help, check back around the weekend ;)
Yiannis.
Yes, of course. I didn't mean for you to validate the endianess. Sorry if I gave that impression.
I'll have to remember that command for GCC. It looks like it could come in handy in the future as well.
I'll accept the code you have even though it may not work 100%. Surely others will be able to help out validating it and rooting out the bugs that remain.
Regards,
Andreas
I'll have to remember that command for GCC. It looks like it could come in handy in the future as well.
I'll accept the code you have even though it may not work 100%. Surely others will be able to help out validating it and rooting out the bugs that remain.
Regards,
Andreas
I know about the registering... I'm just bloody lazy ;-)
I'll do my best to debug as much as I can and, hopefully, nail that nasty bug.
The define to determine whether it's a 64 bit or not on OS X is __LP64__ instead of _LP64.
Cheers,
J
ps, I'll create an account now ;-)
I'll do my best to debug as much as I can and, hopefully, nail that nasty bug.
The define to determine whether it's a 64 bit or not on OS X is __LP64__ instead of _LP64.
Cheers,
J
ps, I'll create an account now ;-)
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement