From: | BGB <cr88192@hotmail.com> |
Newsgroups: | comp.compilers |
Date: | Sat, 22 Jan 2011 03:26:31 -0700 |
Organization: | albasani.net |
References: | 11-01-082 11-01-088 11-01-092 |
Keywords: | analysis, C |
Posted-Date: | 22 Jan 2011 20:58:32 EST |
On 1/19/2011 11:11 AM, Tony wrote:
<snip>
> I am surprised (kinda) to see how many people consider C a suitable
> compile-to language when it really is only good for C-derivatives. C++
> is one of those, so cfront was adequate, for awhile. For languages
> that depart from C-likeness, it is not suitable at all.
I somewhat disagree...
I have before compiled both Scheme and JBC to C without too many
issues, and neither is particularly like C.
what C does by default is no mandate that one needs to do the same
sort of things.
<snip>
I suspect C is likely the easiest option.
ASM is probably a little harder than C, since one has to more fully work
out the mechanics, vs being able to rely on a more abstract model.
I suspect LLVM IR would be harder than ASM, since I have successfully
generated ASM on a number of occasions, but have yet to successfully be
able to get things into proper SSA form (or firmly grasp SSA in its
entirety).
granted, I am not very good with functional-programming or math either,
which may be part of it (they seem related).
well, that or getting things into SSA form is either just non-trivial or
involves some sort of "trick" I am not yet aware of. probably not that
it matters too much though (apart from doing optimizations, what else
can SSA do? and does it really offer that much over more straightforward
tasks, such as constant propagation and expression folding, and the use
of peephole optimizations? or is it more just trying to squeeze off the
last few optimizer percentage points?).
good old stack machines also work (and seem to me to be a simpler
conceptual model, and easier to work with).
granted, an IR-free compiler or interpreter would not need either.
> [C can be a perfectly reasonable intermediate language so long as you don't
> expect the C code to be readable by humans or to look anything like the
> source code. -John]
yes, I will second this.
one can use all sorts of ugly hackery which wouldn't really fly with
real (IOW: human readable) code:
merging and breaking apart functions;
using goto all over the place;
using CPS (Continuation Passing Style);
putting local variables in structures;
indentation is purely optional;
...
CPS is mostly useful if one needs to be able to support tail-call
optimization or full continuations, dunno if it has many other strong
uses though. CPS is also useful for implementing interpreters and JIT
compilers.
some things online relate SSA and CPS (claiming equivalence), but they
seem very different and unrelated.
in cases where I have used CPS when generating C, usually it involves
breaking apart code into minimal fragments (each with no internal jumps,
...), usually putting each fragment in its own C function.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.