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.
|