A few Questions ...
simonmarhaskell at gmail.com
Mon Nov 13 06:54:06 EST 2006
Peter Tanski wrote:
> 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.
There are other free assemblers that we can use, e.g. NASM.
> * 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).
I was referring to the driver that is now part of GHC itself; basically the code
that invokes the various external processes that form part of the compilation
> 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 main issue I see is getting the RTS built. We already build it using GHC as
the compiler, but we'll certainly need to feed it different flags when GHC is
invoking CL.EXE. Also there's the .obj vs. .o issue. Some work will be
required in Cabal, too - assuming that by the time we get around to doing this
the libraries will be building using Cabal.
> 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.
Sure, support for DLLs is high on the priority list. However, you can already
build a DLL from a Haskell library (just not multiple DLLs).
> (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.
Ideally I'd like to refactor the native code generator to separate out all the
architecture-specific stuff into separate files, and make it possible to compile
in more than one backend at the same time (we might even compile in all of them
More information about the Cvs-ghc