Mercury port to WinNT native

Fergus Henderson fjh at cs.mu.OZ.AU
Sat Oct 3 00:42:04 AEST 1998


On 02-Oct-1998, Renaud Paquay <rpa at miscrit.be> wrote:
> [...] as a part of the ARGO project,
> we plan to convert the whole mercury run-time into a native Win32-DLL
> to remove the dependency with CygWin.dll. (and to reduce the size of
> the "Hello world" executable file.)

This is a good idea.

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

I would recommend trying with mingw32 first.  That way, you only have
to solve dependencies on cygwin rather than dependencies on gcc.

Ideally you should be able to set things up so that users can compile
Mercury code with mingw32 gcc and link it with code compiled with MS C++.

> So, I have a few questions:
> 1. Do you see any major technical problem to this approach?
>    (I think about conflicts with the memory manager, or
>     hyphothesis on the memory layout of code and data segments, etc)

Compiling with MS C will result in significantly lower performance
than if you compile with gcc.  Apart from that, I don't think there
are any major technical problems.

> 2. Do you have an estimation of how many functions the runtime exports
>    to mercury applications?

If you want such an estimate, I suggest you use `nm' or `objdump'.

However, if the reason that you are asking is because you are wondering
about hard-coding the DLL export list, then I recommend that you do not
do that, because it would lead to undesirable maintenance work.
Instead, it would be better to write code to create the DLL export
list automatically (using `nm' or `objdump').

The current Mercury distribution includes code for doing that
in the file `Makefile.DLLs'.

> 3. Does the mercury run-time only exports functions, or functions _and_
>    variables? (I've had problems exporting variables from a DLL)

It imports functions _and_ variables.
Exporting variables from a DLL is indeed more difficult,
but `Makefile.DLLs' has some solutions for that too.

> 4. Does it rely on specific GCC-extensions (global register variables, global
>    goto's, etc)?

Mainly only for performance -- the code will work without those extensions,
but it will run significantly slower.

However, the code in the current Mercury distribution also contains a
number of places where some minor dependencies on GCC extensions have
accidentally crept into our source code.  Peter Ross is currently in
the process of fixing those.  I would advise that you delay trying to
port to MS C until after we have fixed them.

Cheers,
	Fergus.

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



More information about the developers mailing list