Re: porting gcc

Tom Payne <>
8 Oct 2000 22:29:00 -0400

          From comp.compilers

Related articles
porting gcc (2000-09-15)
Re: porting gcc (Jeff Sturm) (2000-09-17)
Re: porting gcc (Michael A. Sewell) (2000-09-17)
Re: porting gcc (2000-09-17)
Re: porting gcc (2000-09-28)
Re: porting gcc (Tom Payne) (2000-10-08)
| List of all articles for this month |

From: Tom Payne <>
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 <> 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

Post a followup to this message

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