A few Questions ...

[Simon Marlow]

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