GameMonkey Script

Thanks for that, let us know how you go with your 64bit version.

I am looking into the forum attachment problem. I just did a test and wasn't able to attach a file myself. I will get back to you soon on this issue.

Attachments should work fine now.

Thanks for the fix,I have attached the modified files:

Thanks for that MagickPanda. I've had a quick look through the code and it appears you've mainly made sure that all references to BOTH integer and pointer are now 64 bit, is that correct? This is fine, though we really need to update the code one day to allow arbitrary sized int and pointers where, for example an xbox person may want 64bit ints and floats while retaining 32bit addressing, or a Windows 64 person may want 64bit addressing but still 32bit int values.

Thanks for clarifying that. I'll see if I can at least fix the cases where native 'int' was used instead of 'gmptr' or such as those should work for everyone.

Hmm, I'm not happy. I just had a look into the gm code. There are so many issues to make the thing truely 64bit and safe. I believe you got lucky with your changes, but there are still risks with them. For example, Bison has a stack which contains both code tree node pointers and integer values. Because the new code uses 64bits for gmint/gmuint, it works, but those get cast to int which may not be. The code really should use gmptr and gmuptr when casting from void* or such and gmint/gmuint for all true integer operations. The GM code is inconsistent with this usage, and code like that in Bison is not easy to correct. What about gmVariable? Unless your int and float values are zeroed or scaled up to 64bit, the top bits will contain junk since they are unioned with pointer size values. The gmVariables are hashed so gmTable indices for example might get screwed up.

I'm thinking a safe hack might be to make most integers 64bit to match pointer size AND zero values as much as possible so that operations on union values will produce consistent results.

A proper solution might take considerable effort and a bunch of testing. A proper solution would allow different sizes for integers and pointers, used internally by the machine and used as a value (gmVariable) choice by the user.

Thanks for the info,I will add memset to gmVariables so it won't make wrong/erroneous table hash off high-bits junk.
I am only using the very basic features of GM,I am not even binding C++ objects to GM,so it will be hard to test anything other than table hashing/accessing under 64bit.

There's a good chance you'll be fine. If you add a constructor to gmVariable, instead of the memset (which may or may not compile nicely as an intrinsic), you could just set m_ref or the largest union member to zero. Another alternative is to modify gmTableObject::GetAtHashPos to perform a different hash based on the variable type. If you're happy with performance and behavior, despite what I said, I think there's a good chance it will all work.