A few Questions ...

[Peter Tanski]

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/ 
BackEndNotes>).

> 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/ 
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.


Cheers,
Pete