I popped your comments into the Trac task S
| -----Original Message----- | From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter Tanski | Sent: 09 November 2006 20:17 | To: Simon Marlow | Cc: [EMAIL PROTECTED]; Ian Lynagh | Subject: Re: A few Questions ... | | On Nov 6, 2006, at 6:12 AM, Simon Marlow wrote: | | Sorry for the late reply. I had to work through a bit of | miscellaneous drudgery and make time to review the Native Code | Generator (NCG). I have some notes on the new NCG (mostly from the | comments in the source code) and will post them on the new Commentary | wiki page soon--or not, if you would rather start that yourself. | | > Peter Tanski wrote: | >> making GHC "Windows-native," | > | > I think this is a good idea, in fact I've suggested it before. | | I do remember your suggestion though I can't recall which message | thread it was in just now--too bad, really, since I also (hazily) | recall several other good points you made on this issue. This was | also listed under potential proposals for Internships, though I think | an internship applicant would prefer to do something more research- | oriented so no one should be unhappy if the job gets done. After | all, there seems to be a very large body of work available for | improving the NCG (anyone interested could get a start from your | BackEndNotes, at <http://hackage.haskell.org/trac/ghc/wiki/ | BackEndNotes>). | | > We wouldn't be able to compile via-C using the MS C compiler, | > because adapting the mangler is too much work, but in any case we | > want to move away from the mangler and use the native code | > generator instead. | | Definitely. It is too bad that the mangler is so much work--via-C | would pass the extra linker-compatibility work to the C compiler. | The future is native asm compilation so that would only be a | temporary fix, anyway. | | > I've created a Task: | > | > http://hackage.haskell.org/trac/ghc/ticket/989 | | Right on. 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. | | | Cheers, | Pete | | | | | _______________________________________________ | Cvs-ghc mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/cvs-ghc _______________________________________________ Cvs-ghc mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/cvs-ghc
