Re: Pcc, generic compilation

Jaap van Ganswijk <ganswijk@xs4all.nl>
6 Apr 1996 22:17:47 -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: Jaap van Ganswijk <ganswijk@xs4all.nl>
Newsgroups: comp.compilers
Date: 6 Apr 1996 22:17:47 -0500
Organization: Compilers Central
Keywords: C

>>...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?


>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
>something like
>
> switch (i) {
> case offsetof(struct woof, x):
> /* blah */
> break;
> case offsetof(struct arf, x):
> /* blah 2 */
> break;
> }
>
>and it would be a major pain to make the back end give a reasonable error
>message if, say, the values were identical!


I must agree: I have also tried to have the code generator and/or
assembler handle fields in structures and other offset's and
alignment, but didn't succeed.


Because I had quite a small computer at the time (64 Kbyte per task),
the idea was to have a stand-alone and even target processor
independent front-end. (I know, not a unique idea. ;-) Later I made
configurable but target dependent front-ends, but there was still some
need for feedback from the back to the front-end. Later (when the
task space on my computer increased) I recombined the front and
back-end again and I think thats much better, because you don't need
to flatten the expression trees, transport them and build them up
again, which is quite a lot of work...


The compiler still generates the structure information in assembler
language and also uses the original variable names for local variables
as far as possible. This requires a kind of block structure in the
assembler language. This all makes it much more easy to change the
assembler code manually, when needed.


In retrospect however, I think it was a waste of time, since I hardly
ever use it. The assembler needs all kinds of constructs, that are not
needed when writing assembler programs by hand. The assembler gets
more or less dual-faced. The compiler is also more complex since it
has to remember from all variables (and structure fields) what their
original name and type etc. was and generate correct assembler code
from this.


Probably a better solution is, to have the compiler print the
displacements of variables as commentaries (as some compilers do) and
enable the assembler to use the C-include files. (In case a programmer
wants to use the same C-structures in assembler). I believe some
assemblers already do this, but perhaps even this is too luxurious
too.


Well you learn by doing...
(And perhaps by reading the above text. ;-)


Groeten,
Jaap


-- Chip Directory
-- http://www.hitex.com/chipdir/ - USA
-- http://www.xs4all.nl/~ganswijk/chipdir/ - Europe
-- Many other international mirror sites from there...
--


Post a followup to this message

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