|porting gcc email@example.com (2000-09-15)|
|Re: porting gcc firstname.lastname@example.org (Jeff Sturm) (2000-09-17)|
|Re: porting gcc email@example.com (Michael A. Sewell) (2000-09-17)|
|Re: porting gcc firstname.lastname@example.org (2000-09-17)|
|Re: porting gcc email@example.com (2000-09-28)|
|Re: porting gcc firstname.lastname@example.org (Tom Payne) (2000-10-08)|
|From:||Tom Payne <email@example.com>|
|Date:||8 Oct 2000 22:29:00 -0400|
|Organization:||University of California, Riverside|
|References:||00-09-104 00-09-122 00-09-187|
Juergen Fischer <firstname.lastname@example.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.
Return to the
Search the comp.compilers archives again.