Re: Pros and cons of high-level intermediate languages

>I am looking for examples in which using C as IL will lead to inefficiencies.


. Mapping a language which has garbage collection, onto C. Registers
which point to non-garbage are hard to track when some C compiler thinks
that it's smarter than your compiler.


. Mapping a language which has exception handling, onto C. You could
probably do better than setjmp/longjmp in specific cases.


. Mapping an object oriented language onto C. The C model of
compilation, producing an object file for later linking, is DEAD WRONG for
OOP (*).


. Mapping an application language onto C, where it makes sense to
globally allocate a register or two to hold very important,
application-specific pointers to data/tables/etc. C thinks that registers
(other than the sp) can belong only to routines.


. Mapping a language which has scoping rules different from C onto C.
You run into namespace problems (a la C++).


. Mapping a language which has strange control flows and optimizations
onto C. C's inane half-type-checking and declaration-before-use just get
in the way - assembler is better (a sad statement, when C is nowadays
acknowledged to be foremost an assembler :-).


. Mapping a language which actually cares about arithmetic overflow
onto C. Mapping a language with larger-than-C types onto C. C lets ++
leak out, but obliterates carry and overflow.




> (2) I want to know whether any other language has been used as
> extensively as C for IL


Most so-called portable compilers I've seen have used C as their IL (how
do you think that my hate-list got to be as long as that above? :-).
I've observed that the vast majority of academics and practitioners in the
world max out at no more than one innovation per project (sometimes, per
lifetime :-). This most often means that portability issues get relegated
to the non-innovation levels. No one ever got fired for using C or MSDOS
(in this decade at least).


> (3) I want to learn about the efforts to evolve efficient ILs for
> procedural languages


Automatic coder technology has become pretty good and has been backing
into the idea of IL's. See Fraser/Davidson "automated peepholer"
technology (used in gcc) and Cordy Orthogonal Code Generator technology
for ideas. With Cordy's stuff, you get "IL's" which include high level
constructs like loops, if-then-else, etc.


The biggest practical advantage of C as a portable IL is that it brings
with it a mildly standard set of library routines. Writing such routines
for each target architecture is time consuming. On the other hand, you
don't have to emit C to be able to call these library routines.


Paul Tarvydas
TS Controls
tarvydas@tsctrl.guild.org


(*) If you don't believe my statement that the .o model of compilation is
wrong for OOP, observe how many .o files are deleted then totally
recompiled when you make a simple change to a class in the middle of a
hierarchy. You can also see the defects of the C model of compilation
oozing out in nefarious other ways - look at what they've done to Make
nowadays (.KEEP_STATE and hidden conversations with the comiler passes),
look at the goofy optimization Borland is pulling (precompiling .h files
into something other than ASCII) - these are all symptoms of a technology
having been pushed to the limit and beyond, without anyone stopping to
think WHY. [The best approximation to a better answer can be derived from
first principles - imagine that the compiler is a closed environment, like
that of Smalltalk. Then, take out your Xacto knife and slit the data
structures and dependencies so that you can write them onto persistent
storage without losing any useful information. You will not come up with
a .o model.]
--

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