Mercury port to WinNT native

[Fergus Henderson]

On 02-Oct-1998, Renaud Paquay <rpa at miscrit.be> wrote:
> Fergus Henderson wrote:
> > > Also, we want to compile the mercury run-time with MS C++.
> > 
> > This is not such a good idea, because of the impact on performance
> > (see below).
> 
> Maybe I was not clear enough:
> We first want to convert only the mercury _runtime_, i.e. 
> the C files in the "runtime" directory. 

Ah.  This isn't possible.  The files in the runtime also make
extensive conditional use of the same GNU C extensions.

That is, the only way to build things with MS C is by using `--grade
none.gc' instead of `--grade asm_fast.gc'.  But you must build the
runtime in the same grade as the Mercury standard library and the
Mercury user's program.  So you can compile the runtime with MS C and
the library etc. with gcc, but only if you compile the library with
`--grade none.gc', which will give you the same efficient hit.

Check the benchmarks on our WWW page for comparisons of the
efficiency of `none.gc' vs `asm_fast.gc' (or `none' vs `asm_fast').

> I understand that the C-code generated by the
> mercury compiler is much more efficient with gcc (because of the
> use of specific gcc features), but concerning the mercury runtime, 
> I don't see why MS C would be so bad compared to gcc wrt compiling
> indentical source files.

Yes, it probably wouldn't be a major difference either way.

> Our hypothesis is most of the "cygwin" dependencies stands
> in the mercury runtime, not in the C-code generated by the
> Mercury from ".m" files. (We may be wrong, of course.)

Well, I really don't know how many cygwin dependencies there are --
I think most of them are already conditionalized.  Of the ones
that remain, I would guess that most are in the runtime, but quite
a few will be in `pragma c_code' fragements in the standard library.

> So, our work plan would be the following:
> 1. We convert the runtime into a Win32 DLL compiled with MS C.
> 2. We let the mercury compiler generate gcc code, but we slightly
>    modify the compilation process so that we link mercury applications
>    to the Win32 DLL, instead of the static runtime Mercury library.

I would suggest the following alternative work plan:

	A.  Convert the runtime and library into Win32 DLLs.
	    Actually for the GNU toolset most of the work has already
	    been done, I hope, by the file Makefile.DLLs.
	    But it needs testing, and the process could perhaps
	    be simplified (I think Mumit Khan may have some better tools
	    on his WWW page).

	B.  Convert the runtime and library to use only the standard
	    ANSI C library, by conditionalizing any remaining
	    dependencies on POSIX features provided by cygwin32.dll.
	    This will enable it to be compiled with mingw32,
	    which is a version of gcc that links with the MS C
	    DLL for its runtime library.

	C.  Convert the runtime and library to work with POSIX C compilers
	    other than gcc, such as lcc or MS C.

Note that each of these steps can be carried out independently.
Peter Ross <petdr at cs.mu.oz.au> is currently working on step C,
using lcc.

Your step 1 amounts to applying all of steps A, B, and C to the
runtime, except that for step A instead of using the GNU tools 
to build DLLs you will use the MS tools.

BTW, we have just split off the code for the debugger into two
new libraries.

> That would let us generate mercury applications that do not depend
> on cygwin to run.
> 
> Regarding performance, we would then be able to compare the two types
> of applications:
> a. Applications compiled with mercury + gcc and linked to the static 
>    runtime library dependent on CygWin.
> b. Applications compiled with mercury + gcc, but linked to the
>    Win32 native DLL.
> 
> Of course, the test is not fair, because of the CygWin overhead.
> 
> But, if at that point, "b." applications are slower than "a." ones, 
> then we can definitively abandon MS C, and go to mingw32.

The odds are very high indeed that "b." applicates will be slower than
"a." ones, because "b." applications will need to use grade "none.gc"
instead of grade "asm_fast.gc".

> > I would recommend trying with mingw32 first.  That way, you only have
> > to solve dependencies on cygwin rather than dependencies on gcc.
> 
> You're right, except that I know much better the MS VC compiler
> than mingw32. So, I believe it will be easier, for me, to start
> directly with MS VC.

Well, if you start with MS VC, you will need to solve problems
A, B, and C, which will result in duplication of work since problem A
is already mostly solved for the GNU toolset and since Peter Ross is already
working on problem C.  If you start with mingw32 then A is already mostly
done, and you can work just on problem B while we work on problem C.

This is why I think it would be better to try with mingw32 even if
you are more familiar with MS VC.

> The reason we want to try MS C is that we believe (we may be wrong 
> again) that MS C is better than gcc at generating code for the WinNT
> platform, because WinNT itself is written with MS C!

I would be surprised if MS VC generates significantly faster code than
recent versions of gcc (i.e. egcs).  I would not be that surprised
if egcs generated faster code than MS VC, though.

But even if MS VC is a little better than gcc, the difference is likely
to be swamped by the difference between the `none' and `asm_fast' grades --
and `asm_fast.gc' will only work with gcc.

-- 
Fergus Henderson <fjh at cs.mu.oz.au>  |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>  |  of excellence is a lethal habit"
PGP: finger fjh at 128.250.37.3        |     -- the last words of T. S. Garp.