HDTenEightyP/NetNews huggingface dataset:
From: Michael Dyck <dyck@cs.sfu.ca>
Subject: parser-generators for RRPGs
Reply-To: Michael Dyck <dyck@cs.sfu.ca>
Organization: Compilers Central
Date: Thu, 28 Jan 1993 02:02:26 GMT
Keywords: parse, tools, question, comment

Regular right-part grammars (RRPGs) are a kind of phrase structure grammar
akin to context-free grammars (CFGs).  In each production of an RRPG, the
LHS is a single non-terminal (as in a CFG), but the RHS is a regular
expression (or finite automaton) over the symbol set (rather than simply a
sequence of symbols, as in a CFG).

There are various notations for writing RRPGs (or slight restrictions
thereof), many called "extended BNF".

For example (from Modula-2):

if-statement = "IF" condition "THEN" statements
               { "ELSIF" condition "THEN" statements }
               [ "ELSE" statements ]
               "END"

It seems like most grammars presented for human consumption are RRPGs, but
most grammars presented for machine consumption are CFGs.  What
parser-generators are available that accept some form of RRPG?

-Michael Dyck, dyck@cs.sfu.ca
[I've seen occasional references to something called eyacc, which appeared
to be an EBNF version of yacc.  Is it not the case that RRPGs can be
mechanically translated to CFGs, in which case a preprocessor for a normal
parser generator might make sense? -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: s2861785@techst02.technion.ac.il (Alon Ziv)
Subject: Optimizations for Pipelined Processors
Reply-To: s2861785@techst02.technion.ac.il (Alon Ziv)
Organization: Compilers Central
Date: Thu, 21 Jan 1993 11:13:46 GMT
Keywords: optimize, parallel, question, comment

During a discussion with a friend who works for Intel in microprocessor
developement, we found out that nothing is ever taught about implementing
compiler back-ends for pipelined processors; in fact, it would even seem
that some common optimizations would be potentially harmful on such a uP,
while others---such as loop unrolling---have unexpected benefits.
Moreover, there are some ``weird'' schemes used by assembly programmers on
such processors (such as `mixing' instruction sequences for long,
essentially independent computations) which are far out from standard
practice in optimization.

So, the question is: _is_ there any research going on for these ideas?  I
would assume that it has started, and---if so---would very much like to
have some references about progress so far, as it seems to be
(potentially, at least) VERY interesting.

		Alon Ziv
--
Internet:	s2861785@t2.technion.ac.il			   . __
[There's been plenty of work on pipeline scheduling.  I'm sure readers will
send in citations. -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: Alain.Callebaut@cs.kuleuven.ac.be (Alain Callebaut)
Subject: Re: Different Strokes for Different Folks (Was: Assessing a language)
Reply-To: Alain.Callebaut@cs.kuleuven.ac.be (Alain Callebaut)
Organization: BIM Belgium
Date: Mon, 25 Jan 1993 10:12:25 GMT
Keywords: prolog, functional

Peter Ludemann writes :
> Two Prolog implementations that have good foreign language interfaces are
> IBM Prolog (CMS, MVS, OS/2) and Quintus Prolog (Unix, DOS).  No doubt
> there are others.

Sure, there are !
Maybe you forgot the Prolog review that was published in AI Expert of
January 1991 (page 45-50 for the SPARC Prolog systems).

For years now, ProLog by BIM has had an extremely flexible and advanced
interface between Prolog and other languages, including C, Pascal and
Fortran.  It enabled us to write interfaces to windowing systems and data
bases.  Our very first SunView interface (dating from the beginning of
SunView itself), was quite complete, and we did not need any tricks to
bypass shortcomings of the provided interface facilities.  The
backtracking example you mention, will be solved much cleaner and with
less burden for the programmer in the forthcoming release of ProLog by
BIM.

Alain Callebaut
BIM - ProLog Development
ac@sunbim.be

-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: dww@inf.fu-berlin.de
Subject: Benefits of hand-coded bottom-up parsers
Reply-To: dww@inf.fu-berlin.de
Organization: Free University of Berlin
Date: Tue, 26 Jan 1993 11:31:57 GMT
Keywords: parse, courses, LR(1)

I don't really want to fan the flame wars, but I must stress the benefits
of hand-coding an LR parser if your goal is to understand parsing.

My advisor insisted that I hand code an LR-parser for a language with 59
productions, mostly trivial. We fought about this for almost a year: I
felt it was a waste of time, too messy, etc.  After a blazing fight I sat
down and did it. I generated the yacc tables first, so that I knew where I
was going. It took about 5 iterations and much gnashing of teeth before I
was able to produce the yacc table myself.

I was then required to draw the state machine on a piece of paper. I
complained. My advisor said: "Take a *big* piece of paper and get
started!" I bought a roll of packing paper and began. During the process
of fitting the 118 states and the over 300 transitions onto a flat piece
of paper, I began to *really* understand what actually is happening during
parsing. I saw how the prefixes are recognized.  I "discovered" a number
of theorems that of course have been proved for ages. I now have an
excellent "Gedankenmodell", a thought model of the bottom-up parsing
process, and find it easy to understand theoretical papers about
LR-parsing.

I don't think it is necessary to do such a large language, but even to
hand-construct LR-tables for the expression grammar will give you a
lasting insight into the parsing process. Of course, a large language
gives you a nice big poster to hang on the walls - mine is 600x100 cm !
--
Debora Weber-Wulff                       dww@inf.fu-berlin.de
Institut fuer Informatik                 +49 30 89691 124
Nestorstr. 8-9
D-W-1000 Berlin 31
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: mdg@netcom.com (Mark Grand)
Subject: P-Code (was Re: [TDR] Token-Based Compilers)
Reply-To: mdg@netcom.com (Mark Grand)
Organization: Premenos
Date: Tue, 26 Jan 1993 01:18:01 GMT
Keywords: design

pcbeard@ucdavis.edu (Patrick C. Beard) said:
> I believe Microsoft uses P-Code in many of its shipping
> products for the Macintosh. ... I am very interested in finding out what
> the various trade-offs are in compiling to pseudo code. And what type of
> instructions to provide. I am thinking very seriously about
> writing a C interpreter using just such a technique. Has
> anybody any references on designs of P-Code instruction sets?

The P-Code that Microsoft uses is for the purpose of minimizing the isze
of the executable.  The p-code that they use is substantially more compact
than native 8086 code.

Another circumstance in which p-code is a reasonable choice is when there
is an enormous semantic gap separating the source language from the native
instruction set.  For example, there are a number of specialized languages
for building database related applications.  Because of the large number
of operations they perform related to database manipulation, data
formatting and screen formatting, well over 90% of the time in these
programs is spent inside of the equivalent of a run time library.  For
languages such as these, compiling to machine code does not usually
provide enough of an improvement to justify the effort of implementing a
machine code back end.

Yet another advantage of P-Code is that it can provide hardware
independence.  P-Code can be designed so that it can be moved from one
type of computer hardware to another without need for access to source
code.
--
Mark Grand
Premenos Corporation                510-602-2000
1000 Burnett, Second Floor          mark@premenos.sf.ca.us
Concord, CA   94520
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: zstern@adobe.com (Zalman Stern)
Subject: Re: justify use of flex vs lex
Reply-To: zstern@adobe.com (Zalman Stern)
Organization: Adobe Systems Incorporated
Date: Tue, 26 Jan 1993 23:30:15 GMT
Keywords: lex, flex

swl26@cas.org (Steve Layten x3451) writes:
[Asks about vendor support of lex.]

My impression from having worked at a UNIX vendor is the only way lex
would get fixed is if USL did the work. Code like lex originates off some
source distribution and then percolates through N layers of source control
and finally makes it into a build. The build is regression tested and so
long as nothing fails, it's shipped. Vendors are loathe to fix something
like lex because they have to merge their fixes the next time they get a
source drop.  And given that most people have either learned to work
around the bugs or picked up flex instead, there is little incentive to do
so.

The easy way to get around stupid management restrictions in this case is
to bundle flex with your project's code. Have the build mechanism build
the tool first and you're in business. (If your management asks why you
didn't use lex, they're probably smart enough to understand a detailed
description of how lex is broken...)
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers,comp.lang.fortran
From: apofort!metcalf@dxmint.cern.ch (Michael Metcalf)
Subject: Re: Wanted: folk theorems in Fortran Programming.
Reply-To: apofort!metcalf@dxmint.cern.ch (Michael Metcalf)
Organization: CERN European Lab for Particle Physics
Date: Thu, 28 Jan 1993 07:42:35 GMT
Keywords: Fortran, books

steve@hubcap.clemson.edu ("Steve" Stevenson) writes:
>I am trying to make a catalog of folk wisdom in fortran programming.

I collected such wisdom some time ago and published it as "FORTRAN
Optimization", Academic Press, 1985, ISBN 0-12-492482.4. It contains an
extensive bibliography.

It discusses in gory detail not only the examples given by the poster, but
also the I/O list optimization problem that featured in this news group
recently.

A shorter summary appears as Chapter 11 of "Effective FORTRAN 77", Oxford
U. Press, 1985 (busy year), ISBN 0-19-853709-3.

  Hope this helps,

                  Mike Metcalf
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: zstern@adobe.com (Zalman Stern)
Subject: Re: Architecture description languages for compilers?
Reply-To: zstern@adobe.com (Zalman Stern)
Organization: Adobe Systems Incorporated
Date: Thu, 28 Jan 1993 04:50:39 GMT
Keywords: architecture, GCC

pardo@cs.washington.edu (David Keppel) writes:
> It is an amusing exercise to compare the listed md sizes for the Thompson
> compiler to the GCC md sizes for the same machines.  I can't say whether
> the code is comparable: Thompson claims the compile time is half that of
> GCC and run time is 75% that of GCC, but it shows only slightly better run
> times than lcc, and a previous comp.compilers article said lcc was
> substantially worse than GCC.

1) What programs are used for the execution time comparisons? If you are
willing to do a lot of hand optimization of C code, then you can get good
performance with relatively simple compilers. (E.g. should the compiler do
induction variable optimization/strength reduction or should the
programmer code pointer arithmetic?) My impression is that the Thompson
and friends lean towards the simpler compiler approach.

2) GCC's machine description language is notable for supporting a large
number of architectures and having good documentation. It also serves as
an opportunity to study the evolution of an intermediate language as the
number of architectures and optimization quality both increase. (In fact
it may be worth studying the "distributed software engineering" aspects of
the compiler but that's off the subject.)
--
Zalman Stern		   zalman@adobe.com		    (415) 962 3824
Adobe Systems, 1585 Charleston Rd., POB 7900, Mountain View, CA 94039-7900
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: glew@pdx007.intel.com (Andy Glew)
Subject: Re: Code quality
Reply-To: glew@pdx007.intel.com (Andy Glew)
Organization: Intel Corp., Hillsboro, Oregon
Date: Mon, 25 Jan 1993 07:59:06 GMT
Keywords: optimize

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

From a hardware company's point of view:
========================================

10% is *definitely* interesting.

Even 1% wins are interesting, because if you get enough of them...

Modern microprocessors of comparable price sit in a range of maybe 40%.
10% is a significant chunk of your competitive advantage. It's equivalent
to a few months of hardware development. If you don't go for the
optimizing compiler, your competitor will.

Moreover, compilers have the advantage of being able to be released
*between* silicon releases - giving a midlife kicker to your product.


On the other hand:
==================

I've heard of software companies for which compile time is everything, who
refuse to add optimizations that will make -O more than twice as slow as
non-optimizing.

The marketplace takes all kinds.
--
Andy Glew, glew@ichips.intel.com
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy, 
Hillsboro, Oregon 97124-6497
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: pardo@cs.washington.edu (David Keppel)
Subject: Re: Architecture description languages for compilers?
Reply-To: pardo@cs.washington.edu (David Keppel)
Organization: Computer Science & Engineering, U. of Washington, Seattle
Date: Thu, 28 Jan 1993 00:06:29 GMT
Keywords: architecture, VHDL

brent@eng.uiowa.edu (Brent H. Pease) writes:
>>[Machine descriptions for code generation.]

Ken Thompson ("A New C Compiler", Proceedings of the Summer 1990 UKUUG
Conference, London, July 1990; avaialable via anonymous ftp from
research.att.com in dist/plan9doc/8.Z) claims that it was easier for him
to hard-code a new code generator for each back end than it was to write a
machine description.

It is an amusing exercie to compare the listed md sizes for the Thompson
compiler to the GCC md sizes for the same machines.  I can't say whether
the code is comparable: Thompson claims the compile time is half that of
GCC and run time is 75% that of GCC, but it shows only slightly better run
times than lcc, and a previous comp.compilers article said lcc was
substantially worse than GCC.

At any rate, any study of machine description languges should mention the
compiler.

		;-D on  ( Architec tour guide )  Pardo
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: j0c1099@sigma.tamu.edu (CHOOBINEH, JOOBIN)
Subject: SQL Interpreter
Reply-To: j0c1099@sigma.tamu.edu (CHOOBINEH, JOOBIN)
Organization: Texas A&M University, Academic Computing Services
Date: Thu, 21 Jan 1993 16:30:00 GMT
Keywords: SQL, question, comment

Is any one aware of a public domain or inexpensive source code in C for
interpreting/compiling SQL?

Any help, hints, or directions will be greatly appreciated.

Joobin Choobineh
Department of Business Analysis and Research
Texas A&M University
College Station, Texas 77843
(409) 845-4048
[There are several free SQL parsers, but no free interpreters that I know of.
Perhaps an inexpensive PC database would do the trick.  Even once the SQL
is compiled, you need an index search and update engine to do the work. -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: davidm@questor.rational.com (David Moore)
Subject: Re: Optimizations for Pipelined Processors
Reply-To: davidm@questor.rational.com (David Moore)
Organization: Rational
Date: Fri, 22 Jan 1993 22:58:25 GMT
Keywords: optimize, parallel

s2861785@techst02.technion.ac.il (Alon Ziv) writes:
> Is any work going on into optimisations using loop unrolling
> and loop merging 

Machines on which these optimizations are valuable are by no means new.
The Control Data 6600 was an early (circa 1972) example. 

This machine had a large number of ALU units which could perform a number
of operations simultaneously. Modern processors achieve the same thing by
pipe-lining, but the effect on the compiler writer is the same. However,
the time taken to do one operation was typically 10 times the issue rate,
which is 2-3 times slower than modern machines, and that made the
optimizer's task more difficult.

One oddity caused by this was that a ternary chop would in theory run
faster than a binary search!

However, this machine had a 7 word (14 to 28 instruction) cache which
avoided instruction fetches from memory if you could stay within it.
Hence, stuffing loops was often not worthwhile if the individual loops
would fit in the cache.

A similar situation occurs on modern processors. On a Risc chip,
instructions are often fetched using static column mode. Unrolling a loop
so that it crosses a page boundary will slow rather than speed execution
if the only saving was the loop jump (if the loop has dead time, you may
still gain more than you lose from instruction overlapping)

I just pulled down Sigplan Notices Vol 27 No 7, which is the proceedings
of the 92 Sigplan conference, and found.

Delineraization: An Efficient Way to Break Multiloop Dependence Equations,
Vadim Maslov (maslov@vadik.srcc.msu.su)

Beyond Induction Variables, Michael Wolfe

The bibliographies of these, and previous years' proceedings
represent a good place to start.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: lka@lems17lems.brown.edu (Lalit K. Agarwal)
Subject: Control To Data Dependence
Reply-To: lka@lems17lems.brown.edu (Lalit K. Agarwal)
Organization: Laboratory for Engineering Man/Machine Systems
Date: Sat, 23 Jan 1993 00:34:26 GMT
Keywords: optimize, analysis

Has anyone played with converting CONTROL-DEPENDENCE to DATA-DEPENDENCE in
High-Level-Synthesis or come across any algorithm for doing it in the
literature.?  All suggestions are highly welcome.

thanks,

Lalit K. Agarwal (lka@lems.brown.edu)
Dept. of Computer Engg.
Brown University,
Providence, RI-02912
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: g9gwaigh@cdf.toronto.edu (Geoffrey P Waigh)
Subject: Re: Searching for C compilers for 8051
Reply-To: g9gwaigh@cdf.toronto.edu (Geoffrey P Waigh)
Organization: University of Toronto Computing Disciplines Facility
Date: Sat, 23 Jan 1993 01:16:40 GMT
Keywords: C

maa@edsdrd.eds.com (Matthew Maa) writes:
>I am looking for C compilers that would generate machine code for 8051.

A couple of years ago I was looking for 8051 and other Intel embedded
controller cross-compilers.  Byte listed several companies that targeted
that market, I would think they still would. (You will probably have to
read all the cheap ads at the back as well.)  Several of them provided
reasonably complete compile/link/debug environments.

Geoffrey Waigh
g9gwaigh@cdf.utoronto.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: maa@edsdrd.eds.com (Matthew Maa)
Subject:  Searching for C compilers for 8051
Reply-To: maa@edsdrd.eds.com (Matthew Maa)
Organization: Compilers Central
Date: Fri, 22 Jan 1993 13:29:16 GMT
Keywords: C, question, comment

I am looking for C compilers that would generate machine code for 8051.
If you know any such compiler, would you please email me the following
information.

*) the company name or author name,
*) address, email address, phone number, or fax number,
*) product price,
*) other features, if any.

Even a partial information is highly appreciated.  I will summarize the
responses.  Thanks in advance.

Matthew Maa
--
Email: maa@edsdrd.eds.com               EDS Research & Development
Phone: 313-265-4010                     901 Tower Drive, 1st Floor
Fax:   313-265-4039                     Troy, MI 48098-7019
[When this question came up last year, the only response was the Hitech
compiler from Australia. -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: pcbeard@ucdavis.edu (Patrick C. Beard)
Subject: Re: [TDR] Token-Based Compilers
Reply-To: pcbeard@ucdavis.edu (Patrick C. Beard)
Organization: Department of Computer Science, University of California, Davis
Date: Sat, 23 Jan 1993 01:40:51 GMT
Keywords: Pascal, interpreter, comment

tdarcos@mcimail.com (Paul Robinson) writes:
>I'd like to ask what people think of the idea of Compilers that generate
>ficticious machine code, i.e. tokens for an optimized machine which is
>then interpreted on the target.  

I believe Microsoft uses P-Code in many of its shipping products for the
Macintosh. Microsoft Word has an enormous 'PCOD' resource in it, which I
take to be the result of some kind of cross-platform compilation tool.

I am very interested in finding out what the various trade-offs are in
compiling to pseudo code. And what type of instructions to provide. I am
thinking very seriously about writing a C interpreter using just such a
technique. Has anybody any references on designs of P-Code instruction
sets?

// Patrick C. Beard
// Department of Computer Science, U. C. Davis
// pcbeard@ucdavis.edu
[Microsoft has always used p-code for all versions of Word.  The p-code
compiler used to be internal only until it was made part of MS C.  Current
versions of their C compiler can generate p-code and come with the
interpreter.  As you might expect, the p-code is considerably smaller and
slower than native code. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers