Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!ihnp4!ptsfa!lll-lcc!seismo!husc6!necntc!mit-eddie!mit-hermes!phr
From: phr@mit-hermes.UUCP
Newsgroups: comp.lang.c
Subject: Re: Dhrystone benchmark results from GNU C compiler
Message-ID: <2809@mit-hermes.AI.MIT.EDU>
Date: Sat, 28-Feb-87 07:01:58 EST
Article-I.D.: mit-herm.2809
Posted: Sat Feb 28 07:01:58 1987
Date-Received: Mon, 2-Mar-87 06:47:01 EST
References: <2806@mit-hermes.AI.MIT.EDU> <376@sdd.UUCP>
Reply-To: phr@hermes.UUCP (Paul Rubin)
Followup-To: comp.lang.c
Organization: GNU project / Free Software Foundation
Lines: 21
Summary: gcc backends; gdb availability

In article <376@sdd.UUCP> Daniel Corbett writes:
>
>	What CPUs / architectures / a.out formats is the GNU C compiler
>work for?  How easy will it be to port the compiler to other
>machines / CPUs?  Is gbd the GNU equivalent to sdb?  If so, is
>it currently available.  I would like to have a debugger that
>works with C++.

1. Currently backends exist for vax, 68000, and 68020.
   It produces assembly code, so the a.out format is not relevant
   (but it produces debugging info used by 4.2bsd as/ld).
2. GCC is reasonably easy to retarget.  Someone who has looked at
   both GCC and Unix PCC says that GCC is probably easier, but
   who knows.  Documentation on GCC internals for would-be retargeters
   is being written and some will be available when GCC is released.
3. GDB is more like DBX than SDB.  It has been in distribution for a
   year or so on the GNU Emacs tape.  It works on Vaxes and Suns under
   4.2bsd.  We have no plans to make it work under Sys V although
   others are welcome to try.  Making it work with other languages
   (e.g. C++) will be of more interest once we have more front ends
   for GCC.