64-bit windows version?

[Peter Tanski]

> skaller wrote:
>
>> On Tue, 2007-06-19 at 12:23 +0100, Simon Marlow wrote:
>>
>>> Bulat Ziganshin wrote:
>>>
>>>> Hello glasgow-haskell-users,
>>>>
>>>> are you plan to implement 64-bit windows GHC version?
>>>>
>>> The main thing standing in the way of this is the lack of a 64- 
>>> bit port of
>>> mingw.
>>>
>>
>> Why do you need mingw? What's wrong with MSVC++?

The largest problem is the build system: GHC uses autoconf with  
custom makefiles.  I have looked into porting the whole thing to a  
Visual Studio project, using SCons (unreliable), CMake (limited  
command line abilities--good for a one-shot build but really just a  
"safe" lowest-common-denominator version of Make), Waf (another  
python-based build system that started as a fork of SCons for the  
KDevelop changeover from Autotools) and Jam.  I would prefer to use  
Jam but I'm afraid I would be the only one who would ever want to  
support it.  Nothing has the auto-configuration abilities you (John)  
built into the Felix Interscript-based system but I do not porting  
the build system (at least) to Interscript would go over well with  
anyone else who wanted to maintain it and the build itself would  
require heavy customisation.  I have tested all of these on a small  
scale (the replacement-Integer library).  The best option seems to be  
to create a VS project (not trivial--lots of glue) so a user may also  
call that from Make (if under Mingw) or pure DOS.

There is also some gcc-specific code in the RTS (inline assembler,  
use of extern inline, etc.)  By the way, as of gcc-4.2 (I believe; I  
know it is true for gcc-4.3)  the use of 'extern inline' now conforms  
strictly to the C99 standard so we will have to add the option '- 
fgnu-89-inline' to get the old behaviour back--'extern inline' is  
used in some of the headers.  Converting those 'extern inline's to  
'static inline' or best yet plain 'inline' would also solve the  
problem.  Ian Taylor's message at http://gcc.gnu.org/ml/gcc/2006-11/ 
msg00006.html describes this in greater detail; his proposal was  
implemented.

> I don't think we'll be able to drop the mingw route either, mainly  
> because while
> the MS tools are free to download, they're not properly "free", and  
> we want to
> retain the ability to have a completely free distribution with no  
> dependencies.

I don't know of any completely free 64-bit compilers for Windows.   
The Intel compilers are free for 30-day evaluation but everything  
else is for Win32.  For the base Win32-native port there are many  
compilers available but I have mostly worked on using CL and Yasm  
(assembler) as replacement back-end compilers for GHC.

> There are people that want a Cygwin port too; personally I think  
> this is heading
> in the wrong direction, we want to be more "native" on Windows,  
> using the native
> object format and interoperating directly with the native Windows  
> tools.

Cygwin has a real problem with gcc: it is far behind everything else  
(gcc-3.4.4, though Mingw isn't much better) and it doesn't look like  
that will change anytime soon.  It  is also only 32-bit, I believe.

Cheers,
Pete