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) |
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]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.