Re: [GHC] #989: Windows native port
#989: Windows native port -+-- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal| Milestone: _|_ Component: Compiler | Version: Keywords:| Os: Windows Architecture: x86 | Failure: None/Unknown Difficulty: Difficult (2-5 days) |Testcase: N/A Blockedby:|Blocking: Related:| -+-- Changes (by ihameed): * cc: idhameed@… (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/989#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #989: Windows native port
#989: Windows native port -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: Keywords:| Testcase: N/A Blockedby:| Difficulty: Difficult (2-5 days) Os: Windows | Blocking: Architecture: x86 | Failure: None/Unknown -+-- Changes (by dagit): * cc: dagitj@… (added) Comment: Being able to use MS compiler tool chain would be useful to me in the following two ways: * 64bit Haskell binaries (yay, 8gigs of ram!) * Directly use foo.lib files instead of using gendef/dlltool to (hopefully) construct a .a file. This comes up when trying to use OpenCL with Haskell on windows. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/989#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #989: Windows native port
#989: Windows native port -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: Keywords:| Testcase: N/A Blockedby:| Difficulty: Difficult (2-5 days) Os: Windows | Blocking: Architecture: x86 | Failure: None/Unknown -+-- Comment(by simonmar): @dagit: using the MS compiler chain by itself wouldn't give us a 64-bit Windows port, though it would mean that we don't depend on a working 64-bit mingw port. See #1884. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/989#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #989: Windows native port
#989: Windows native port -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: Keywords:| Testcase: N/A Blockedby:| Difficulty: Difficult (2-5 days) Os: Windows | Blocking: Architecture: x86 | Failure: None/Unknown -+-- Changes (by dterei): * cc: dterei (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/989#comment:8 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #989: Windows native port
#989: Windows native port -+-- Reporter: simonmar |Owner: Type: task | Status: new Priority: normal|Milestone: _|_ Component: Compiler | Version: Keywords:| Testcase: N/A Blockedby:| Difficulty: Difficult (2-5 days) Os: Windows | Blocking: Architecture: x86 | Failure: None/Unknown -+-- Changes (by fryguybob): * cc: fryguybob@… (added) * failure: = None/Unknown -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/989#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #989: Windows native port
#989: Windows native port --+- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal| Milestone: _|_ Component: Compiler |Version: Severity: normal| Resolution: Keywords:| Difficulty: Difficult (1 week) Testcase: N/A | Architecture: x86 Os: Windows | --+- Changes (by sharpe): * version: 6.7 = Comment: Win port of gmp at [http://fp.gladman.plus.com/computing/gmp4win.htm], perhaps move gmp out of dist altogether and only link w/ .so or .dll? Support utils (cgprof, hp2ps,.. etc.) need minor modifications to build and keep cl from choking on e.g. some exotic C macros (and simple ones such as macros suffixed with semi-colon). RTS is more challenging as it contains a mix of C89, C99, C++ code which gcc happily compiles; minor inconsistencies (STATIC_INLINE here, static inline there), gcc extensions not supported by cl, inline assembly, void pointer arithmetic etc. Adapting the build system is pretty terrible (esp. proper autoconf,libtool), custom make rules, custom config.h, custom mk files and some custom Makefile.win32 do the trick but are more difficult to maintain in the future (cmake?). Used winsock is deprecated, also i will need to look into signal handling as this doesn't behave properly (mingw?). Registered boot attempts fail with alignment errors, as of yet not resolved (-mix gcc/cl?); will continue on unregistered 6.4 series builds. Haven't got to real low-level stuff, YASM seems ok and is easily integrated w/ VS2008. prepping the environment is pretty easy once you've got around the unixy build system (include vcvars variables PATH,LIBPATH,INCLUDE etc.), btw utils/pwd does not work in mingw using series 6.8.2 (easily resolved). merging changes will be another fun item. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/989#comment:4 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #989: Windows native port
#989: Windows native port --+- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal| Milestone: _|_ Component: Compiler |Version: Severity: normal| Resolution: Keywords:| Difficulty: Difficult (1 week) Testcase: N/A | Architecture: x86 Os: Windows | --+- Changes (by NeilMitchell): * cc: [EMAIL PROTECTED] (added) -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/989#comment:5 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #989: Windows native port
#989: Windows native port --+- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal| Milestone: _|_ Component: Compiler |Version: 6.7 Severity: normal| Resolution: Keywords:| Difficulty: Difficult (1 week) Testcase: N/A | Architecture: x86 Os: Windows | --+- Comment (by simonmar): A plausible plan seems to be to use [http://www.tortall.net/projects/yasm/ YASM], which can generate Windows object files and understand GAS syntax. This way the changes to the NCG would be minimal, and hence we have a shorter path to getting something working. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/989 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #989: Windows native port
#989: Windows native port --+- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal| Milestone: _|_ Component: Compiler |Version: 6.7 Severity: normal| Resolution: Keywords:| Difficulty: Difficult (1 week) Testcase: N/A | Architecture: x86 Os: Windows | --+- Changes (by igloo): * milestone: = _|_ -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/989 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #989: Windows native port
#989: Windows native port --+- Reporter: simonmar | Owner: Type: task | Status: new Priority: normal| Milestone: Component: Compiler |Version: 6.7 Severity: normal| Resolution: Keywords:| Difficulty: Difficult (1 week) Testcase: N/A | Architecture: x86 Os: Windows | --+- Comment (by simonpj): Notes from Peter Tanski The only caveat would be that the free version of MASM (an add-on to Visual C++ Express) is licensed for non-commercial purposes only. Commercial Windows developers would have to purchase a full version of VC++. The most universal solution would be to restrict the syntax from the pretty-printer to use assembler directives and macros common to both MASM and IAS (Intel ASsembler), with some special attention to linker differences between the two. Here are a few notes on Task #989: * Task point 1: pretty printing MS/Intel asm syntax Most of this seems to be concentrated in compiler/nativeGen/ PprMach.hs, with a macro added to NCG.h. Depending on how much you want to interoperate directly with .NET and other non-C languages, the pretty-printer for assembly output may be only part of the work: we might add special COFF sections to compiler/ nativeGen/AsmCodeGen.lhs. * Task point 2: compiling via Microsoft's CL compiler Fun. Once we have gotten over point 4 (modifications to driver, build system, etc.). * Task point 3: drop dependencies on mingw32 functionality in the libraries Is there a Windows-version of readline, or a Windows-native version of readline available? Even if I don't finish the replacement-GMP library before this, if I recall correctly, GMP has a Windows-native version (as a DLL, no less). Are there any other library dependencies? Windows-native versions of Perl are available. * Task point 4: modifications to driver, build system, etc. driver: DOS batch file or Perl (GHC users will need Perl installed to run the mangler anyway); might also be a very small C program (especially if you want to have a splash screen when GHC starts up). build system: small but pervasive modifications for compiler dependencies, etc.; as a general cleanup matter it might be nice to organise these sorts of dependencies to add other compilers later. The one problem I think people will run into is setting up the paths in MSYS to use the Windows tools--not a GHC-support issue, really, but many questions will be raised about it so we might head them off with lots of build-documentation. There are several related points to this project: (1) for general Windows interoperability, GHC will need to produce DLLs, at least: .NET or other Microsoft languages, such as VB, cannot include foreign code from static libraries. (2) once GHC may produce more than one type of assembler output, would it be too much trouble to give it a cross-compiler option, say -arch i386 (compiler/nativeGen/PprMach.hs seems to use IF_ARCH_... statements) or the GCC option, -b i386v? A cross- compile option would probably require changing the compiler/utils/ Outputable.CodeStyle data constructor AsmStyle to contain several different sub-styles (Intel, ATnT) and clutter up the code in PprMach.hs, at least for i386_TARGET_ARCH. Of course floatToBytes and doubleToBytes (converting endianness to host byte order) would also have to change. (Note: the reference in PprMach.hs:2418 to PprAbs seems to refer to an old module, PprAbsC, which is no longer used, correct?) The easy, host-target-compiler-only solution might be to create a new macro, IF_OS_windows(x,y), in NCG.h and a new Ppr section for the MASM/Intel syntax in PprMach.hs. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/989 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: [GHC] #989: Windows native port
Hello GHC, Monday, November 6, 2006, 2:12:25 PM, you wrote: * Convert the pretty printer in the i386 NCG to generate MS/Intel syntax instead of ATT syntax. We can then generate assembly code that MASM can grok. may be i will look into it. for me main problem is to compile ghc itself, but if i will finally arrange this, at least i know both assemblers i'm very interested in implementing this ticket because intel с compiler for windows in visual с -compatible and it is the compiler that generates fastest code in the world (+10% against gcc, afaik). so if my C libraries that i link to haskell program, will be able to compile via intel c, my program should become 10% faster (it's speed inn't depended on haskell code) -- Best regards, Bulatmailto:[EMAIL PROTECTED] ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
