Re: Debugging optimized code (Jonathan A. Chandross)
Fri, 27 Jul 90 04:14:16 GMT

          From comp.compilers

Related articles
Debugging optimized code (Lyle Cool) (1990-07-24)
Re: Debugging optimized code (1990-07-27)
Re: Debugging optimized code (Ralph Johnson) (1990-07-30)
Re: Debugging optimized code (1990-07-30)
Re: Debugging optimized code (1990-07-31)
debugging optimized code (Caroline Tice) (1998-09-18)
Re: debugging optimized code (Steve Simmons) (1998-09-22)
Re: debugging optimized code (Quinn Tyler Jackson) (1998-09-24)
[2 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: (Jonathan A. Chandross)
Keywords: debug, optimize
Organization: Rutgers Univ., New Brunswick, N.J.
References: <>
Date: Fri, 27 Jul 90 04:14:16 GMT

> I would like to come up with a master's thesis on some aspect of debugging
> optimized code. I am looking for two things right now: 1) references to
> relevant articles and/or books, and 2) suggestions for projects approppriate
> for a master's thesis.

I am writing this with some reluctance. Partially because I am not certain
if the topic is appropriate for this group, partially because I am uncertain
as to the reaction.

I constantly see individuals in graduate school posting requests for
references for various topics. Is the art of using a library totally dead?
Is it unreasonable to expect someone who claims they want to do research to
know how to use a library? How can someone say they want to do research in a
field when they don't even know the rudiments of how to find information or
even what the field is about? Even a single paper will give you a dozen
references that can be tracked down with only minor effort.

So that this diatribe is not totally content-free, here is a brief
introduction to finding information on compilers.

Computing Surveys
Survey articles on various topics. The references cited should
give you a good idea of where to look for more information.
SigPlan Compiler Conferences (conference proceedings)
    Symposium on Compiler Construction
    Programming Language Design and Implementation
These proceedings contain many papers on compilers and related
systems. Tends to be practically oriented, but some theory.
SigPlan Notices
Journal. Often contains interesting things. Not refereed;
beware -- quality varies tremendously.
POPL (Principles of Programming Languages) Conference proceedings
Papers on compilers; tends to be more theoretical than SigPlan.
TOPLAS (Transactions On Programming Languages and Systems)
papers on compilers; tends to be more theoretical than SigPlan
ASPLOS (Architectural Support for Programming Languages and Operating Systems)
More hardware oriented, explains hardware requirements but often
describes compiler related issues
MICRO (Microprogramming) conference proceedings
Issues regarding LIW, VLIW machines. Compaction, flow analysis,
and hardware issues. Mostly microprogrammed hardware design.
AFIPS proceedings
The old volumes (sixties, early seventies) contain descriptions
of many old compilers and systems. Very helpful to understand
where things come from.

If you've looked through these proceedings and journals and you still
can't find what you want, ask somebody.


Don't expect others to do your research for you. You won't learn anything
at all that way.

You can also look at PhD dissertations and tech reports that are cited in the
references. Or, if you have some time to spare, browse through the tech
reports issued by Berkeley, Rice, University of Illinois-UC, Stanford,
Cornell, Princeton, NYU, Columbia, Rutgers, etc. to find dissertations and
tech reports that look like they would be helpful. A paper is too short to
contain much introduction and explanation; a tech report often contains good,
solid, background material. They are also much more recent than papers. A
paper often takes a year or more to get published; by the time it comes out,
the information may no longer be state of the art.

As far as your second question, i.e. a good topic, read through some of the
papers. Get a feel for the issues; what's hard, what's easy, and why.
Critique the work -- write down a list of pros and cons for each paper. What
does it do well? What does it not do well? What does it avoid entirely?
Group the papers into categories. Trace ideas through them. See how the
cross-fertilization process works. See if you can spot places where a
combination of the techniques might work. Think some more. Talk to people
about your conclusions. Think a lot more. Re-read what you've written. Is
it correct? Is it fair? Keep thinking.

Then, try to find a problem that needs solving. Do a little preliminary
investigation of the topic to ensure you haven't bitten off too much. Talk
to your advisor about the topic and see if he/she agrees that it is

If you want to do research you have to think. It isn't easy and it isn't
always pleasant. But it is the only way. And the end result is usually
worth it.

Jonathan A. Chandross
UUCP: rutgers!!jac
[This point is well taken, in the future I'll encourage senders of similar
messages to find out enough to ask something more specific. -John]

Post a followup to this message

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