HDTenEightyP/NetNews huggingface dataset:
From: tm@netcom.com (Toshiyasu Morita)
Subject: Re: Code quality
Reply-To: tm@netcom.com (Toshiyasu Morita)
Organization: Netcom Online Communications Services
Date: Thu, 7 Jan 1993 04:53:56 GMT
Keywords: optimize, GCC

John Levine writes:
[It varies all over the place.  The Princeton/Bell Labs lcc compiler
>is supposed to produce better code faster than GCC.  Ken Thompson's Plan 9
>compiler is supposed to be better still in both dimensions. -John]

The lcc compiler might produce better code for GCC for some
very local bits of code, but not globally. Here's the benchmark
given at the end of the lcc OVERVIEW.TEX file:

                            benchmark
_compiler__1._gcc1.35__8._espresso__22._li_23._eqntott__


 VAX: MicroVAX II w/16MB running Ultrix 3.1
 lcc          1734        2708       7015      3532
 cc           1824        2782       7765      3569
 gcc          1439        2757       7353      3263
 cc -O        1661        2653       7086      3757
 gcc -O       1274        2291       6397      1131


 68020: Sun 3/60 w/24MB running SunOS 4.0.3
 lcc          544         1070       2591       567
 cc           514         1005       3308       619
 gcc          426         1048       2498       591
 cc -O        428          882       2237       571
 gcc -O       337          834       1951       326


 MIPS: IRIS 4D/220GTX w/32MB running IRIX 3.3.1
 lcc          116          150       352        111
 cc           107          153       338        100
 gcc                       188       502        132
 cc -O         92          130       299         70
 gcc -O                    145       411        112


 SPARC: Sun 4/260 w/32MB running SunOS 4.0.3
 lcc          196          370        790       209
 cc           203          381       1094       275
 gcc          186          411       1139       256
 cc -O        150          296        707       183
 gcc -O       127          309        788       179



 Table 2: Execution Time for C SPEC Benchmarks in Seconds.


I think it's a bit misleading to say lcc produces better code than gcc.

lcc is definitely faster than gcc, however.


Toshi Morita
tm@netcom.com

-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: crowl@jade.cs.orst.edu (Lawrence Crowl)
Subject: Undergraduate Compilers Textbook
Reply-To: crowl@jade.cs.orst.edu (Lawrence Crowl)
Organization: Computer Science Department, Oregon State University
Date: Wed, 6 Jan 1993 00:01:01 GMT
Keywords: books, question

Our department is reevaluating the textbook for our senior-level compiler
course.  So, I am seeking your recommendations for textbook.  Please email
your recommendations to me, and I will post a summary.

-- 
Lawrence Crowl		503-737-2554	Computer Science Department
		   crowl@cs.orst.edu	Oregon State University
      ...!hplabs!hp-pcd!orstcs!crowl	Corvallis, Oregon,  97331-3202
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: brent@rcx1.ssd.csd.harris.com (Brent W. Benson)
Subject: Compiler Construction in Ada
Reply-To: brent@rcx1.ssd.csd.harris.com (Brent W. Benson)
Organization: Compilers Central
Date: Thu, 7 Jan 1993 20:33:18 GMT
Keywords: courses, Lisp

jipping@cs.hope.edu (Mike Jipping) writes:

> Now the Pascal compiler is gone.  And I'm looking for the
> appropriate language in which to write the compiler for the project.

Why not us Common Lisp?  Its wealth of tools and good programming
environment make it ideal for prototyping compilers.  If you're using
Sparcs, CMU Common Lisp is a quality (and freely-available) compiler.

Brent Benson                     
Harris Computer Systems

-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: winikoff@cs.mu.oz.au
Newsgroups: comp.compilers
Subject: Errors and Type checking.
Keywords: debug, types
Date: 12 Jan 93 18:13:32 GMT
Article-I.D.: comp.93-01-069
Reply-To: winikoff@cs.mu.oz.au
Organization: Compilers Central

> From: jlg@cochiti.lanl.gov (J. Giles)
> ...  The vast majority of debugging time is spent isolating and
> correcting problems which are not - and cannot be - found by the
> typechecks no matter how strict your type system is.  To put it another
> way: people make mistakes and those mistakes which the compiler (or some
> analyzer) can find automatically are the least difficult to find and
> correct.

Not neccessarily. A lot of the mistakes that people make induce type
errors as a side effect.  Of course the type checker won't give you the
cause of the error but in a fair number of cases it will detect that there
is an error even if the error is a logical one.

> It seems to me that the main problem with compiler writers ... is that
> compiler writers don't actually *use* the language the compiler is written
> to compile.  Such compiler jockeys don't understand the issues which are
> important to the users.

A fair number of languages have compilers that are written in themselves.
(Eg. Prolog, C, Haskell ...)
--
Michael Winikoff
winikoff@cs.mu.oz.au
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: jjones@cs.uiuc.edu (Joel Jones)
Subject: current work on affix grammar code generators
Reply-To: jjones@cs.uiuc.edu (Joel Jones)
Organization: University of Illinois at Urbana-Champaign
Date: Mon, 11 Jan 1993 18:08:21 GMT
Keywords: question

What is the current state of the art in affix grammar code generators?

Joel Jones
jjones@uiuc.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: drw@riesz.mit.edu (Dale R. Worley)
Subject: Re: Code quality
Reply-To: drw@riesz.mit.edu (Dale R. Worley)
Organization: MIT Dept. of Tetrapilotomy, Cambridge, MA, USA
Date: Fri, 8 Jan 1993 23:24:26 GMT
Keywords: performance

bill@amber.csd.harris.com (Bill Leonard) writes:
   Most users are not going to upgrade their CPUs every year, nor even every
   2 years, but they are highly likely to upgrade their compilers every year
   (if nothing else, for bug fixes).

If I remember correctly, the product lifetime for workstations is 18
months heading downward toward 12 months.  A lot of computers are thrown
out because the manufacturer has discontinued support.

Dale Worley		Dept. of Math., MIT		drw@math.mit.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: brent@rcx1.ssd.csd.harris.com (Brent W. Benson)
Subject: Re: Compiler Construction in Ada
Reply-To: brent@rcx1.ssd.csd.harris.com (Brent W. Benson)
Organization: Compilers Central
Date: Fri, 8 Jan 1993 14:27:10 GMT
Keywords: courses, Ada

davidm@questor.rational.com (David Moore) writes:

> Ada would be a perfectly fine language to write a compiler in, but I
> would say that the prime requirement is that the students already
> have whatever language you choose when they come into the course.

I don't agree (what does it mean to "have" a language anyway).  What
better way to learn a langauge than to write a compiler in that language?
(Answer: write a compiler for it.)  By teaching C classes and Fortran
classes and Pascal classes we're reinforcing the idea that there is
something completely unique about that language.  You should be able to
explain the idiosyncrasies of a new language to a junior or senior-level
CS student, give him or her a manual and start giving assignments.

Sorry, for the digression into comp.edu issues.

Brent Benson                     
Harris Computer Systems
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: thutt <thutt@MAIL.CASI.NASA.GOV>
Subject: Writing Interactive Compilers....
Reply-To: thutt <thutt@MAIL.CASI.NASA.GOV>
Organization: Compilers Central
Date: Tue, 12 Jan 1993 12:45:49 GMT
Keywords: books, interpreter

If the book, "Writing Interactive Compilers and Interpreters" in paperback
form from Wiley is the one that implements a Pascal compiler and Pascal
interpreter for the 8086 chip, it is truly so full of errors in the actual
code (generated code as well as the compiler itself) as to make it almost
useless.

The practical approach that is taken really leaves a lot out
(explanation), and the descriptions of the code do not correspond very
well to the published source.

The very best 'practical' book on operating systems and compilers that I
have seen is 'Project Oberon: The design of a compiler and operating
system' by Wirth & Gutknecht (ISBN 0-201-54428-8).  This contains the
(nearly) complete implementation of the Oberon operating system, and the
complete implmentation of a production compiler.  The source is available
for ftp from neptune.ethz.ch.  Recommended reading.

(If I have confused the above book, then I apologize.  I am sorry I bought
the book I did, whatever it is.)

-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: John R. Levine <johnl@iecc.cambridge.ma.us>
Subject: Re: Input buffer overflow in lex...
Reply-To: John R. Levine <johnl@iecc.cambridge.ma.us>
Organization: Compilers Central
Date: Tue, 5 Jan 1993 00:10:47 GMT
Keywords: lex

|    \"(\\.|[^\\"])*\"                       {some_action_here ();}
|
|The input string is "aaaa..." with 2000 `a' in it [and the token buffer
|overflows]

Well, the short answer is that you lose.  No version of lex checks for
token buffer overflow, although it is less destructive in flex than it is
in lex.  This can be called a lex design error, though it's hard to
check for overflow without making the lexer a lot slower.  The solution
is not to use tokens that can be arbitrarily long.

If you switch to flex (highly recommended) it can handle up to 8K per
token with no trouble.  In AT&T lex, you can redefine YYLMAX, the size of
the token buffer, yourself at the front of the lex file.

The other possibility is to use start states to build the string
yourself:

%s STRING

<INITIAL>\"		{ BEGIN STRING; init_string_buf(); }
<STRING>\\.|[^\\"]	{ add_to_string(yytext); }
<STRING>\"		{ end_string_buf(); BEGIN INITIAL; }

This topic is discussed at some length in the reference part of:

John R. Levine, Tony Mason, and Doug Brown, ``Lex & Yacc,'' 2nd Edition,
O'Reilly and Associates, 1992, ISBN 1-56592-000-7, $29.95.

I think it's a swell book but since I wrote a lot of it my opinion may be
a wee bit biased.
-- 
Regards,
John Levine
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Code quality
Reply-To: henry@zoo.toronto.edu (Henry Spencer)
Organization: U of Toronto Zoology
Date: Wed, 6 Jan 1993 21:45:43 GMT
Keywords: optimize

drw@zermelo.mit.edu (Dale R. Worley) writes:
>Is there much of a market for another 10% in speed of generated code?

To (approximately) quote John Mashey: "there are people who will commit
unspeakable acts for another ten percent".  There is no shortage of
applications which are hard up against processor speed limits, where a
modest improvement in code quality can save a lot of people a lot of pain
trying to squeeze out a bit more performance.  "Just switch to a faster
processor" doesn't work when you've got a large installed base to worry
about, or you're already using the fastest available, or the CPU box is
orbiting Jupiter...

A lot of customers don't care about 10%.  Some do.  Some care a lot.
Whether there are enough of them to support extensive compiler work
depends on details of the market you're selling to.
-- 
Henry Spencer @ U of Toronto Zoology, henry@zoo.toronto.edu  utzoo!henry
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: preston@dawn.cs.rice.edu (Preston Briggs)
Newsgroups: comp.compilers
Subject: Re: Code quality
Keywords: optimize, architecture
Date: 6 Jan 93 19:25:39 GMT
Article-I.D.: comp.93-01-019
Reply-To: preston@dawn.cs.rice.edu (Preston Briggs)
Organization: Rice University, Houston

drw@zermelo.mit.edu (Dale R. Worley) writes:

>How important is generated code quality these days?  There are a lot of
>good optimization techniques that seem to be adequate for ordinary
>programming.  But they still are at least 10% or 20% worse than the ideal.
>Is there much of a market for another 10% in speed of generated code?

I think high-quality code generation is still important.  However, people
aren't worried so much about the final 10%; rather, they are concerned
about the factors of 5 and 10 and 20 that current compilers lose to
(knowledgable and hardworking) humans when faced with an exotic
architecture.  Typically, compilers still lose big on various kinds of
parallel machines and on machines with interesting memory hierachies.  Of
course, most high-performance machines have many levels of parallelism and
a multi-level memory hierarchy, so...  Lots of problems to work on!

Note that I'm not advocating hand coding for these machines.  I believe
that even simple compilers are easily good enough to economically justify
their use in almost every circumstance.  Instead, I'm saying that the
demands (and money) of high-performance users justify quite a lot more
research effort.

Preston Briggs
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: richw@sol.camb.inmet.com (Richard Wagner)
Subject: Re: Input buffer overflow in lex...
Reply-To: richw@sol.camb.inmet.com (Richard Wagner)
Organization: Intermetrics, Inc.
Date: Wed, 6 Jan 1993 19:57:37 GMT
Keywords: lex, comment

In the version of "lex" I use, the generated lexer gets its input via an
"input" macro.  One solution, which may be viewed as a "kludge" or "hack",
is to "#undef" the default macro and "#define" another with the same
functionality, but which also checks for overflow (and possibly takes some
recovery action, like copy what's in the buffer to an "infinitely" long
linked-list of buffers).

For example:

    %{
    #undef input

    #define usual_input_macro()    (...text of default "input" definition...)

    #define input()         ( \
	('\0' != *(yytext + YYLMAX - 1)) \
		? (token_too_long()) \
		: usual_input_macro() \
	)

    #define token_too_long()	(...recovery action...)

	:


Disclaimer:  I've never tried this.

Lets hope I'm not being blind to some reason this can't work.  I
personally prefer this than just bumping YYLMAX, which may be fine,
practically speaking, but still nags in that it just begs the question.

Hope this helps,

Rich Wagner
Intermetrics, Inc.
[I still think you're better off writing your lexer so you don't get
enormous tokens. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: ssimmons@convex.com (Steve Simmons)
Subject: Re: Code quality
Reply-To: ssimmons@convex.com (Steve Simmons)
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Date: Thu, 7 Jan 1993 13:48:15 GMT
Keywords: optimize

>Is there much of a market for another 10% in speed of generated code?

If the application takes 10 days to run, then taking a 10% off the 
application time saves you an entire day's worth of work (and risk
of down time).  It is all relative. 

Thank you. 

					Steve Simmons
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: Michael John Haertel <mike@skinner.cs.uoregon.edu>
Subject: Gcc, Lcc, and 2c
Reply-To: Michael John Haertel <mike@skinner.cs.uoregon.edu>
Organization: Compilers Central
Date: Thu, 7 Jan 1993 01:30:46 GMT
Keywords: optimize

The moderator wrote:

>[It varies all over the place.  The Princeton/Bell Labs lcc compiler
>is supposed to produce better code faster than GCC.  Ken Thompson's Plan 9
>compiler is supposed to be better still in both dimensions. -John]

This isn't true.  My experience was that Gcc produces faster code than
Lcc.  Methodology: Compile both compilers with themselves and each other.
Time the amount of time both compilers take.  I found that the
lcc-compiled compilers typically ran 5-10% slower than the gcc-compiled
compilers.  I suspect that any published comparisons that show Lcc
producing faster code are either based on not using -O with gcc, or or
used a poorly tuned port of gcc.

I was not able to compare 2c directly with gcc, since gcc had not been
ported to Plan 9, but again I suspect Gcc-compiled code is as good or
faster.  Despite claims to the contrary in Thompson's paper.  My guess is
that either (a) he didn't use -O with gcc, or (b) he ran his comparisons
on the MIPS.  The MIPS version of gcc in 1990 was very poorly tuned.  (On
the 680x0, also add (c) use of 16-bit addressing modes that Gcc can't use
for lack of linker magic.)

There is no question, though, that both Lcc and 2c themselves run much
faster than gcc.  Lcc is at least twice as fast, and 2c is probably faster
still.  The Bell Labs folks seem to care more about compile time than
extreme optimization of the generated code.  This is quite reasonable
considering how much of their time they spend compiling.

Unfortunately, I have no hard data to offer and I no longer have access to
Lcc or 2c.  It would be nice if a disinterested third party with access to
all three compilers would do a comparison...
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: bill@amber.csd.harris.com (Bill Leonard)
Subject: Re: Code quality
Reply-To: bill@amber.csd.harris.com (Bill Leonard)
Organization: Harris CSD, Ft. Lauderdale, FL
Date: Thu, 7 Jan 1993 15:07:18 GMT
Keywords: optimize, comment

drw@zermelo.mit.edu (Dale R. Worley) writes:
>Is there much of a market for another 10% in speed of generated code?
 
henry@zoo.toronto.edu (Henry Spencer) writes:
> There is no shortage of applications which are hard up against processor
> speed limits, where a modest improvement in code quality can save a lot
> of people a lot of pain trying to squeeze out a bit more performance.
> "Just switch to a faster processor" doesn't work when you've got a large
> installed base to worry about, or you're already using the fastest
> available, or the CPU box is orbiting Jupiter...

You don't have to get nearly so exotic as this to find a market for an
extra 10% in code performance.  To the user, it is still much less
expensive to upgrade compilers than it is to upgrade a CPU.  So if a user
can upgrade his compiler to get an extra few % in performance, then he can
add extra functionality to his application without hurting its
performance.  This is especially important in real-time applications,
which often have to do a given amount of work in a specified amount of
time.  As we all know, however, the "given amount of work" often increases
over time.

Most users are not going to upgrade their CPUs every year, nor even every
2 years, but they are highly likely to upgrade their compilers every year
(if nothing else, for bug fixes).
-- 
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.csd.harris.com
[Funny, I can upgrade the CPU on my system to a double-speed version for
about $400, but a super-duper optimizing compiler costs more like $700.
-John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Subject: Re: Errors and Type checking.
Reply-To: anton@mips.complang.tuwien.ac.at (Anton Ertl)
Organization: Institut fuer Computersprachen, Technische Universitaet Wien
Date: Tue, 12 Jan 1993 09:24:45 GMT
Keywords: performance, debug

jlg@cochiti.lanl.gov (J. Giles) writes:
> Most errors are not syntactic or static semantic errors (like type
> errors).  The vast majority of debugging time is spent isolating and
> correcting problems which are not - and cannot be - found by the
> typechecks no matter how strict your type system is.

I can confirm this from experience with languages that do not check types
at all (e.g. Forth). I have not found type errors to be a problem.  There
are two reasons for this:

1) I make fewer type errors than when programming in a compile-time
type-checked language. I.e., I am more careful. It probably takes a bit of
time to develop that programming mode.

2) When I make a type error, it is usually easy to catch and correct (It
helps if the language is interactive).

I think the more problematic type errors are those that the type checker
does not check, e.g. a search tree that is not sorted. Of course, this
sort of error could be caught with compile-time assertion checkers, but
somehow this technology has not caught on.

- anton
-- 
M. Anton Ertl	anton@mips.complang.tuwien.ac.at
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: bj gleason <BJGLEAS@AMERICAN.EDU>
Subject: Re: Availability of a Basic Compiler
Reply-To: bj gleason <BJGLEAS@AMERICAN.EDU>
Organization: The American University - University Computing Center
Date: Thu, 7 Jan 1993 18:08:31 GMT
Keywords: Basic, interpreter, comment

Unless I am mistaken, I thought that Bywater BASIC was an interpreter,
not a compiler....

bj
[Despite the name, interpreters are fair game for comp.compilers. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Subject: Re: Compile Time vs. Run Time, Mixed Language Compiling, Fat Code
Reply-To: tmb@arolla.idiap.ch (Thomas M. Breuel)
Organization: IDIAP
Date: Tue, 12 Jan 1993 22:59:32 GMT
Keywords: debug, types

nickh@CS.CMU.EDU (Nick Haines) writes:
> An SML program which successfully typechecks will not
> bomb [due to type errors] at runtime.

jlg@cochiti.lanl.gov (J. Giles) writes:
Then your programs are considerably different from what I'm familiar with.
Most errors are not syntactic or static semantic errors (like type errors).

Actually, both of you are probably right.

For example, in FORTRAN, most programming mistakes don't show up as type
errors. The reason is that the FORTRAN type system isn't very expressive,
relying on arrays of numbers to represent many different kinds of data
structures (this kind of programming style is often carried over by its
practitioners to other languages; see, for example, "Numerical Recipes in
C").

The SML type system, however, lets the programmer tell the compiler a lot
about his data structures and their interrelationships.  This means that
if you take advantage of the added expressiveness of the SML type system,
many errors that are not type errors in most other languages will be
caught by the type checker.

So, extensive static typechecking alone doesn't automatically find more
errors in your programs. You also need an expressive type system, and you
need to use it.

Incidentally, having reimplemented a number of FORTRAN programs in SML, my
impression is that even hardcore numerical programs benefit greatly from
use of a more expressive type system.

					Thomas.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers