Re: porting gcc

Tom Payne <thp@roam-thp2.cs.ucr.edu>
8 Oct 2000 22:29:00 -0400

          From comp.compilers

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)
| List of all articles for this month |
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


Post a followup to this message

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