Re: Teaching compilers backwards?

Johnathan wrote:
> I'm at the stage where I'm doing compiler construction and I agree.
> Compiler courses are very unsatisfactory because we don't write real
> compilers or really learn anything. By the time the exam is "last
> week," everything is pretty much forgotten. The course runs way too
> fast and everything is vague and abstract. If we're lucky we'll do a
> stupid YARPNC (Yet Another Reverse Polish Notation Calculator). ...


I agree with all that has been said regarding teaching compiler
development. Having been disappointed with the courses, I thought I
might get various and sundry books, and go it alone. This did not
really help much either, although it made more sense to me. It seems
to me that the best way of doing all this is to get one's hands dirty,
and, start generating code (via parsers, scanners), then going though
it.


One big problem for me is the actual generation of the backend code.
All the optimization required to created a high-quality compiler leaves
one exhausted.


Sure would be good if we could generate some kind of pcode, then have
all the guru's optimize it, and produce assembly for various processors.
    I have looked at a lot of pcode, and, frankly am not too excited about
what's out there. Rather than pcode generation, if we put our heads
together, and create a plain English verion of this, it sure would go a
long way. I guess what this means is to create a new pcode language
that is readable by human beings (text), and does not assume processor
architecture. The language should assume that there are registers,
stack, memory, and should be easy to look at.


The main point of all this is that, if one can create an easy-to-look-at
    interim code, then generate processor-specific assembly code from it,
that sure would be great.


Thanks


ADD8 REG.

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