HDTenEightyP/NetNews huggingface dataset:
From: dak@kaa.informatik.rwth-aachen.de (David Kastrup)
Newsgroups: comp.compilers,comp.theory
Subject: Re: Quantum Parsing (was: Re: Parsers are easy to write)
Keywords: parse, LL(1), yacc, comment
Date: 30 Sep 92 08:52:05 GMT
Article-I.D.: comp.92-09-203
Reply-To: dak@kaa.informatik.rwth-aachen.de (David Kastrup)
Organization: Rechnerbetrieb Informatik  /  RWTH Aachen

Ever written a parser for @#%$#@ Fortran? Remember, spaces are ignored,
and there are no reserved words. So strictly speaking you can write
12    FORMAT(I) = 7
which means something abysmally different from
12    FORMAT(I)
Note that practically all existing fortran compilers complain at some
-well- perfectly legal code. Another example:
      DO 10 I=1
is an assignment of variable DO10I
      DO 10 I=1,10
is a loop.
Write a parser for that, if you like. And building a recursive thing
with backtracking and certain state values produces essentially nothing
that a parser generator could not produce. Only that you may be less
efficient. Only pretty simple grammars can be substantially faster
parsed by a handwritten parser.
[I wrote a yacc parser for Fortran, using a prepass over each statement to
decide whether it's an assignment or not.  It wasn't that hard to do.  It's
in the compilers archives for anyone who cares. -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: preston@helena.cs.rice.edu (Preston Briggs)
Subject: Re: Register Files
Reply-To: preston@helena.cs.rice.edu (Preston Briggs)
Organization: Rice University, Houston
Date: Mon, 5 Oct 1992 21:05:12 GMT
Keywords: registers

storm@binkley.cs.mcgill.ca (Marc WANDSCHNEIDER) writes:
>[why did DEC compiler writers care if Alpha has combined or separate
>integer and FP registers?]

I don't think it's a matter of the compiler writer taking advantage of the
split; instead, I think it was a matter of ensuring that the split
wouldn't inhibit optimization (i.e., they didn't want to annoy the
compiler writers).

Preston Briggs
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: dedourek@jupiter.Sun.CSD.unb.ca (John DeDourek)
Newsgroups: comp.compilers
Subject: What program analysis tools available for c++?
Keywords: C++, tools, question
Date: 28 Sep 92 15:42:39 GMT
Article-I.D.: comp.92-09-197
Reply-To: dedourek@jupiter.Sun.CSD.unb.ca (John DeDourek)
Organization: University of New Brunswick

What program analysis tools for c++, e.g. things like C's cflow under unix,
are available for free distribution?

dedourek@jupiter.sun.csd.unb.ca
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: hobbs@steven.enet.dec.com (Steve Hobbs)
Subject: Re: Register Files
Reply-To: hobbs@steven.enet.dec.com (Steve Hobbs)
Organization: Digital Equipment Corporation
Date: Tue, 6 Oct 1992 23:09:02 GMT
Keywords: registers

>[why did DEC compiler writers care if Alpha has combined or separate
>integer and FP registers?]

Imagine that it has been decided to allocate 5 bit instruction fields to
represent register operands.  The choice then becomes: should you have 32
combined float/int registers or should you have 64 registers split between
32 integer and 32 float.  It is a fairly easy tradeoff for a compiler
person to choose double the number of registers at the cost of having to
move between the register banks when casting or converting between integer
and floating point formats.

The hardware people also like split registers.  They want to keep the
floating adder and floating multiplier close to the registers that hold
floating values and they want to keep the registers that hold integers
close to the ALU, shifter and integer multiplier.  This is much easier to
do if the registers holding floating values can be placed in a different
chip location than the registers holding integers.

A more interesting question is why doesn't the Alpha AXP architecture have
any instructions that transfer values directly between the split register
sets.  The compiler people lobbied hard for such instructions.  The
hardware people pointed out that such instructions would require precious
chip area to run wires between the two register sets and it would require
bigger muxes in the floating and integer data paths.  The size of the
integer data path is particularly important to peak chip cycle speed and
adding a mux here would reduce that peak.  The compiler people agreed to
trade off easy transfer between register banks in return for getting a
faster cycle speed.  Transfers between registers banks are not all that
common and increasing the speed of other operations even a small
percentage justifies this decision.

It is easy for a compiler person to agree with the architecture trade-offs
when the hardware experts explain and quantify the losses caused elsewhere
by any particular change.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: "Elliot H. Mednick" <elliot@wellspring.com>
Subject:   Re: Error handling in yacc question
Reply-To: "Elliot H. Mednick" <elliot@wellspring.com>
Organization: Wellspring Solutions
Date: Sat, 26 Sep 1992 19:43:30 GMT
Keywords: yacc, errors, books, comment

vera@fanaraaken.Stanford.EDU (James S. Vera) writes:
> Speaking of yacc error handling, its easy enough to put out a message
> saying token "x" was unexpected.  How does one find out what set of
> tokens was expected?  ...

See "Introduction to Compiler Construction with UNIX" by Schreiner and
Freidman (Prentice-Hall, 1985).  They present the code for doing what
you want.

-Elliot
-- 
Elliot H. Mednick                                        P.O. Box 150
Wellspring Solutions                                     Sutton, MA. 01590
elliot@Wellspring.com                                    +1 508 865 7271
[Good point.  It's in the back, in Appendix A. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: drw@euclid.mit.edu (Dale R. Worley)
Newsgroups: comp.compilers
Subject: Re: Parsers are easy to write (was: Re: Backtracking yacc)
Keywords: C, parse
Date: 30 Sep 92 17:15:01 GMT
Article-I.D.: comp.92-09-204
Reply-To: drw@euclid.mit.edu (Dale R. Worley)
Organization: MIT Dept. of Tetrapilotomy, Cambridge, MA, USA

markh@csd4.csd.uwm.edu (Mark) writes:
   In fact, I challenge anyone to find me one that I cannot craft a parser
   for by hand in a short time ("short" meaning: less time than it takes to
   write and debug an equivalent YACC source).  Something like C is
   okay, though it's not deterministic.  But C's syntax is too easy,
   the operative word here is Challenge.

C's syntax is *not* easy, if you're trying to do ANSI C exactly.  The
syntax *looks* simple to start with, but has dozens of little niggling
points that make the parser much more complicated than the language seems
to require.  I spent months, on and off, writing one.  I doubt that anyone
could write a parser that passes the usual test suites in less than a
month of full-time work, starting with only the ANSI C standard.  (I also
estimated that I could write a full C front-end in a few months.  What a
disaster!)

   [Don't forget to make sure that your hand-written parser diagnoses
   all invalid input, as a yacc parser does.  My experience is that
   the biggest wins from using yacc are the automatic diagnosis of
   ambiguous grammars and the extreme ease of adding little tweaks
   later on. -John]

Yes, indeed.  The trouble with hand-written parsers is that one doesn't
simply take a grammar and write a parser.  One writes a parser and then
modifies the grammar 100 times.  Often, the ambiguities found by the
parser generator are fed back to the language-design committee!  When the
language is pushing the edges of syntactic ambiguity, the ability of a
parser generator to detect ambiguity is very, very important.

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.
From: rsaripa@cs.clemson.edu (Saripalli Ramakrishna)
Newsgroups: comp.compilers
Subject: PDG generation from some intermediate code?.
Keywords: optimize
Date: 2 Oct 92 02:52:53 GMT
Article-I.D.: comp.92-10-005
Reply-To: rsaripa@cs.clemson.edu (Saripalli Ramakrishna)
Organization: Clemson University Computer Science Dept.

I wish to know about the various ways to generate a PDG given "some"
intemediate representation of the program.Is there any way I can
do it using GCC?.Or is there such a beast already existent at the 
numerous ftp sites?.

Can someone provide me info on this?.

					Thanks a lot,
				Saripalli Ramakrishna
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: liblit@cs.psu.edu (Benjamin R. Liblit)
Newsgroups: comp.compilers,gnu.misc.discuss
Subject: Bison: %guard & %semantic_parser
Keywords: yacc, GCC, question
Date: 30 Sep 92 02:01:33 GMT
Article-I.D.: comp.92-09-202
Reply-To: liblit@cs.psu.edu (Benjamin R. Liblit)
Organization: Compilers Central

I saw mention somewhere of a Bison %semantic_parser directive.  Near
as I can tell, it causes bison.hairy to be used instead of
bison.simple, and it seems to be somehow tied in with another
directive, %guard.

I cannot, however, find any mention of these directives in the online
documentation.  What do they do?  How does a hairy parser differ from
a simple one?  If someone could point me to some FTP'able
documentation, I would be most grateful.

--
Ben Liblit   -----   "Fais que tes reves soient plus longs que la nuit."
liblit@cs.psu.edu   --   brl102@psuvm.psu.edu   --   brl102@psuvm.bitnet

-- 
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: Register Files
Reply-To: ssimmons@convex.com (Steve Simmons)
Organization: Engineering, CONVEX Computer Corp., Richardson, Tx., USA
Date: Tue, 6 Oct 1992 12:35:51 GMT
Keywords: registers

>[why did DEC compiler writers care if Alpha has combined or separate
>integer and FP registers?]

This is not uncommon.... They were trying to separate the contention for
different functional units.  Since the CPU can write (or read) to (or
from) only one register file on a cycle, having both floating point and
integers gprs in the same register file would prohibit simultaneous
execution of both floating point and integer operations.

Separating these two register files allows the CPU to execute floating pt
and integer instructions simultaneously.  After all, the floating pointer
arithmetic unit and integer arithmetic unit are already different
functional units.  Therefore, they can fetch, decode and execute both an
integer and a floating point instruction on the same cycles. 

Be careful about some of the hype in the marketing literature. The Intel
i860 has been doing that for 4 years now.

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: "Eric A. Anderson" <eanders+@cmu.edu>
Subject: Re: Looking for Parser Generator in Perl
Reply-To: "Eric A. Anderson" <eanders+@cmu.edu>
Organization: Compilers Central
Date: Sun, 27 Sep 1992 18:01:43 GMT
Keywords: yacc, FTP

The moderator writes:
> [I'd think it'd be straightforward to modify Berkeley yacc to produce its
> parser in perl rather than C.  Yacc used to do ratfor, after all. -John]

Indeed, someone already has:
Package-Name: perl-byacc
Maintainer: corbett@berkeley.edu
Version: 1.8
Obtained: sparky.sterling.com:local-src/perl-byacc1.8.tar.Z
--
I found it to be very useful.  The only thing missing now is a lexer.
However because of perl's incredible string handling ability, writing
a lexer isn't too bad.
          -Eric 
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: markh@csd4.csd.uwm.edu (Mark)
Subject: Parsers are easy to write (was: Re: Backtracking yacc)
Reply-To: markh@csd4.csd.uwm.edu (Mark)
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Date: Fri, 25 Sep 1992 22:20:19 GMT
Keywords: parse, LL(1), errors, yacc, comment

andrewd@cs.adelaide.edu.au (Andrew Dunstan) writes:
>There are other reasons - LL parsers are easy to hand craft, making them
>good for teaching purposes (yes, I know we all use calculators, but we
>also have to know how to do arithmetic without them.) They can also be
>very fast.

All deterministic Context Free Grammars (and many of the non-deterministic
ones too) are easy to craft by hand.

In fact, I challenge anyone to find me one that I cannot craft a parser
for by hand in a short time ("short" meaning: less time than it takes to
write and debug an equivalent YACC source).  Something like C is okay,
though it's not deterministic.  But C's syntax is too easy, the operative
word here is Challenge.

Any takers?
[Don't forget to make sure that your hand-written parser diagnoses all invalid
input, as a yacc parser does.  My experience is that the biggest wins from
using yacc are the automatic diagnosis of ambiguous grammars and the extreme
ease of adding little tweaks later on. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers,comp.arch
From: John R. Levine <johnl@iecc.cambridge.ma.us>
Subject: Classic computer books?
Reply-To: John R. Levine <johnl@iecc.cambridge.ma.us>
Organization: Compilers Central
Date: Sun, 4 Oct 1992 05:28:27 GMT
Followup-To: comp.compilers
Keywords: books, question

A friend and I were trying to come up with a list of classic computer
books that we wish we could get but aren't in print any more.  My list so
far has:

Wulf et al., "Design of an Optimizing Compiler"
Bell et al., "Computer Engineering: a DEC View"
Organick, "The Multics System"

and I suppose, the Lions source code book.  What else would people
suggest?  Send me mail and I'll summarize.

Regards,
John Levine, johnl@iecc.cambridge.ma.us, {spdcc|ima|world}!iecc!johnl

-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: plyon@emx.cc.utexas.edu (Paul Lyon)
Subject: Re: language design tradeoffs
Reply-To: plyon@emx.cc.utexas.edu (Paul Lyon)
Organization: The University of Texas at Austin
Date: Sat, 26 Sep 1992 03:30:17 GMT
Keywords: syntax, design, FTP, comment
Posted-Date:  26 Sep 92 03:30:17 GMT

eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig) writes:
> There's no _a_priori_ reason to expect programs to read like novels.

Literate programming fans might disagree :-). And, after all, the concept
has impeccable parentage (Donald Knuth). 

Since matters WEB-ish have been broached several times in this thread, I
surmise there is some interest in literate programming systems.  There is
a fairly complete collection of such on niord.shsu.edu: the original WEB,
Cweb, fweb, spiderweb, funnelweb, and so on.

In the ~ftp/litprog directory on niord, there is a bibliography on
Literate Programming, as well as a collection of posts to date for the
``litprog'' mailing list, and instructions on how to subscribe.  [I did so
several months ago, but have, alas, forgotten the instructions; if there
is interest from those without ftp access, I will retrieve same and do a
follow-up post.]

Very briefly, the original concept of literate programming precisely _was_
to write a program like a book; in Knuth's case, two: _TeX: the Program_
and _Metafont: the Program_. One writes source files containing both code
and documentation; the tangle processor extracts the source code for
compilation, the weave processor prepares a TeX input file. The original
WEB was language-specific (PASCAL), as are Cweb (K&R C), and fweb (FORTRAN
with a built-in version of ratfor, but now also C and C++). Spiderweb is
adaptable to various languages; it comes with a large awk script to read a
file specifying a pretty- printing grammar for the target language which
is then converted to C for inclusion in the code for the tangle and weave
processors.  Grammar files for awk, Ada, C, and C++ are included. Finally,
funnelweb is fully language-independent, but at the price of abandoning
pretty-printing the code: the instructions to TeX are typewriter font and
verbatim formatting for the code; one may, as with the others, use
whatever is compatible with plain TeX in the documentation sections.

Besides the support for better internal documentation and more attractive
hard copy, the chief advantage to the programmer is the capability to
write in something more akin to pseudo-code, substituting descriptive
names of code sections for blocks of code where these are to appear, and
putting the actual code for the block, together with commentary, where it
may seem best. The language specific weave processors also generate an
index of code sections and identifiers at the end of the TeX input file.

Paul Lyon
[To subscribe, mail SUBSCRIBE LITPROG "Your Real Name in Quotes" to
LISTSERV@SHSU.edu. -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: ali@sbcs.sunysb.edu (Ai Li)
Newsgroups: comp.compilers,comp.parallel
Subject: Looking for a data dependence generator
Keywords: parallel, optimize, vector
Date: 28 Sep 92 18:54:41 GMT
Article-I.D.: comp.92-09-198
Reply-To: ali@sbcs.sunysb.edu (Ai Li)
Organization: State University of New York at Stony Brook

Hi,

I am working on a research project for a parallel system and the
project needs a data dependence generator which can detect and
extract all data dependence information (distance vectors, director
vectors, etc) for a given program (mainly for loop structures). Since
lots of work have been done on data dependence analysis for years, I
would like to know whether I could get such a program from somewhere.
I would appreciate greatly if someone could provide me some
information or an available program.

Thanks in advance.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: markh@csd4.csd.uwm.edu (Mark)
Subject: Re: Quantum Parsing (was: Re: Parsers are easy to write)
Reply-To: markh@csd4.csd.uwm.edu (Mark)
Organization: Computing Services Division, University of Wisconsin - Milwaukee
Date: Sat, 3 Oct 1992 16:52:39 GMT
Keywords: parse, yacc, Fortran

dak@kaa.informatik.rwth-aachen.de (David Kastrup) writes:
>Ever written a parser for @#%$#@ Fortran?...

Can't say I ever heard of @#%$#@ Fortran.  Must be a vulgar dialect or
something. :)

>Write a parser for that, if you like. And building a recursive thing
>with backtracking and certain state values produces essentially nothing
>that a parser generator could not produce. Only that you may be less
>efficient. Only pretty simple grammars can be substantially faster
>parsed by a handwritten parser.

I seriously doubt you'll even be able to write a spec to a parser
generator as concise as the result to the technique outlined, much less
generate one.

>[I wrote a yacc parser for Fortran, ... -John]

If you want, we can use the moderator's yacc source as both definition of
the challenge and measure of success.

-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers,comp.human-factors
From: liblit@cs.psu.edu (Benjamin R. Liblit)
Subject: Re: Syntax of Comments (was: language design tradeoffs)
Reply-To: liblit@cs.psu.edu (Benjamin R. Liblit)
Organization: Compilers Central
Date: Tue, 6 Oct 1992 01:07:31 GMT
Keywords: syntax, design

Marc Andreessen <marca@ncsa.uiuc.edu> has written a package for Epoch
(Emacs on steriods for XWindows) called Lightbrite.  It allows regions of
a buffer to be displayed in different styles based, I believe, on regular
expression matching.

The Lightbrite distribution includes a syntax-table analyzer that will
produce comment-matching expressions.  Other syntax features of interest
can, of course, be matched via expressions designed by the user.  I
believe samples for popular languages are included.

Interested parties may FTP to archive.cis.ohio-state.edu, and retrieve
the file "pub/gnu/emacs/elisp-archive/epoch/lightbrite-1.1.2.tar.Z".
--
Ben Liblit
liblit@cs.psu.edu   --   brl102@psuvm.psu.edu   --   brl102@psuvm.bitnet
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: cliffc@cs.rice.edu (Cliff Click)
Subject: Re: Register Files
Reply-To: cliffc@cs.rice.edu (Cliff Click)
Organization: Compilers Central
Date: Tue, 6 Oct 1992 14:58:32 GMT
Keywords: registers, optimize

>[why did DEC compiler writers care if Alpha has combined or separate
>integer and FP registers?]

Some quick problems for the compiler (and compiler writer):

1/2 as many integer or float registers (cannot conveniently put ints in
float registers and vice-versa).  Causes more spilling and requires better
spill-code handling.

Must register-allocate both sets (perhaps two passes with the allocator).

Passing values between register sets often goes through memory.  This
requires some memory space to be handy (i.e. some stack slots available
and a stack pointer defined).  This is slow if not in cache, so you also
have to make sure the required cache line is not being booted out by other
references.

I don't think it has any big implications on scheduling.

Cliff
cliffc@cs.rice.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers,comp.human-factors
From: pcbeard@ucdavis.edu (Patrick C. Beard)
Subject: Re: Syntax of Comments (was: language design tradeoffs)
Reply-To: pcbeard@ucdavis.edu (Patrick C. Beard)
Organization: Department of Computer Science, University of California, Davis
Date: Tue, 6 Oct 1992 17:59:26 GMT
Followup-To: comp.compilers
Keywords: design

de19@umail.umd.edu (Dana S Emery) writes:
>I'm surprised no one has suggested coloration or styling to reflect
>semantics.

People have. Borland C++ on the PC can show different syntactic elements
in different visual styles under Windows. Object Master on the Macintosh
(an integrated editor/browser development environment) does as well.

Everytime I've ever attempted to come up with a design for a color scheme
for the keywords, comments, etc. it always looks ugly. I choose really
muted colors and similar fonts. Nothing beats plain text.

Now, when I want something to really stand out, like a syntax error, or
questionable use, a nice bright red color is good. I think styles that
stand out are good for transient events. When I read code, every line is
of equal importance to me, comments and statements. I agree with the
moderator that this probably won't be standardizable in general, but
perhaps in the areas I mention.

// Patrick C. Beard
// Department of Computer Science, U. C. Davis
// pcbeard@ucdavis.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers