give me some tips

[Yuri CHUANG]

"No newline at the end of your output" is really a problem? I've never
learned that before.
So I desire to know some tips about writting a program perfectly.Can
anyone give me some tips which are hardly learned from textbook or
easily ignored?
Thank you very much.

[Rod Pemberton]

"Michael Mair" <Mi**********@i nvalid.invalid> wrote in message
news:47******** ****@individual .net...

Rod Pemberton schrieb:

"Michael Mair" <Mi**********@i nvalid.invalid> wrote in message
news:47******** ****@individual .net...

Essentially, whatever you can learn from the Dragon Book or
Muchnick's book.

Found them. Thanks again.

Dragon Book:
"Compilers: Principles, Techniques and Tools" Alfred V. Aho, Ravi Sethi,
Jeffrey D. Ullman
"Advanced Compiler Design and Implementation" by Steven S. Muchnick

RP

[Michael Mair]

Rod Pemberton schrieb:

"Michael Mair" <Mi**********@i nvalid.invalid> wrote in message
news:47******** ****@individual .net...

Rod Pemberton schrieb:

"Michael Mair" <Mi**********@i nvalid.invalid> wrote in message
news:47***** *******@individ ual.net...

Essentially , whatever you can learn from the Dragon Book or
Muchnick's book.

Found them. Thanks again.

Dragon Book:
"Compilers: Principles, Techniques and Tools" Alfred V. Aho, Ravi Sethi,
Jeffrey D. Ullman
"Advanced Compiler Design and Implementation" by Steven S. Muchnick

Note that the Dragon Book nowadays is quite outdated; IIRC,
there is a "21st Century Compilers" (or similar) book under way
or even out by much the same authors.

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Michael Mair]

Rod Pemberton schrieb:

"Michael Mair" <Mi**********@i nvalid.invalid> wrote in message
news:47******** ****@individual .net...

Rod Pemberton schrieb:

"Michael Mair" <Mi**********@i nvalid.invalid> wrote in message
news:47***** *******@individ ual.net...

Apart from that: Have a look at graph theory; there is much nice
stuff on the web and, as discrete maths goes, it is a fun subject
as you can state really deep problems on a sheet of paper within
five minutes so that everyone understands the problem but the
proof took a hundred years to be found and conversely can prove
things in an easily understandable way. If you understand graph
theory and get an intermediate representation of some code, you
are ready to do general (not target specific) optimisations.

Hmm, graph theory. I'll _definately_ have a look at this. It'll probably
be a big time saver for me since my spatial relationship abilities are
(supposedly) off the charts.

I am not quite sure whether I understand this remark.
We are both talking about
http://en.wikipedia.org/wiki/Graph_theory ,
aren't we?

I am not actually writing a traditional compiler but am involved
in the optimisation of an intermediate representation of code;
the output of the product is C.
More about that only via PM and only as far as I am allowed to
tell about it.

Well, you don't have to talk about that. I'm sure you've looked at other
stuff like:

GCC's RTL
TenDRA's ANDF

This one's new to me.
LCC's DAGs
Necula's CIL

So far, the only "C" compiler I've found that uses both a yacc and lex
grammar is Lutz Hamel's "C Subset Compiler" WCC for VMS.

Hmmm, as resources go, you probably know
http://www.lysator.liu.se/c/ANSI-C-grammar-y.html

Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[Rod Pemberton]

"Michael Mair" <Mi**********@i nvalid.invalid> wrote in message
news:47******** ****@individual .net...

Rod Pemberton schrieb:

"Michael Mair" <Mi**********@i nvalid.invalid> wrote in message
news:47******** ****@individual .net...

Rod Pemberton schrieb:
"Michael Mair" <Mi**********@i nvalid.invalid> wrote in message
news:47***** *******@individ ual.net...
Apart from that: Have a look at graph theory; there is much nice
stuff on the web and, as discrete maths goes, it is a fun subject
as you can state really deep problems on a sheet of paper within
five minutes so that everyone understands the problem but the
proof took a hundred years to be found and conversely can prove
things in an easily understandable way. If you understand graph
theory and get an intermediate representation of some code, you
are ready to do general (not target specific) optimisations.

Hmm, graph theory. I'll _definately_ have a look at this. It'll probably

be a big time saver for me since my spatial relationship abilities are
(supposedly) off the charts.

I am not quite sure whether I understand this remark.
We are both talking about
http://en.wikipedia.org/wiki/Graph_theory ,
aren't we?

You were. I wasn't... But, I just went through a number of graph theory
pages. I'm not sure exactly where I can use it in a compiler (yet). In
other words, binary trees, stacks, and reverse polish notation seem to do
everything I'm thinking of at the moment... Maybe I'll get it in the
future. Since I was just skimming, I didn't get to heavily into the
mathematics of graph theory.

I am not actually writing a traditional compiler but am involved
in the optimisation of an intermediate representation of code;
the output of the product is C.
More about that only via PM and only as far as I am allowed to
tell about it.

Well, you don't have to talk about that. I'm sure you've looked at other stuff like:

GCC's RTL
TenDRA's ANDF

This one's new to me.

Darn. I couldn't get a version for my OS, and was hoping someone had some
familiarity with ANDF...
http://www.info.uni-karlsruhe.de/~andf/index.htm

The TenDRA C and C++ compiler has two branches:
http://www.ten15.org/
http://www.tendra.org/

LCC's DAGs
Necula's CIL

So far, the only "C" compiler I've found that uses both a yacc and lex
grammar is Lutz Hamel's "C Subset Compiler" WCC for VMS.

Hmmm, as resources go, you probably know
http://www.lysator.liu.se/c/ANSI-C-grammar-y.html

Yes, I've updated for myself, both his flex and bison grammar's to C99.

Are you aware of Edward Willink's C++ grammars:
http://www.computing.surrey.ac.uk/research/dsrg/fog/

Unfortunately, some of his links are incorrect, extra /v/. These are
corrected:
CxxGrammar.y
http://www.computing.surrey.ac.uk/re...g/CxxGrammar.y
CxxTester.y http://www.computing.surrey.ac.uk/re...og/CxxTester.y
FogGrammar.y
http://www.computing.surrey.ac.uk/re...g/FogGrammar.y
FogTester.y http://www.computing.surrey.ac.uk/re...og/FogTester.y
Rod Pemberton

[Michael Mair]

Rod Pemberton schrieb:

"Michael Mair" <Mi**********@i nvalid.invalid> wrote in message
news:47******** ****@individual .net...

Rod Pemberton schrieb:

"Michael Mair" <Mi**********@i nvalid.invalid> wrote in message
news:47***** *******@individ ual.net...
Rod Pemberton schrieb:
>"Michael Mair" <Mi**********@i nvalid.invalid> wrote in message
>news:47*** *********@indiv idual.net...

Apart from that: Have a look at graph theory; there is much nice
stuff on the web and, as discrete maths goes, it is a fun subject
as you can state really deep problems on a sheet of paper within
five minutes so that everyone understands the problem but the
proof took a hundred years to be found and conversely can prove
things in an easily understandable way. If you understand graph
theory and get an intermediate representation of some code, you
are ready to do general (not target specific) optimisations.

Hmm, graph theory. I'll _definately_ have a look at this. It'll
probably
be a big time saver for me since my spatial relationship abilities are
(supposedl y) off the charts.
I am not quite sure whether I understand this remark.
We are both talking about
http://en.wikipedia.org/wiki/Graph_theory ,
aren't we?

You were. I wasn't... But, I just went through a number of graph theory
pages. I'm not sure exactly where I can use it in a compiler (yet). In
other words, binary trees, stacks, and reverse polish notation seem to do
everything I'm thinking of at the moment... Maybe I'll get it in the
future. Since I was just skimming, I didn't get to heavily into the
mathematics of graph theory.

Okay, let us keep this basic.
If you introduce an intermediate representation, it is often
advantageous to introduce a graph with certain properties,
e.g. a tree; if you compile on a translation unit by translation
unit base, then you could make an abstract translation unit
the base of your tree and everything stored in file scope the
first level nodes. Then you descend, into functions, declarations,
statements, operations...
For intraprocedural analysis, you can build a hypergraph on top
of this tree representing your control flow, e.g. you can use
an SSA form for constant propagation, constant folding,
control flow optimisation, copy propagation, scope reduction, ...
The tree gives you the chance to navigate scopes (just stay on
one level).
Recognition of certain patterns as detection of certain kinds
of induced subgraphs can be much easier.
One key to success is an appropriate intermediate representation;
here is one point where intellectual property can rest.

TenDRA's ANDF

This one's new to me.

Darn. I couldn't get a version for my OS, and was hoping someone had some
familiarity with ANDF...
http://www.info.uni-karlsruhe.de/~andf/index.htm

The TenDRA C and C++ compiler has two branches:
http://www.ten15.org/
http://www.tendra.org/

Anyway, thank you for the information :-)

LCC's DAGs
Necula's CIL

So far, the only "C" compiler I've found that uses both a yacc and lex
grammar is Lutz Hamel's "C Subset Compiler" WCC for VMS.

Hmmm, as resources go, you probably know
http://www.lysator.liu.se/c/ANSI-C-grammar-y.html

Yes, I've updated for myself, both his flex and bison grammar's to C99.

Would you put that up on the clc wiki?
BTW: We made it back on topic ;-)
Are you aware of Edward Willink's C++ grammars:
http://www.computing.surrey.ac.uk/research/dsrg/fog/

Unfortunately, some of his links are incorrect, extra /v/. These are
corrected:
CxxGrammar.y
http://www.computing.surrey.ac.uk/re...g/CxxGrammar.y
CxxTester.y http://www.computing.surrey.ac.uk/re...og/CxxTester.y
FogGrammar.y
http://www.computing.surrey.ac.uk/re...g/FogGrammar.y
FogTester.y http://www.computing.surrey.ac.uk/re...og/FogTester.y

I will check these out, too.
Cheers
Michael
--
E-Mail: Mine is an /at/ gmx /dot/ de address.

[David Holland]

On 2006-03-12, Michael Mair <Mi**********@i nvalid.invalid> wrote:

Rod Pemberton schrieb:

So far, the only "C" compiler I've found that uses both a yacc and lex
grammar is Lutz Hamel's "C Subset Compiler" WCC for VMS.

Why would anyone use lex? Handwritten lexers for C and C-ish languages
are cleaner, more maintainable, and perhaps faster. And they're quite
readily written in standard C.
Hmmm, as resources go, you probably know
http://www.lysator.liu.se/c/ANSI-C-grammar-y.html

Is there a license to go with that?

--
- David A. Holland
(the above address works if unscrambled but isn't checked often)

[Chris Torek]

>"Michael Mair" <Mi**********@i nvalid.invalid> wrote in message

news:47******* *****@individua l.net...

I am not actually writing a traditional compiler but am involved
in the optimisation of an intermediate representation of code;
the output of the product is C. ...

In article <dv***********@ news3.infoave.n et>
Rod Pemberton <do*********@so rry.bitbuck.cmm > wrote:... I'm sure you've looked at other stuff like:

GCC's RTL
TenDRA's ANDF
LCC's DAGs
Necula's CIL

So far, the only "C" compiler I've found that uses both a yacc and lex
grammar is Lutz Hamel's "C Subset Compiler" WCC for VMS.

In reverse order: lex does not do grammars (it only does regular
expressions), and you would want flex rather than lex, or a hand-built
lexer, as original lex's C code was, um, "not so great". :-)

GCC uses a grammar written in bison, which is essentially the same
as yacc (with of course the inevitable GNU extensions). As of many
years ago it was possible to feed this into byacc, Bob Corbett's
"Berkeley YACC", at least with a few bells added (I added them, at
BSDI).

I have never looked at CIL nor LCC.

ANDF came out of the Open Software Foundation's attempt to come up
with an "Architectu re Neutral Distribution Format" (hence the
acronym). The goal was to be able to distribute the equivalent of
".o" (compiled object) files that were not compiled for any
*particular* machine, but rather would be fed into a "re-compiler"
that would turn them into appropriate machine-specific code and
link them together. Libraries would be either native (i.e., already
compiled for the target machine) or a collection of ANDF objects.
"Architectu re neutral" intermediate file formats were not a new
idea, but previous attempts had always been abandoned or surpassed
(or both), due to what I think are pretty obvious reasons. Note
that ANDF was supposed to be "source-language neutral" as well as
"target-machine neutral", and there really is no such thing: while
it is possible to wedge a number of different source languages into
one intermediate language -- GCC does this with its RTL -- one
invariably winds up with a "union of all source constructs"
intermediate system

GCC's RTL ("register transfer language") is an outgrowth of research
originally done at the University of Arizona (Chris Fraser and J.
Davidson, in the 1980s). GCC's RTL was rather Lispified, not
surprising since the original versions of GCC itself were done by
Richard Stallman. While doing some quick background checks in
order to write this paragraph, I learned that GCC 3 and/or 4 added
some new layers between the original syntax trees built by its
front-ends and the RTL system. (I have not done anything major
inside GCC since 2.95.x, so this is all new to me.) GCC now does
a number of optimizations using the Static Single Assignment model
(which has obvious advantages over attempting them in RTL; see
<http://gcc.gnu.org/onlinedocs/gccint/SSA.html> et seq.).
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Ben Pfaff]

Chris Torek <no****@torek.n et> writes:

GCC uses a grammar written in bison, which is essentially the same
as yacc (with of course the inevitable GNU extensions).

This was true for a long time, but no longer. GCC 4.1.0,
released on 2006-02-28, replaces GCC's C parser by a "new, faster
hand-written recursive-descent parser", as you can see at:
http://gcc.gnu.org/gcc-4.1/changes.html
--
"Programmer s have the right to be ignorant of many details of your code
and still make reasonable changes."
--Kernighan and Plauger, _Software Tools_

[Chris Torek]

>Chris Torek <no****@torek.n et> writes:

GCC uses a grammar written in bison, which is essentially the same
as yacc (with of course the inevitable GNU extensions).

In article <87************ @benpfaff.org>
Ben Pfaff <bl*@cs.stanfor d.edu> wrote:This was true for a long time, but no longer. GCC 4.1.0,
released on 2006-02-28, replaces GCC's C parser by a "new, faster
hand-written recursive-descent parser", as you can see at:
http://gcc.gnu.org/gcc-4.1/changes.html

Well, at least there is still a C parser. :-)

And (on-topic, more or less) I see at the bottom of that page:

Some built-in functions have been fortified to protect applications
from stack-smashing attacks. The protection is realized by
buffer overflow detection and reordering of stack variables
to avoid pointer corruption.

This could cause "interestin g" surprises with existing code that
makes use of undefined behavior. The web page gives no additional
details, though.

I also see that x86-64 uses multiple memory models, and attempts
to bypass Standard C by using "out-of-segment" memory references
may behave in ways that surprise programmers. Everything old is
new again. :-)
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.