Re: Mercury front-end

Re: Mercury front-end

[Geert Bosch]

On Fri, 26 Jan 2001 08:27:52 +1100, Fergus Henderson wrote:

  On 02-Jan-2001, Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
  > I've implemented an initial version of a Mercury front-end for GCC.
  
  ... and it now bootstraps :->

A new GCC compiler is born! Congratulations! :-) Do you see any
difference in code generated with your new front-end versus the old
one, or do you get pretty much the same mapping as you did before?

  -Geert

Re: Mercury front-end

[Fergus Henderson]

On 26-Jan-2001, Geert Bosch <bosch@gnat.com> wrote:
> On Fri, 26 Jan 2001 08:27:52 +1100, Fergus Henderson wrote:
> 
>   On 02-Jan-2001, Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
>   > I've implemented an initial version of a Mercury front-end for GCC.
>   
>   ... and it now bootstraps :->
> 
> A new GCC compiler is born! Congratulations! :-) Do you see any
> difference in code generated with your new front-end versus the old
> one, or do you get pretty much the same mapping as you did before?

Well, that depends on exactly what you mean by "the old one".
The Mercury compiler has two different back-ends that compile to C.
The code generated with Mercury GCC back-end is almost the same as
that generated with the new "high-level" C back-end, but it is quite
different from the code generated by the original "low-level" C back-end.

The original "low-level" C back-end of the Mercury compiler was based
on an abstract machine, with its own registers and stacks; we
generated code for this abstract machine and implemented the abstract
machine instructions using C macros.  The macros had alternative
definitions depending on whether we were compiling to GNU C, or to
portable ANSI C.  For GNU C, the most frequently accessed abstract
machine registers were mapped to real registers using GNU C's global
register variables feature.  Tail calls were mapped to GOTO
instructions in the abstract machine, which were implemented using
inline assembler labels and GNU C's computed goto extension to jump
from the middle of one C function to the middle of another.  This
approach was of course not officially supported by GNU C, was rather
fragile, and made porting more difficult than But it did work, and it
had the advantage over competing alternatives of (1) being efficient;
(2) supporting tail calls (in 1994!); and (3) being relatively
portable (a lot more so than writing our own native code compiler,
for example).

More recently, we've developed a new back-end for the Mercury compiler
that compiles to a fairly high-level intermediate representation based
on an abstraction of various imperative/OOP languages (C, C++, Java,
and the like).  We then convert this representation to either C,
MS IL (the Microsoft.NET Intermediate Language), Java, or GCC trees.

The assembler code generated by the high-level C back-end and the GCC
back-end is very similar; not exactly the same, but close enough that
I was able to use `diff' on the generated assembler files to help find
bugs.  But that is after I made a couple of changes to the C back-end
to make it more closely match the GCC back-end, in particular using
__builtin_{set,long}jmp and changing the way we generate switches so
that the default case comes first (to better optimize switches with
unreachable default cases).

Note that this is without any information being passed from the
Mercury front-end to the GCC back-end about tail calls; I plan to
do better in that regard.

Compared to the original low-level C back-end, the code generated by
the high-level C back-end is quite different; sometimes better,
sometimes worse.  For the Mercury compiler itself, the new high-level
C back-end beat the low-level back-end by about 10% on Alpha but lost
by a similar amount on x86, if I recall correctly.

The low-level C back-end does a much better job than GCC on a few
optimizations that are sometimes important for the kind of code that
we generate.  One of them is delaying/avoiding stack frame creation.
For functions like

	void foo(arg) {
		if (arg == 0) {
			... base case ...
		} else {
			... recursive case that needs a stack frame ...
		}
	}

GCC will (AFAIK) always create a stack frame for every call to foo(),
whereas for the equivalent Mercury code the Mercury compiler's
"low-level C" back-end will avoid creating a stack frame for calls
which use the base case, if the base case doesn't need a stack frame.

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

Re: Mercury front-end

[Richard Henderson]

On Sat, Jan 27, 2001 at 04:09:49AM +1100, Fergus Henderson wrote:
> The low-level C back-end does a much better job than GCC on a few
> optimizations that are sometimes important for the kind of code that
> we generate.  One of them is delaying/avoiding stack frame creation.

Shrink-wrapping is on the long-term todo list.


r~

Re: Mercury front-end

[Richard Kenner]

    My employer (The University of Melbourne) might perhaps have some
    claim on them.  I will probably be able to persuade them to sign a
    form either disclaiming ownership or assigning the rights to the FSF,
    for the C side of the changes.  For the Mercury side, and the existing
    Mercury compiler, that won't happen, since we (the Mercury group here)
    want the freedom to release the Mercury distribution under different
    licenses in future.

Note that you still have that freedom if you assign the copyright to
the FSF under the standard assignment agreement.

Re: Mercury front-end

[Joe Buck]

>     My employer (The University of Melbourne) might perhaps have some
>     claim on them.  I will probably be able to persuade them to sign a
>     form either disclaiming ownership or assigning the rights to the FSF,
>     for the C side of the changes.  For the Mercury side, and the existing
>     Mercury compiler, that won't happen, since we (the Mercury group here)
>     want the freedom to release the Mercury distribution under different
>     licenses in future.
> 
> Note that you still have that freedom if you assign the copyright to
> the FSF under the standard assignment agreement.

There may be things that you want to do that are not covered by the
standard assignment agreement.  But then, RMS has been known to negotiate
different terms.  It's probably best to discuss it with him.

Mercury front-end

[Fergus Henderson]

Hi all,

Happy new millenium.

I've implemented an initial version of a Mercury front-end for GCC.
I haven't tested it much yet, but (apart from bugs that I haven't
discovered yet ;-), it implements all the standard Mercury language
features.

The front-end consists of the existing Mercury compiler, which is over
200,000 lines of Mercury, plus about 4200 new lines of Mercury and
about 2000 lines of C, which hook it up to the GCC back-end
(rather than compiling to C, as the existing Mercury compiler does).

Now I'm wondering what the next step is.
I plan to post the diff to the mercury-developers mailing list sometime
soon, and eventually to include at least the Mercury side of the changes
in the Mercury distribution.  But I'm not quite sure what to do with
the C side of the changes.  Would it be appropriate to include them
in the standard GCC distribution?  Or would you prefer that we just
include them in the Mercury distribution?

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

Re: Mercury front-end

[Andi Kleen]

Fergus Henderson <fjh@cs.mu.oz.au> writes:

> Now I'm wondering what the next step is.
> I plan to post the diff to the mercury-developers mailing list sometime
> soon, and eventually to include at least the Mercury side of the changes
> in the Mercury distribution.  But I'm not quite sure what to do with
> the C side of the changes.  Would it be appropriate to include them
> in the standard GCC distribution?  Or would you prefer that we just
> include them in the Mercury distribution?


How does the Mercury interface with the C ?


-Andi

Re: Mercury front-end

[Fergus Henderson]

On 01-Jan-2001, Andi Kleen <ak@suse.de> wrote:
> Fergus Henderson <fjh@cs.mu.oz.au> writes:
> 
> > Now I'm wondering what the next step is.
> > I plan to post the diff to the mercury-developers mailing list sometime
> > soon, and eventually to include at least the Mercury side of the changes
> > in the Mercury distribution.  But I'm not quite sure what to do with
> > the C side of the changes.  Would it be appropriate to include them
> > in the standard GCC distribution?  Or would you prefer that we just
> > include them in the Mercury distribution?
> 
> How does the Mercury interface with the C ?

Using Mercury's C interface, of course ;-)

Mercury includes a C interface as a standard part of the language.
For details about Mercury's C interface, see the "C Interface" chapter
of the Mercury language reference manual, which is available on the
Mercury web site, in particular at
< http://www.cs.mu.oz.au/research/mercury/information/doc/reference_manual_toc.html >.

Using this C interface, I've defined a Mercury module which is a
wrapper around the parts of GCC's interface that we need for compiling
Mercury.  For example, this module declares a type `gcc__op', for GCC
tree codes that represent operators, and defines functions such as
`addr_expr', which return values of this type.  These functions are
implemented using `pragma c_code' declarations, which are a bit like
inline asm in GNU C.  Here's an example showing the Mercury code to
implement `addr_expr':

	/* declare `addr_expr' as a function with no arguments
	   returning a value of type `gcc__op' */
	:- func addr_expr = gcc__op.

	/* define `addr_expr' to return the value of the C
	   enumeration constant `ADDR_EXPR' */
	:- pragma c_code(addr_expr = (Code::out), "Code = ADDR_EXPR;").

With the existing Mercury compiler, these get compiled in as inline C
in the generated C code.  With the new Mercury compiler based on the
gcc back-end, the Mercury compiler handles `pragma c_code' declarations
by generating a separate C file containing the code from `pragma c_code'
declarations, wrapped up inside suitable functions, and calls to Mercury
functions such as `addr_expr' get compiled into calls to these
automatically generated C functions.

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

Re: Mercury front-end

[Jeffrey A Law]

  In message < 20010102015053.A1955@hg.cs.mu.oz.au >you write:
  > I plan to post the diff to the mercury-developers mailing list sometime
  > soon, and eventually to include at least the Mercury side of the changes
  > in the Mercury distribution. 
Sounds good.

  >  But I'm not quite sure what to do with
  > the C side of the changes.  Would it be appropriate to include them
  > in the standard GCC distribution?  Or would you prefer that we just
  > include them in the Mercury distribution?
It might be appropriate.  However the first thing that needs to be settled
is the copyright status of the changes (of both your changes and the
existing Mercury code).

jeff

Re: Mercury front-end

[Fergus Henderson]

On 02-Jan-2001, Jeffrey A Law <law@redhat.com> wrote:
> 
> It might be appropriate.  However the first thing that needs to be settled
> is the copyright status of the changes (of both your changes and the
> existing Mercury code).

The existing Mercury code is GPL'd / LGPL'd.  We also use the Boehm
(et al) GC, which has a BSD-style license (without the advertising
clause).

The C side of my changes are a derivative work of Tim Josling's `toy'
GCC front-end.  The Mercury side of my changes are in a few parts a
derivative work based on existing code in the Mercury compiler.

The new part of my changes are copyright by me, I believe.
I would be happy to sign the rights over to the FSF.

My employer (The University of Melbourne) might perhaps have some
claim on them.  I will probably be able to persuade them to sign a
form either disclaiming ownership or assigning the rights to the FSF,
for the C side of the changes.  For the Mercury side, and the existing
Mercury compiler, that won't happen, since we (the Mercury group here)
want the freedom to release the Mercury distribution under different
licenses in future.  But some kind of joint ownership might be
acceptable, if that is possible.

Where can I obtain the appropriate forms?

P.S. For completeness, here's an extract from the README file in the
Mercury distribution, which states the license conditions for the
relevant parts of the Mercury distribution (I've omitted the license
conditions for the example Mercury programs that we distribute,
since that would be just "mere aggregation").

 | This directory contains the source distribution for the University of
 | Melbourne Mercury compiler, version DEV.
 | 
 | 	The Mercury implementation is free software, but it is Copyright
 | 	(C) 1993-2001 The University of Melbourne.  It is distributed
 | 	under the terms of the GNU General Public License.  See the file
 | 	COPYING for copying permission.
 | 
 | 	The Mercury library and runtime (the files in the library and
 | 	runtime subdirectories) are distributed under the terms of the
 | 	GNU Library General Public License.  See the file COPYING.LIB for
 | 	copying permissions for those files.
 | 
 | 	If those licencing arrangements are not satisfactory, please
 | 	contact us!  We are willing to offer alternative arrangements,
 | 	if the need should arise.
 | 	
 | The subdirectory `boehm_gc' contains a slightly modified copy of
 | version 5.0alpha3 of the conservative garbage collector distributed
 | by Hans Boehm:
 | 
 | 	Copyright 1988, 1989 Hans-J. Boehm, Alan J. Demers
 | 	Copyright (c) 1991-1995 by Xerox Corporation.  All rights reserved.
 | 	Copyright (c) 1996-1999 by Silicon Graphics.  All rights reserved.
 |	Copyright (c) 1999 by Hewlett-Packard Company. All rights reserved.
 | 
 | 	THIS MATERIAL IS PROVIDED AS IS, WITH ABSOLUTELY NO WARRANTY
 | 	EXPRESSED OR IMPLIED.  ANY USE IS AT YOUR OWN RISK.
 | 
 | 	Permission is hereby granted to use or copy this program for any
 | 	purpose, provided the above notices are retained on all copies.
 | 	Permission to modify the code and to distribute modified code is
 | 	granted, provided the above notices are retained, and a notice
 | 	that the code was modified is included with the above copyright
 | 	notice.
 | 
 | A few files (config.guess, config.sub) are derived from code that is
 | copyright by the Free Software Foundation, Inc, and are distributed
 | under the GNU General Public License version 2.

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

Re: Mercury front-end

[Alexandre Oliva]

On Jan  3, 2001, Fergus Henderson <fjh@cs.mu.oz.au> wrote:

> But some kind of joint ownership might be acceptable, if that is
> possible.

When you assign something to the FSF, the FSF grants you the right to
re-license the code you've assigned with whatever license you may see
fit.  Which doesn't mean you'd be able to re-license any GCC front-end
with whatever license you want, of course, but willing to re-license
soem code as non-GPL can never be a reason for not assign code to the
FSF.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Mercury front-end

[Fergus Henderson]

On 02-Jan-2001, Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
> I've implemented an initial version of a Mercury front-end for GCC.

... and it now bootstraps :->

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

Re: Mercury front-end

[Fergus Henderson]

On 26-Jan-2001, Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
> On 02-Jan-2001, Fergus Henderson <fjh@cs.mu.OZ.AU> wrote:
> > I've implemented an initial version of a Mercury front-end for GCC.
> 
> ... and it now bootstraps :->

... and it is now passes all of the relevant tests in the Mercury test suite.

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