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
pipeline.
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
by default).
Cheers,
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
