🚀 go-pugleaf

> From: kanner@tymix.UUCP (Herb Kanner)
> Newsgroups: net.lang.c++
> Subject: Query to Bjarne
> Organization: Tymnet Inc., Cupertino CA
> 
> Here are a few questions, probably addressed to Bjarne Stroustrup, with
> respect to the released version of the C++ compiler.

> 1) Is the assumption that the compiler is released in the form of C source
> a correct one?

The released version of the C++ translator (commonly known as cfront) comes in
C++ source form together with a C version of of cfront (generated by itself) for
a VAX or a 3B.

> 2) It is described as a front end, and in one of your news items you refer
> to inspection of its C output.  You also specifically call it "a front-end
> that translates C++ into C."  Later in the same sentence, you say that
> cfront does all syntax and type checking and that the underlying C compiler
> is used as a code generator only.  Superficially, this sounds like a
> contradiction.  Is it that some options are set so that unnecessary
> checking steps on the part of the C compiler are skipped because its input
> is guaranteed to be clean?

No, the C compiler goes through a ``completely unnecessary'' syntax and type
checking step. I wish I could turn that off and go directly to the code
generation part of cc. However, that would take away the portability that was
the reason for generating C in the first place. You gain portability and
lose cpu time when you must generate code. What you can reasonably hope for is
that you re-gain that cpu time by using a better language and because the two
pass approach (cfront + cc) yields error messages about 3 times faster than a
one pass approach (such as ``plain'' cc).

> 3) How do you do debugging with the current product?  Is it to set dbx or 
> sdb flags on the C compiler, capture a copy of the intermediate C, and work
> with that?

That is ``approach number one''. It is not ideal, but it has been done. A better
approach involves a debugger that can relate the object code to the C++ source.
This has been done, but I don't know of any commercially available debuggers
that does that.

> 4) We are planning to use C++ to cross compile for a stand-alone (non-UNIX)
> environment.  What runtime functions must we implement in order to support
> code generated by cfront?

malloc() and free(). The C++ library contains a few more functions _main(),
_ctors(), _dtors(), operator new(), and operator delete(), but they are trivial
portable, and supplied in C++ source form.

You will also have to provide an I/O library (printf and/or stream I/O).

> What other problems in building such a cross compiler might we expect?

Cfront needs to know the sizes and alignments used by the C compiler on the
target machine. Typically, you get them wrong first time. Have a look at the
description of how to port release 1.0 of C++ to a variety of machines
posted to net.lang.c++ by Jonathan P. Leech at California Institute of Technology.
It mentions most snags and their fixes.

> Herb Kanner, McDonnell Douglas (TYMNET), ...!hplabs!oliveb!tymix!kanner
> 
> An additional question suggested by a colleague:
> 
> Are there any runtime routines used by C++ other than those included
> in the standard C library?

None that are essential for running programs, but C++ does come with a
``stream I/O library'' as described in the C++ book. There is also a
library of functions and operators for complex arithmetic. Some rudementary
facilities for creating generic types, and a library for writing event
driven simulations a la Simula67. This ``task libray'' contains machine
dependent code and a few lines of assembler so it will only run on a VAX.