#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
