[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Assembler backend (was: GNU Sather Status)

From: Matthew Browne
Subject: Re: Assembler backend (was: GNU Sather Status)
Date: Mon, 26 Mar 2001 23:26:06 +1200

At 4:19 AM -0800 26/3/2001, Quinn Dunkan wrote:

Like what?  The only one I know of is C--, and I don't think that's in a
usable state.

ghc can generate both C and assembler (for a few architectures).  Native
compilation often makes slower binaries, but is a lot faster.

I do most of my work on a platform for which the only available compiler is a
C compiler, and I think a C backend is a better idea.  Since sather is not a
very popular language, if I want it ported I would have to do it myself.

Native code is a refinement which can be convenient in terms of compilation
speed and binary size (for those who happen to have the right platform), but
is not essential.  I'd rather have a clean, well-tested, functional C backend
and an experimental under-development native code compiler than the other way

One thing I think you may be missing here is that having a clean,
well tested, functional C backend is not that easy. Sather
currently has a C backend which has the advantage of having
a few year head start over any alternatives but I would not
call it "clean" by any means and testing it is not all that
easy. The other problem I have with it is that a piece of C code
describes a way of solving a problem rather than describing the
problem and letting our intermediate to binary stage find the
best way to solve it on our target platform. This may seem to
be a subtle difference but one way will give you clean,stable and
efficient code and the other likely will not.

I don't know enough about ghc to make any serious comments but
I would generally be worried if my native assembly code was
slower than C, I've yet to see an optimizer that good, even for
RISC platforms.

Matthew Browne

reply via email to

[Prev in Thread] Current Thread [Next in Thread]