Re: Assembler backend (was: GNU Sather Status)

[Matthew Browne]

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

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