Pcc, generic compilation

gclind01@starbase.spd.louisville.edu (George C. Lindauer)
31 Mar 1996 17:19:37 -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: gclind01@starbase.spd.louisville.edu (George C. Lindauer)
Newsgroups: comp.compilers
Date: 31 Mar 1996 17:19:37 -0500
Organization: University of Louisville, Louisville KY USA
Keywords: design, question

I asked a while back what's to stop you from having a generic compiler
that would output some sort of intermediate code, and then having a
seperate backend for each processor. The answer I got was that PCC
already does this; further I was informed that it's hard to get around
needing feedback into the first pass; e.g. for structures and stuff.


But I was wondering, if you are going to have a generic compiler which
outputs intermediate code, what is to stop you from putting enough
info in the intermediate code that the backend programs can resolve
structure references themselves. E.G. instead of having the main
compiler resolve numerical offsets, just have it pass the structure
names and fields and elementary types and then have the backend
resolve the offsets with any alignment or other concerns? Then the
compiler can focus on producing low-level code from an input spec and
the backends can deal with architecture-dependent issues.


Are the any other issues I haven't thought up that might pose a
problem?


David
[ANDF does this; the main problem is that it pushes a lot of work into
the back end which could have more easily handled in the front. -John]


--


Post a followup to this message

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