Author Topic: Offering build platform. (Read 19646 times)

bacon665 · « **on:** May 06, 2009, 03:10:57 am »

Hi, I noticed there was very little mention of x64 builds for winblows.
I have experience compiling on Unix/Linux and can do some basic code editing so heres the deal:
I have a new 64bit system and windows vista home premium x64 and id like to build the x64 binary packages on it so everyone can use it, but i need a little guidence in doing so. I wish to enable SSE3 and multithreading and my system has the following specs.

Proc: AMD Phenom x4(AM2+) 9950 Black edition.
Ram: 4 gig patriot Viper 1024mghz DDR2
Hard disk: (surely it wont take an extra 500 gigs)
Graphics:
Onboard - Radeon HD 3500
PCI-E - Nvidia 9600GT(not installed but available if needed for build)
Gigabyte ETH
HD audio.

Im even willing (should i get stuck) to let one of the devs use teamveiwer or VNC to work on it.

kevlarman · « **Reply #1 on:** May 06, 2009, 04:21:23 am »

there isn't currently a 64 bit version of mingw for windows, so the 64 bit build will have to wait, though there isn't much benefit other than increased loading times.

bacon665 · « **Reply #2 on:** May 06, 2009, 04:48:49 am »

there is a 64bit mingw lol.
its been out for a while now.
and yes you get an increase in the number of vectors processed per cycle. and now that explorer. exe has been divided and they added a program to control the compatability libs in windows you save on memory too. (even with the double sized pointers)

SlackerLinux · « **Reply #3 on:** May 06, 2009, 12:17:51 pm »

no reason why 64bit mingw shouldn't compile trem

talk to frak and doomagent they were looking into it a while back.

Amanieu · « **Reply #4 on:** May 06, 2009, 12:56:06 pm »

The x64 JIT won't compile on windows.

Odin · « **Reply #5 on:** May 06, 2009, 06:14:26 pm »

Please, it's "x86_64", not "x64."

gimhael · « **Reply #6 on:** May 06, 2009, 07:09:31 pm »

It's not that simple: x64 is the name used by Microsoft, x86_64 is the original name used by AMD and also used in Linux. AMD switched to the name amd64, Intel called it originally EM64T and later Intel64. (If anybody still isn't confused now, all these names refer to the 64-bit extension of the ia32 architecture, but of course the name ia64 refers to a completely different architecture.)

bacon665 · « **Reply #7 on:** May 06, 2009, 09:37:53 pm »

Quote

The x64 JIT won't compile on windows

What about compiling the 32 bit version and linking it in the 64?

player1 · « **Reply #8 on:** May 07, 2009, 02:54:36 am »

i hope ur moar thorough at inspecting ur code than ur quotes

j/k gl

bacon665 · « **Reply #9 on:** May 07, 2009, 03:01:42 am »

What on earth could you possibly mean =P

Overdose · « **Reply #10 on:** May 07, 2009, 05:32:34 am »

Quote from: player1 on May 07, 2009, 02:54:36 am

i hope ur moar thorough at inspecting ur code than ur quotes

j/k gl

I seriously lol'd.

I'll volunteer my [64-bit Intel] system as well if it means getting a native x64 client for Windows.

frazzler · « **Reply #11 on:** May 07, 2009, 09:34:24 am »

I don't understand. Why are you concerned about fancy game file crap when you could be cranking up the actual game and enjoying it?

Bissig · « **Reply #12 on:** May 07, 2009, 02:15:55 pm »

Quote from: frazzler on May 07, 2009, 09:34:24 am

I don't understand. Why are you concerned about fancy game file crap when you could be cranking up the actual game and enjoying it?

Why are you spamming all threads with nonsense just to increase your post count?

Amanieu · « **Reply #13 on:** May 07, 2009, 02:21:30 pm »

The 32-bit JIT will NOT work on 64-bit systems, since it generates 32-bit code.

(Well I guess I could have that code run in a 32-bit code segment, but that would take more effort than just porting the JIT to x64 Windows

)

gimhael · « **Reply #14 on:** May 07, 2009, 02:36:45 pm »

You could run the JIT code in a separate 32 bit process and communicate via sockets, but that would probably be even slower than the interpreter.

bacon665 · « **Reply #15 on:** May 07, 2009, 05:22:02 pm »

All the 32bit API's are present in the 64 versions.
so native 32 bit code can run. and ive seen a couple threads on MSDN where the 64 called on a 32 bit process.

David · « **Reply #16 on:** May 07, 2009, 06:07:40 pm »

64bit process calling a 32bit process is very very different to 64bit code running 32bit code.

bacon665 · « **Reply #17 on:** May 07, 2009, 07:14:46 pm »

Either way im sure one of them can be done.
What about using AOT GNU Lightning or libJIT to change it over?

Quote

64-bit NGEN Optimizations
For the purposes of this article, I've referred to the JIT and NGEN together as the JIT. With the 32-bit version of the CLR, both the JIT compiler and NGEN perform the same optimizations. This is not the case for the 64-bit version, where NGEN does significantly more optimization than the JIT.
The 64-bit NGEN takes advantage of the fact that it can spend a lot more time compiling than a JIT can since the throughput of the JIT directly affects the response time of the application. I specifically mention the 64-bit NGEN in this article as it has been relatively well-tuned to work with C++-style code and it does some optimizations that greatly help C++, such as the Double Thunk Elimination optimization, which other JITs and NGENs do not do. The 32-bit JIT and the 64-bit JIT were implemented by two different teams within Microsoft using two different code bases. The 32-bit JIT was developed by the CLR team, whereas the 64-bit JIT was developed by the Visual C++ team and is based on the Visual C++ code base. Because the 64-bit JIT was developed by the C++ team, it is more aware of C++-related issues.

Double Thunk Elimination
One of the most important optimizations that the 64-bit NGEN performs is known as double thunk elimination. This optimization addresses a transition that happens when calling a managed entry point from managed code, through a function pointer or virtual call in C++ code compiled with the /clr switch. (This does not happen in /clr:pure or /clr:safe compiled code. ) This transition occurs because neither the function pointer nor the virtual call have the necessary information at the callsite to determine if they're calling into a managed entry point (MEP) or an unmanaged entry point (UEP).
For backwards compatibility, the UEP is always selected. But what if the managed callsite is actually calling a managed method? In this case, there would be a thunk that goes from the UEP to the target managed method, in addition to the initial thunk from the managed callsite to the UEP. This managed-to-managed thunk process is what is commonly referred to as the double thunk.

Source: http://msdn.microsoft.com/en-us/magazine/cc163855.aspx

could something like that be of use?

kevlarman · « **Reply #18 on:** May 07, 2009, 08:50:06 pm »

Quote from: bacon665 on May 07, 2009, 07:14:46 pm

could something like that be of use?

no

bacon665 · « **Reply #19 on:** May 07, 2009, 09:14:05 pm »

Quote from: kevlarman link=topic=10983. msg165339#msg165339 date=1241725806

Quote from: bacon665 link=topic=10983. msg165333#msg165333 date=1241720086
could something like that be of use?
no

That means very little coming from you since you cant even seem to google for the 64bit MinGW

bacon665 · « **Reply #20 on:** May 07, 2009, 09:17:36 pm »

For anyone who else who does not know where to look.
Heres the MinGW 64 http://mingw-w64.sourceforge.net/

Bissig · « **Reply #21 on:** May 08, 2009, 01:58:53 am »

Quote from: bacon665 on May 07, 2009, 09:17:36 pm

For anyone who else who does not know where to look.
Heres the MinGW 64 hxxp: mingw-w64. sourceforge. net/

Why are you obfuscating the links you post?

Archangel · « **Reply #22 on:** May 08, 2009, 02:13:54 am »

he isn't.

Amanieu · « **Reply #23 on:** May 08, 2009, 05:22:23 am »

Blame Khalsa

Bissig · « **Reply #24 on:** May 08, 2009, 10:45:48 pm »

Quote from: Amanieu on May 08, 2009, 05:22:23 am

Blame Khalsa

Well, maybe it should default to only obfuscate links in sigs?

bacon665 · « **Reply #25 on:** May 09, 2009, 03:12:27 am »

would putting it in quote or a http:sourceforge.net/projects/mingw-w64/
?
ok so the [ link ] didnt work
i could just tell you to google "MinGW 64"

so how about back on topic.
If JIT wont compile is it possible to reconvert it to AOT?
With the extra headroom and increased amount of integers processed per clock inversion it shouldnt really impact game play.

And another question would be swapping the engine.
I noticed the old one was just an add on for the quake engine so you could use one of the hundreds of replacement engines right?

Archangel · « **Reply #26 on:** May 09, 2009, 08:10:16 am »

shut up

bacon665 · « **Reply #27 on:** May 10, 2009, 01:38:22 am »

Quote

shut up

If you dont wish to contribute then why did you even post?

Archangel · « **Reply #28 on:** May 10, 2009, 02:46:26 am »

Quote from: Archangel on May 09, 2009, 08:10:16 am

shut up

bacon665 · « **Reply #29 on:** May 10, 2009, 03:30:07 am »

WTF is your problem?

News:

Author Topic: Offering build platform. (Read 19646 times)

Archangel

Archangel

Archangel