Re: Intermediate forms (again?): worthwhile?

Robbert Haarman <>
Fri, 14 Jan 2011 09:19:37 +0100

          From comp.compilers

Related articles
Intermediate forms (again?): worthwhile? (Tony) (2011-01-13)
Re: Intermediate forms (again?): worthwhile? (BGB) (2011-01-14)
Re: Intermediate forms (again?): worthwhile? (Robbert Haarman) (2011-01-14)
Re: Intermediate forms (again?): worthwhile? (Gene) (2011-01-15)
Re: Intermediate forms (again?): worthwhile? (Tony) (2011-01-18)
Re: Intermediate forms (again?): worthwhile? (Robbert Haarman) (2011-01-19)
Re: Intermediate forms (again?): worthwhile? (Steven Shaw) (2011-01-19)
Re: Intermediate forms (again?): worthwhile? (Tony) (2011-01-19)
Re: Intermediate forms (again?): worthwhile? (Tony) (2011-01-19)
[14 later articles]
| List of all articles for this month |

From: Robbert Haarman <>
Newsgroups: comp.compilers
Date: Fri, 14 Jan 2011 09:19:37 +0100
Organization: Wanadoo
References: 11-01-045
Keywords: analysis
Posted-Date: 15 Jan 2011 00:16:56 EST

Hi Tony,

On Thu, Jan 13, 2011 at 11:53:30PM -0600, Tony wrote:
> As a language designer/developer, I feel like I'm in between the
> proverbial rock and hard place. I'm A-OK with doing the "front end" of
> the compiler, but the "back end" is "kinda scary" for me. To "spill", my
> path is, currently, compiling to assembly language (am I naive?). I mean,
> it's "simple", right? What can go wrong, having full control (ignore
> multi-platform compatibility, for it is NOT in my requirement now)?

Like John already said, there is nothing wrong with keeping it simple. Why
would you spend a lot of time on designing and implementing an intermediate
form if you can already do everything you need to do and the result is good
enough for your purposes?

In my experince, intermediate forms start to really make things easier
for you once you want more complex compilers: multiple target platforms,
program transformations, optimization. Many people end up wanting these
things, and so, immediate forms make sense for them. But if going straight
from parsing to emitting target code is good enough to meet your needs,
I see nothing wrong with it. Keep it small and simple; it's the best way
to complete the project and make it work.

> Clarification: I got to here from disenchantment/unenamorment with
> existing HLLs (yep, every one of them). I like the freedom afforded by
> writing to the hardware level for my language's
> initial/prototype/reference output. I have looked at (well, "you know
> me", cursory inspection) LLVM and GCC, but get the feeling it throws me
> back from where I started.

I know you warned against drifting off-topic, so feel free to move this
to a different thread, but I am curious as to what your experiences, both
good and bad, with LLVM and GCC have been. As you may know, I am working
on Voodoo, which is sort of an abstract assembly language which can be
(and has been) implemented for a number of actual target platforms. The
idea is that a compiler writer can get the benefits of generating assembly
for multiple target platforms for the cost of implementing a generator for
a single target (namely Voodoo). This is not unlike LLVM assembly language
or GCC's GIMPLE, so I am curious what they did right and wrong so that I
may learn from it.



Hofstadter's Law: Every project takes longer than you expect, even when you
take Hofstadter's Law into account.

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.