At first I did not have a 64 bit PC so I had a good excuse, but those times are long gone...
We still have the excuse that MinGW32 does not support 64 bit, but we have MinGW-W64 to try
It seems that it'd be easier to get this started on Linux, however, and there's already some basic awareness in the IDE to build in 32 vs 64 bit. The options are still missing a GUI in Project settings however (contributions welcome to add it - http://ecere.com/mantis/view.php?id=743), so we'll have to hack at the project files with a text editor for now...
vendu mentionned the interest to get this 64 bit support in eC going, so here's why I'm bothering with this at all
The problem of 64 bit lies in a few areas...
The eC compiler will need some awareness of the size of data types, and so will the eC runtime.
I'm almost certain some generated C code makes some bad assumptions, and coded code in the runtime and/or compiler as well... Note that ideally a distinction should be made between host and target, so a 64 bit eC compiler should be able to compile eC code meant to run on a 32 bit machine... Ideally, there won't be too much attention that must be given to this, and generated C code should be able to build on both 32 and 64 bit systems (In fact, this is a requirement for the bootstrapping compiler at the minimum, which is generated C code, to be able to run on both 32 and 64 bit!)
So things to watch for: sticking void * in int (I've done that a lot).
e.g. in Window::id, DataRow::tag, etc.
The new collection classes (containers) were thought with 64 bit in mind, but there might still be some issues with them.
The old containers however, which are still used in many areas (especially throughout the compiling tools), must be making a lot of sizeof(int) == sizeof(void *) assumptions. We need to phase them out completely, in favor of the new containers, but for now it might be easier to just fix them to work in both 32 and 64 bit. These are:
- OldArray
- OldList (Along with related classes NamedItem, NamedLink, Item, OldLink)
- BinaryTree (Along with BTNode)
Multiple-data types unions and such are used, and we'll have to be careful about the offset (little-endian vs big-endian 64 bit machines!)
So... here's how I propose to start. First we should try to get a very basic hello world application compiled and running in 64 bit.
Code: Select all
class Hello : Application
{
void Main()
{
PrintLn("Hello, 64 bit!!");
}
}First of all, checkout the dev branch from github @ https://github.com/ecere/sdk/tree/dev .
make yourself some work folder, say /ecere64/
And in there make a subfolder /ecere64/ecereCOM
Copy sdk/ecere/src and sdk/ecere/ecereCOM.epj in there .
Then make a new empty project in /ecere64/hello/ and add the above snippet in to a file called hello.ec
Now we'll text edit these .epj to make them build in 64 bit. We need to add the option "BuildBitDepth" : "Bits64" under the top level options, so Hello.epj will look like this
Code: Select all
{
"Version" : 0.2,
"ModuleName" : "Hello",
"Options" : {
"Warnings" : "All",
"TargetType" : "Executable",
"TargetFileName" : "Hello",
"Libraries" : [
"ecere"
],
"BuildBitDepth" : "Bits64"
},
"Configurations" : [
{
"Name" : "Debug",
"Options" : {
"Debug" : true,
"Optimization" : "None",
"PreprocessorDefinitions" : [
"_DEBUG"
]
}
},
{
"Name" : "Release",
"Options" : {
"Debug" : false,
"Optimization" : "Speed"
}
}
],
"Files" : [
"hello.ec"
],
"ResourcesPath" : "",
"Resources" : [
]
}To link and/or run this Hello application however, we'll need to build ecereCOM in 64 bit as well.
So do a Project/Add project to workspace and add /ecere64/ecereCOM.epj , which you text-edited to build as 64 bit as well. Try to build it, and see how far you get
Once this hello world is going, we can try to build the full ecere runtime, and see how far we get with a GUI application =)
Let's keep this thread going till we can do 64 bit =)
-Jerome