64 bit support

Forum for discussing getting Ecere running on other platforms (iPhone, FreeBSD, SunOS, consoles...) and improving support on existing platforms (e.g. Mac OS X)
jerome
Site Admin
Posts: 608
Joined: Sat Jan 16, 2010 11:16 pm

Re: 64 bit support

Post by jerome »

There's a lot of work to do before we get anything running in 64 bit, from the runtime library to the compiler, which has been daunting, but I guess there's nothing like taking a first step and not looking below! It's a good thing as well that we've taken care of the IDE already, at least in part!

So yes this Binary tree is one place where things will go wrong...

At some point we might need to include <stdint.h> or otherwise get uintptr_t defined.
Remember including headers is always an issue with the bootstrapping system as well...

uintptr_t can be used to define a variable the same size as a pointer (32 or 64 bits)
(The size of long is NOT reliable between different common compilers/platforms).

We could define BTNode's key as a uintptr_t, and use it for CompareKey as well, to keep it 32 bit in 32 bit mode... Or we could simply always make it 64 bit.
The problem is places where BTNode is used, it is often replaced completely by another struct, e.g.:

Code: Select all

public class Method : struct
{
public:
   class_fixed
   char * name;
   Method parent, left, right;
   int depth;
'char * name' here is what maps to the BTNode's key.

But in other places the BTNode key might be used as an int...
So it would have to be mapped to either a uint64 if we decide to standardize on 64 bit, or a uintptr_t (or a pointer, so this particular case wouldn't need to change) if we decide to standardize on the pointer size. By the way, I'd like to define a new eC data type mapping to uintptr_t...
Maybe uintptr? Better suggestion?

Note that we still have the legacy (BinaryTree/BTNode) and new (AVLTree/CustomAVLTree/AVLNode) AVL binary tree implementation. The new one uses the template system, which may require some 64 bit fixes as well. However luckily I had settled on a uint64 for the template types so that it could accomodate all types up to a uint64/double, so we might be covered on there.

At some point we still need to migrate completely to the new containers, starting perhaps from the ecereCOM implementation and then working our way up to the eC compiler library (then we might not even have this problem at all =) Not sure what will get us where we want faster in this case...
redj
Posts: 105
Joined: Sun Jan 17, 2010 10:03 am

Re: 64 bit support

Post by redj »

jerome wrote:In fact pthread and dl should probably be there, they must somehow just be picked up automatically in 32 bit or something...

You'll also notice they are already in the Release config, and in Makefile.ecereCOM (Should probably be moved to Common).
ecereCOM has Release, Debug and Static project configurations. so just confirming, both Debug and Release should have m, dl and pthread libraries. Static on the other hand doesn't need any of them but it's not going to change anything for Static if we specify m, dl and pthread in Common; correct?

-redj
jerome
Site Admin
Posts: 608
Joined: Sat Jan 16, 2010 11:16 pm

Re: 64 bit support

Post by jerome »

Correct. Static libraries don't link in any things.
vendu
Posts: 1
Joined: Tue Jan 08, 2013 5:23 pm

Re: 64 bit support

Post by vendu »

Hey there!

So I finally assembled a 64-bit box and thought I'd join the forums to help with the 64-bit stuff, which I actually promised Jerome months ago. :)

Jerome, I think intptr and uintptr would do as type names; both so we can do negative offsets too.

I was just thinking... Of using long for and unsigned long except when on a Windows setup with 32-bit longs on 64-bit, in which case we could probably use long long, right? We could, of course, add more exceptions, should we encounter such platforms.

Cheers,

/* vendu */
jerome
Site Admin
Posts: 608
Joined: Sat Jan 16, 2010 11:16 pm

Re: 64 bit support

Post by jerome »

Hey vendu :)

Well I don't want to use long, it's such a non-standard type :)

We have int64/uint64 defined already.
And like you said, we really need uintptr/intptr :)

I guess I should get on that ASAP!

-Jerome
jerome
Site Admin
Posts: 608
Joined: Sat Jan 16, 2010 11:16 pm

Re: 64 bit support

Post by jerome »

Hi all!

Version 0.44.04 of the SDK is officially released with 64 bit support!
It also improves FreeBSD and Android support, and solves various bugs.

On Windows, you'll need MinGW-w64.

The SDK will now build with the default architecture of your GCC compiler.
To build for a 32 bit architecture on a 64 bit machine, you can do 'make ARCH=32'.
make ARCH=32 install will try to install libraries in a separate multilib location.

On Windows, installing the 32 bit version will go into Program Files (x86)\Ecere SDK whereas the 64 bit version will go into Program Files\Ecere SDK.

Cheers :D

-Jerome
Post Reply