Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Sixtyfoursupport #46

Closed
wants to merge 9 commits into from

4 participants

@jamesu

This branch allows Torque2D to be built for 64bit platforms, i.e. 64bit OSX and 64bit Windows.

The biggest change in this branch is in the TorqueScript compiler & interpreter. To allow for the fact that 64bit machines tend to use 64bit pointers, the code stream has been adjusted so that 8 bytes of data are reserved for string and namespace pointers instead of just 4.

For details, check out the post on GarageGames: http://www.garagegames.com/community/forums/viewthread/133068

The project files for Visual Studio 2010 and XCode have been modified to enable 64bit builds. Since I do not have a copy of Visual Studio 2012 installed, that project file remains unchanged.

@doodaddy64
Collaborator

Goodness. :) I will look at this over the next few days. Thanks!

@doodaddy64 doodaddy64 commented on the diff
...source/platformWin32/nativeDialogs/win32FileDialog.cc
@@ -112,7 +112,11 @@ static UINT_PTR CALLBACK FolderHookProc(HWND hdlg, UINT uMsg, WPARAM wParam, LPA
SendMessage(hParent, CDM_HIDECONTROL, cmb1, 0);
SendMessage(hParent, CDM_HIDECONTROL, stc2, 0);
+#ifdef _WIN64
@doodaddy64 Collaborator

There will be a platformWin32 with code that says "#ifdef Win64" :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@doodaddy64 doodaddy64 commented on the diff
engine/source/2d/core/SpriteBatchItem.h
@@ -134,7 +134,11 @@ class SpriteBatchItem : public ImageFrameProvider
// This should be as unique as possible as it is used for hashing.
operator const U32() const
{
+#ifdef TORQUE_64
@doodaddy64 Collaborator

Is it necessary to create 64-bit hashes here? If 32 bits does the job (and the return type of the function is still 32 bits) then it would be nice to avoid any unnecessary ifdef'ing.

@jamesu
jamesu added a note

XCode complains if you cast pointers to 32bit integers. Also if mArgString exists in a memory space past 4,294,967,295 only has its upper 32 bits set, this function will always return 0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@doodaddy64 doodaddy64 commented on the diff
engine/source/collection/hashTable.h
@@ -41,7 +41,11 @@
inline U32 hash(const void *data)
{
+#ifdef TORQUE_64
@doodaddy64 Collaborator

same as other comment: Is it necessary to create 64-bit hashes here? If 32 bits does the job (and the return type of the function is still 32 bits) then it would be nice to avoid any unnecessary ifdef'ing.

@jamesu
jamesu added a note

Again XCode was complaining about the void* -> U32 cast

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@doodaddy64 doodaddy64 commented on the diff
engine/source/platform/types.gcc.h
@@ -112,6 +112,12 @@
# define TORQUE_CPU_X86
# define TORQUE_LITTLE_ENDIAN
+#elif defined(__amd64__)
+# define TORQUE_CPU_STRING "Intel x86-64"
+# define TORQUE_CPU_X86_64
+# define TORQUE_LITTLE_ENDIAN
+# define TORQUE_64
@doodaddy64 Collaborator

I want to make sure that amd64 is only set when the developer chooses x64 instructions? probably but I want to be sure.

@jamesu
jamesu added a note

If you compile for Itanium the define is ia64 instead

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@doodaddy64 doodaddy64 commented on the diff
engine/source/console/astNodes.cc
@@ -798,9 +798,9 @@ U32 VarNode::precompile(TypeReq type)
precompileIdent(varName);
if(arrayIndex)
- return arrayIndex->precompile(TypeReqString) + 6;
@doodaddy64 Collaborator

two comments:

Hmm. One generic comment for the entirety of the numerical changes (such as +6 becomes +7). I would really like this to be more informative. It wasn't much so before with +6 but as long as the numbers need to change, it would be nice to have a global value to use for such things. I know this would be more work, but also more debuggable and maintainable going forward with open source.

Another generic comment: it appears that 32 and 64 bit are getting the extended stack size in your update? It would be nice if this was saved for 64-bit only. Mobile devices are (I'm pretty sure) 32 bit and need to save space. What do you think?

@jamesu
jamesu added a note

Basically since I now allocate 64 bits for each name I have to increase the size of all the nodes. It's a pain using cryptic numbers, I agree.

I increased the size on both platforms to maintain compatibility between 32bit and 64bit binaries. On OSX, typically both 32bit and 64bit binaries are combined into a single fat binary. If I simply saved the extended space for 64bit binaries I'd need to duplicate ALL of my DSOs: 1 set for 32, the other for 64 which would waste a ton more space than simply just allocating an extra byte for each name entry.

For mobile platforms nowadays your biggest assets tend to be images and sound, not script.

@doodaddy64 Collaborator

OK. But two concerns.

  • will the 64-bit enhanced version run for a (new) 32-bit app without a hitch?
  • how tested are your torqueScript updates? As the it2d version proved, it's a hairy business trying to update the little numbers everywhere. it ended up not working. (PUAP_SCRIPT_CHANGE anyone)
@jamesu
jamesu added a note

1) yes
2) Tested on mac 32, mac 64 & ipad. Seems to be working for me.

PUAP_SCRIPT_CHANGE was pretty bad. This on the other hand merely changes the size allocated for the names in code. It doesn't do anything too fancy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
@doodaddy64
Collaborator

I'm wondering if this update is actual 64-bit goodness, or just enough changes to compile with a 64-bit compiler?

Looking at the engine's macros, I see that U32, for instance, is defined as

typedef unsigned int U32; ///< Compiler independent Unsigned 32-bit integer.

In other words, it appears that, U32 expands to a generic "unsigned int" which means you get 64 bits on a 64 bit compiler? Is that true?

@jamesu

For most 64bit compilers i've used, the int is still 32 bits and you need to use long long for 64 bits. This can be verified by printing out sizeof(int). Other more obscure platforms may vary.

@doodaddy64
Collaborator

OK. Not to be critical, just curious. Do you get some performance or other boosts out of this? Off the top of my head, it seems to stay "32-bits" in a "64-bit wrapper." There is a certain cache, at least, for supporting 64-bits I would agree.

@eightyeight

@doodaddy64 Doesn't 64-bit simply refer to the amount of memory space that can be addressed? Is there actually a need to make stuff like integers bigger? Existing compilers can do this (we can use long longs already), but they can't use 64-bit pointers.

@doodaddy64
Collaborator

@eightyeight I haven't kept up with the latest developments in 64-bit compilers, which is why I was asking. Word on the street a few years ago was that it didn't give a speed boost and so you shouldn't bother if you didn't need > 4GB. Others say for math intensive apps it may give a "significant" boost. Compilers have probably come along as well. I was hoping to get some education on this. :)

For instance, perhaps a modern compiler will stuff two 32-bit ints into a single memory call. Stuff like that.

@doodaddy64
Collaborator

@jamesu The code looks great. Great job!

I'd like to make this an official branch of the main repo for now if that's alright with you. I'd like people to play with it, and get some eyes and script code running through it since it has to tweak so many constant numbers.

One thing I'm thinking about is adding a header to the compiled torquescript files so we can at least gracefully exit (with message) if older torquescript dso's are loaded. (I'm assuming there is no header at all currently.)

Another (subtle) thing is whether the Win32 platform should be renamed just Win. Stuff like that.

@jamesu

@doodaddy64 all DSOS have a header containing a version number. If a DSO is the wrong version, it won't load. In this pull request I bumped the DSOVersion constant from 43 to 44.

Feel free to branch it, play with it, etc. Thats why I submitted it of course! :)

@doodaddy64
Collaborator

would it be easy for you to switch the pull request to upstream/sixtyfoursupport? If I do it, I'll need to add your fork as a remote on my desk and what-not. heh.

@doodaddy64
Collaborator

I made a Sixtyfoursupport branch off of origin/master. If you switch your pull request to it, I think that will do it!

@jamesu jamesu referenced this pull request in GarageGames/Torque3D
Closed

Steps on the way to Linux client support. #350

@jamesu

@doodaddy64 doesn't seem to be a way of doing that from the github interface. Not really sure what the purpose of switching a pull request if the upstream already has the branch =/

@doodaddy64
Collaborator

If you go back to the same pull request, I think you can go to the top of the page and use the drop down to change the request to a diff branch.

I added the branch as a name only. No code added or merged. You could consider it unrelated to your branch. My goal was to make it so you could switch your request to it in one easy step and I could merge the pull request. (Before I added it, you wouldn't be able to make a pull request to a non-existent branch on upstream so you had to choose master or development or whatever. Now there is a branch to pull to.)

I'm new to this stuff. My goal was to make sure you get the main credit, and to avoid me adding your fork to my working copy just so I could make a new branch in the upstream. Phew. :)

@jamesu

@doodaddy64 ah I get you. Unfortunately when you make the pull request it seems there is no way from the github interface to rebase it to another branch. In order to do it in the way you suggest, I need to create a completely new pull request and also rebase my branch to yours. From what I gathered from the wiki, I figured all you guys wanted was a branch based off development and a pull request. If this is not the case I recommend you update the wiki to reflect the correct method of submitting patches.

@doodaddy64
Collaborator

pushed to garagegames' sixtyfoursupport branch

@doodaddy64 doodaddy64 closed this
@lilligreen lilligreen reopened this
@lilligreen
Collaborator

Reopened to check auto-merge-ability in Github. It's good!

@lilligreen
Collaborator

Or not. :-( The button went from green to grey right after posting that last comment. I'm going to have to hand merge a local copy then.

@lilligreen lilligreen closed this
@lilligreen lilligreen referenced this pull request
Merged

64-bit support #154

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.