Re: Pcc, generic compilation

Dave Lloyd <dave@occl-cam.demon.co.uk>
6 Apr 1996 22:13:33 -0500

          From comp.compilers

Related articles
Pcc, generic compilation gclind01@starbase.spd.louisville.edu (1996-03-31)
Re: Pcc, generic compilation jejones@microware.com (1996-04-02)
Re: Pcc, generic compilation dave@occl-cam.demon.co.uk (Dave Lloyd) (1996-04-06)
Re: Pcc, generic compilation ganswijk@xs4all.nl (Jaap van Ganswijk) (1996-04-06)
| List of all articles for this month |

From: Dave Lloyd <dave@occl-cam.demon.co.uk>
Newsgroups: comp.compilers
Date: 6 Apr 1996 22:13:33 -0500
Organization: Compilers Central
Keywords: C

> That would be nice--but as the moderator says, there are some things
> more easily handled in the front end. Case in point for C: sizeof()
> and offsetof() have to yield constants/constant expressions, so it's
> theoretically possible (bizarre, but theoretically possible) to write
[example snipped]
> and it would be a major pain to make the back end give a reasonable error
> message if, say, the values were identical!


Our compiler is built on three major stages not two: lexer/parser,
translater and code-generator. Between the parser and translater we
use a construct graph that expresses the semantics of the program (not
far off the "internal representation" implied by Algol 68). This is
attributed with source coordinates and if the translater (which maps
from the construct graph to a low-level but universal code similar to
BCPL or C) finds any errors it can raise them cleanly (such as
overlapping case branches). The final stage is similar but weaker
than the back-end of a typical C compiler (weaker becauser the
translater has taken much of the burden where appropriate).


It should be pointed out that problems with constant expressions only
really raise their head in poor languages like C and Fortran which
have the notion of "compile-time" constant built into the language
(brain-death!!). Anyway, all languages have the potential for errors
to be discovered at a late stage in processing (even if just lex
versus semantics) and mechanisms for handling this are well
understood.


ANDF may appear to be a bit high-level, but ANDF as a language is
substantially more powerful and better typed than C (it has to be to
support Ada, Fortran and Algol 68) and a typical ANDF translater
consists of a portable part and a target part.


I have found this factorisation very powerful and many optimisations
are a hell of a lot easier when both the full language semantics and
the nitty gritty of the target code can be analysed. But I doubt the
pay-offs are so high with C which has no high-level constructs to
spend any effort on.


----------------------------------------------------------------------
Dave Lloyd Email: Dave@occl-cam.demon.co.uk
Oxford and Cambridge Compilers Ltd Phone: (44) 1223 572074
55 Brampton Rd, Cambridge CB1 3HJ, UK
--


Post a followup to this message

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