Related articles |
---|
porting gcc bm216754@muenchen.org (2000-09-15) |
Re: porting gcc jeff.sturm@appnet.com (Jeff Sturm) (2000-09-17) |
Re: porting gcc msnw31175@cableinet.co.uk (Michael A. Sewell) (2000-09-17) |
Re: porting gcc bonzini@gnu.org (2000-09-17) |
Re: porting gcc bm216754@muenchen.org (2000-09-28) |
Re: porting gcc thp@roam-thp2.cs.ucr.edu (Tom Payne) (2000-10-08) |
From: | Tom Payne <thp@roam-thp2.cs.ucr.edu> |
Newsgroups: | comp.compilers |
Date: | 8 Oct 2000 22:29:00 -0400 |
Organization: | University of California, Riverside |
References: | 00-09-104 00-09-122 00-09-187 |
Keywords: | C, C++ |
Juergen Fischer <bm216754@muenchen.org> wrote:
> I heard about the possibility of a c++ -> c translator. however my
> theory is that c++ exceptions need capabilities beyond stack
> operations expressible in C,
The cleanest way to translate C++ into C would be to translate
function by function, with each C++ function becoming a unique C
function. I've heard that C-front followed that approach and ran into
the problems that you describe.
There is a lower level approach wherein C is treated as an assembly
language for a load/store architecture:
* variables are treated as registers
* a byte array is treated as memory
* a char* pointer variable serves as stack pointer
* indirect jumps are implemented via a switch-based hack
and so on.
Anything that can be done in say MIPS assembly language can be done
with this approach. One bit of tedium is that in the resulting C code
labels are function local, so one must merge the .c files resulting
from individual C++ translation units into a single very big main()
function. Also, linking to standard library functions is a tedious
but solvable problem.
Tom Payne
Return to the
comp.compilers page.
Search the
comp.compilers archives again.