A few Questions ...
simonpj at microsoft.com
Fri Nov 10 03:58:39 EST 2006
I popped your comments into the Trac task
| -----Original Message-----
| From: cvs-all-bounces at haskell.org [mailto:cvs-all-bounces at haskell.org] On Behalf Of Peter Tanski
| Sent: 09 November 2006 20:17
| To: Simon Marlow
| Cc: cvs-ghc at haskell.org; 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/
| > 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/
| * 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
| 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.
| Cvs-ghc mailing list
| Cvs-ghc at haskell.org
More information about the Cvs-ghc