GameMonkey Script

I am using GameMonkey as data table and definitive data in my simple game,the game is an open source one,so I want it to run both windows and linux platform.

I included gm source files in my MSVC2005 express project and it worked without any problems.But gm errors out with the following error message when compiling with g++ under 64bit linux:

Error:cast from 'const gmObject' to 'gmPtr' loses precision

If I recall correctly this error means incompatible pointer size between 2 pointers,so I looked at gmConfig.h and gmConfig_p.h(where gmPtr is defined) but could not find anything to configure 64bit compilation.

Part of makefile used to compile my source files/gm source files:


So my questions are?

Is GameMonkey 64bit safe and compile-able under 64bit linux?
If it's 64bit safe,are there guides on how to compile it under 64bit linux?

Also I would like to know if there exists an makefile for GameMonkey,for easier compilation under linux.

Thanks.

Since no one was around to help,I decided to try to compile it with a simple make file.I fixed few minor issues with pointer size mismatch and missing endian swap function for 64bit,but this one beats me:


generated code(gmParser.cpp)

Original code(gmParser.y)


I checked gmCodeTree.cpp|.h and found that the last parameter of gmCodeTreeNode::Create is m_SubTypeType,but the purpose of this cast is still unclear to me,so I am unable to figure out a sane way to get around this.

Hi MagickPanda, and welcome to the forum. To answer your 64bit questions, the current GM code is not 64bit safe. The code does not consistently use the correct types for Pointer, Integer and Integer of at least pointer size.

I know at least two people have reported in, attempting to port the code to be 64bit ready, but I have not heard back from either. I've personally built the code for 64bit systems, but not with 64bit addressing.

Sorry I can't help with the Linux 64bit build or the compiler warnings or errors at the moment. I'd encourage anyone who has improved the code for 64bits so speak up. These changes will be increasingly useful in the future.

Thanks for the reply,I hacked around the problem I mentioned in last post and got GM to compile:

Changes:
*Added D_GM_X86_64 and GM_X86_64 for including amd64 platform config files
*Added gmint to all gmConfig_p.h(int on 32bit,int64_t on 64bit)
*Added gmConfig_p.h in folder amd64gcc,I copy the contents of the one in win32gcc and changed the types to sys/types.h types accordingly
*Added gmconfig_p.cpp in folder amd64gcc with 2 functions:gm_cstr_tolower and gm_cstr_tolower,because strlwr and strupr are not standard functions and they are not available in linux's string.h,It will use those 2 replacement functions when strlwer is undefined
*Added SwapEndian functions for 64bit gmuint64 and gmint64 in gmStream.h(Please check them since I am not sure I was careful enough when writing them/counting the zero's)
*Changed void*<-unsigned int<-pointer cast to void*<-gmuint<-pointer in memChain.cpp(gmuint is u_int64_t on 64bit,unsigned int on 32bit)
*Changed "casting from pointer to int" to "casting from pointer to gmint" in gmParser.y(still unsure about the side effects of this)

I only tested with my simple .gm file and it seemed getting the value of 'testtileset' properly and loaded the bitmap successfully,hopefully more people can help testing GM on 64bit.


P.S:It seems I can't attach any file as attachment,it always gave me 'Sorry, the board attachment quota has been reached.' error when attaching the file(the file is 82KB zip)

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.

You are welcome.

My changes are to ensure all pointer storage types(gmptr,gmuptr) to be 64bit so pointers won't get 'squeezed' to 32bit when they get casted from pointer to integer.
I haven't looked all GM source files thoroughly,but I think my changes shouldn't affect the size of int GM uses,since GM uses gmuint32/gmint32 as its integer type,while gmuint is only used for array index and iteration in arrays it seems to me.

For 64bit ints and floats in GM script,I doubt they will be any real use in scripts,I don't think any one will do high precision 3D computation or store/update 64bit timestamp etc in scripts.

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.

Is using int in bison stack a defect of bison or is it a problem with the way gm utilizes bison/flex?


I checked different methods of gmHash in gmHash.h and I did not find anything that uses m_int or m_float as hash 'a_key' parameter,the only one look suspicious is:



Though I believe the 64bit m_int(the union will have the size of biggest member 'gmptr m_ref') will be casted to 32bit int implicitly before getting passed to that function.


I will do more testing when I use GM more intensively later,it's hard to tell what the potential problems are without getting crashes/wrong script values.

BTW I wonder why there is no project for GM on open-source sites or public svn repository and a bugtracker where users can report bugs and share patches or alike.

Certainly the way we are using it causes me concern, I'm not sure if Bison itself is flawed.
I was actually refering to gmTableObject::GetAtHashPos which uses the ref part of the gmVariable union to create the hash value. Other casts should extend and truncate values, possibly safely.
Please do. I didn't want to scare you off, just as I looked at the code, the longer I looked, the more potential problems I found. I wasn't going to be the quick trivial update I'd hoped for. I am quite confident that you will be able to stabilize your build if these issues expose themselves.There is regular talk of such a thing, but it's up to the GM community to get that together. Anything that encourages development and sharing is good. As I've stated in the forum FAQ, I have neither time nor desire to dominate GM development. People have different needs and should to modify and extend the code as they please, and it is of great value to share those changes and bindings. I plan to stick around maintaining this forum, answering Qs as I can, and fixing critical bugs if they appear, to provide a stable build as reference. The build hosted here should be considered my personal build for public reference, and I would encourage others to share their entire builds or large chunks of code, at least until a workable source revision system or shared repository is available. For the time being, the Support forum is a place to post bugs, and the General forum is a place to share info including code. I can host some downloads here, if needed and attachments are working.

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.