Re: Using C as a back end

Pred. <predictor@my-deja.com> wrote:
>
> PROS:
> 1. I don't have to learn about / write code generators for the various
> targets
> 2. "Tried'n'true" back end
> 3. Shorter time-to-market


These are the reasons why C is used as a backend, and they are strong
reasons.


> CONS:
> 1. Slower compilation (scan + parse occurs twice)


Scan&parse is nearly negligible. What takes time is optimization and
linking. On a Windows platform, starting a new process is an
expensive activity, so you may want to make sure that you don't
generate heaps of little C files (this made early Eiffel compilers
slow). The downside of large C files is that it makes incremental
compilation difficult. There's lot of room for heuristics and strategy
in this area. At least one of the Eiffel compilers (iss-base)
generates large files and splits them up when it detects that a
specific source has changed (Eiffel compilers don't work well with
"make" anyway, the dependency analysis of "make" will find too many
superficial dependencies).


> 2. No control over new versions of the back end


This is not a large problem in practice. Your compiler isn't going to
emit new code for each new compiler version, and C compilers tend to
be backwards-compatible, so if your compiler emitted code that worked
under version X it will likely work under version X+1 as well.
Besides, you have this problem regardless of what backend you use. The
C compiler will shield you from new object file formats, for example.


However, you can have trouble adapting to multiple backends. gcc,
MSVC, Borland C, lcc all have their special quirks, require different
header files, have different conventions for interfacing with
DLLs/shared libraries, etc. If portability across C compilers is
required, I'd suggest that you target at least two compilers
initially, to avoid falling trap to one compiler's absolutely
nonstandard C extensions.


3. The generated C source will take up at least as much space as the
original sources. This can become unwieldy once the language is used
for large projects. (Deleting the intermediate C sources on my machine
can take a minute.)


4. You'll have to think about making the standard debugger for C
source work well with your code. (You *will* want to debug the
generated code.) Associating given C source with your language source
will be a major pain in the neck as the standard debug information for
this won't work: C doesn't have language mechanisms to insert
HLL-specific debug information into the executable. Of course, what's
the "standard debugger" will vary wildly for different
compilers. Debugger information formats are highly volatile. If your
language has any nonstandard execution strategies (such as lazy
expression evaluation, or a string representation that doesn't follow
the usual C null-termination convention), then any standard debugger
will be of limited usefulness anyway.


5. Your language may have a semantics that's difficult to implement in
C. The most notorious problem here is exceptions: setjmp() and longjmp()
will work, but they will be slow, as you'll need a setjmp() whenever a
subroutine is called, whether the subroutine throws an exception or not.


An alternative to C is C--. I'm not sure whether it's ready for show
yet, but take a look at http://www.cminusminus.org .


Regards,
Joachim
[Actually, in many compilers the scanner is the slowest part because
it's the only thing that has to look at every character in the source
file. -John]

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