[m-dev.] Thoughts on binary back-ends

[Ralph Becket]

> From: Fergus Henderson [mailto:fjh at cs.mu.OZ.AU]
> Sent: 21 June 2001 02:58
> 
> On 19-Jun-2001, Ralph Becket <rbeck at microsoft.com> wrote:
> > I've been thinking about compiler back-ends and been looking at
> > C-- and MLRISC and so forth (I admit it's not something I've
> > studied extensively).  These are some preliminary thoughts on
> > the subject - I'd be interested to hear other people's views
> > and opinions.
> 
> What problem are you trying to solve?

* Compilation time.
* Access to/control over stack frame format (e.g. it might be 
interesting to examine cactus stacks for concurrency).
* More freedom in exploring GC and threading mechanisms.
* Control of register allocation policy esp. w.r.t. holding globals
in registers.
* Control over calling conventions (e.g. we'd like to have proper
tail calls.)

> You seem to be proposing a particular design, but I didn't understand
> your motivation in proposing this particular design or how it was
> intended to improve on existing approaches.

Going via C seems rather heavyweight given the job the C compiler
is being asked to do.  The motivation is largely similar to that
of the C-- project; I suppose what I'm really interested in is
whether the C-- approach is the right one.  The mechanism I outlined
was mainly thinking out loud about some of what would be involved.

> There's actually a lot of work to writing an efficient native code
back-end.
> E.g. as well as the things above, you need to handle
> 	- scheduling
> 	- generation of PIC (or not)
> 	- handling gp (global pointer) registers
> 	  (for PIC code on some architectures)
> 	- etc.
> 
> It's definitely a non-trivial amount of work and the code would
require
> a non-trivial amount of maintenance.

Sure, but it doesn't seem to me to be a huge amount of work and
once you've covered x86 and the C calling conventions on Linux and
Windows you've covered most of the interesting bases.  The RISC
architectures are all sufficiently similar that I imagine most of
the effort in the first RISC conversion would make subsequent ports
much easier.  Still, it's quite possible that I'm being rather naïve 
about the amount of work involved.

By the way, why do you think it would require non-trivial amount of
maintenance?

- Ralph
--------------------------------------------------------------------------
mercury-developers mailing list
Post messages to:       mercury-developers at cs.mu.oz.au
Administrative Queries: owner-mercury-developers at cs.mu.oz.au
Subscriptions:          mercury-developers-request at cs.mu.oz.au
--------------------------------------------------------------------------