The World of Computer Software/World_Of_Computer_Software-02-387-Vol-3of3.iso/c/comp9302.zip/93-02

Text File | 1993-02-28 | 419KB | 10,296 lines

From compilers Mon Feb  1 07:00:12 EST 1993
Xref: iecc comp.compilers:4171 news.answers:5261
Newsgroups: comp.compilers,news.answers
Path: iecc!compilers-sender
From: [e-mail] (John R. Levine)
Subject: comp.compilers monthly message and Frequently Asked Questions
Message-ID: <[e-mail]>
Followup-To: poster
Keywords: administrivia
Sender: [e-mail]
Supersedes: <[e-mail]>
Organization: Compilers Central
Date: Mon, 1 Feb 1993 12:00:06 GMT
Approved: [e-mail]
Expires: Mon, 1 Mar 1993 23:59:00 GMT

Archive-name: compilers-faq

This is the comp.compilers monthly message, last edited February 1993.

NOTE:  At the end of this message are some answers to frequently asked
questions.  Please read them before you post.

-- What is comp.compilers?

It is a moderated usenet news group addressing the topics of compilers in
particular and programming language design and implementation in general.
It started in 1986 as a moderated mailing list, but interest quickly grew to
the point where it was promoted to a news group.  Recent topics have
included optimization techniques, language design issues, announcements of
new compiler tools, and book reviews.

Messages come from a wide variety of people ranging from undergraduate
students to well-known experts in industry and academia.  Authors live all
over the world -- there are regular messages from the U.S, Canada, Europe,
Australia, and Japan, with occasional ones from as far away as Malaysia.  I
have no idea how large the readership is, since the anarchic nature of
usenet makes it impossible to tell who reads it, but I believe that the total
is in the tens of thousands.

Unless there is specific language to the contrary, each message represents
only the personal opinion of its author.  I claim no compilation copyright on
comp.compilers.  As far as I am concerned, anyone can reproduce any message
for any purpose.  Individual authors may retain rights to their messages,
although I will not knowingly post anything that does not permit unlimited
distribution in any form.  If you find comp.compilers useful in writing a
book, producing a product, etc., I would appreciate an acknowledgement of
usenet and comp.compilers.

-- How do I receive it?

The easiest way is to read comp.compilers on a system that gets usenet news.

If you don't have access to usenet news, it's also available via E-mail via
a LISTSERV forwarder at the American University.  To subscribe a person
should send e-mail to [e-mail] with one line in the mail
message (not in the subject!)  That line should read:

                        SUBSCRIBE COMPIL-L full_name
for example:
                        SUBSCRIBE COMPIL-L Ima Hacker

To get off the list the subscriber should send e-mail to the same address
with the message:       SIGNOFF COMPIL-L

If you have problems getting on or off the list, please contact me.  In
particular, if you want to use an address other than your own personal mail
address, you have to ask me to set it up.

-- How do I submit a message?

Mail it to [e-mail], also known as [e-mail]
or iecc!compilers.  I review messages nearly every day, usually including
weekends, and most messages are posted to the net within a day after I
receive them.  Occasionally when I go on vacation there may be up to a
week's delay, though I try to send out a message when that will happen.

Most net news systems will automatically turn posted messages into mail to
compilers, but some, particularly systems running notes, don't do that
correctly.  As a result, I sometimes receive hundreds of copies of a
message, all mangled slightly differently.  Please mail your contributions
unless you're sure your posting software works correctly.

When you send a message to compilers, I understand that to mean that you
want me to post it to usenet, which means it will be sent to tens of
thousands of potential readers at thousands of computers all around the
world.  It may also appear in a printed comp.compilers annual and other
books, in the ACM SIGPLAN Notices, in on-line and off-line archives,
CD-ROMs, and anywhere else that some reader decides to use it.

If you don't want me to post something, send it instead to
compilers-request.  (See below.)

-- What happens to submitted messages?

Barring mail problems, they arrive in a special mailbox here at iecc.  I
then edit the headers, trim down quoted text, fix typos and grammatical
errors, remove cute signatures, and then post them to usenet.  If I think a
message needs more editing than that, I return it to the author for
rewriting.  The main reasons I return a message are that it appears more
appropriate for another group, the message is too garbled to fix, it
contains too much quoted material relative to the amount of new material, or
I don't understand it.  I also usually return messages that directly attack
individuals, since the net has plenty of other places for ad-hominem battles.
Another possibility is that a message doesn't have a valid return e-mail
address.  If your mail system insists on putting a bogus address in the From:
line, be sure that you put a usable address in your signature.

If a message asks a simple question I sometimes answer it myself rather than
posting it.  When two or three messages arrive with the same answer to a
question, I usually post only one of them, with a comment crediting the
others.

If you send in a message and don't either see it posted or receive something
back in a few days, it probably got lost in the mail and you should contact
me, preferably via a different mail route.  I post or respond to all
messages except for ones that appear to have been sent by mistake, e.g. no
contents, or contents consisting only of another quoted message.  Sometimes
when I'm feeling exasperated I disregard messages that re-ask one of the
frequently asked questions that are answered below.

One of the most time-consuming jobs in moderating the group is trimming down
the quotes in followup articles.  In most cases, you can expect readers to
have seen the previous article, so only a few lines of quoted text should be
needed to remind the reader of the context.

I have installed a simple-minded quote filter that mechanically returns to
the sender any message that contains more quoted than unquoted lines.  Please
edit your quotes before you send in a response, to avoid having the filter
bounce your message.  Since the quote filter is pretty dumb, I do look at
bounced messages myself.  If the filter bounces a message of yours by mistake,
don't panic -- it'll get posted anyway.

``Help wanted'' and ``Position Available'' messages are collected each week
and posted in a digest every Sunday.

-- How do I respond to the author of a message?

I try to be sure that every message contains valid From: and Reply-To:
headers.  The automatic "reply" commands in most news readers let you send
mail to the author.  If you're replying to a message in a digest, be sure
to respond to the author of the particular message, not to the pseudo-author
of the digest.

Some obsolete news readers attempt to reply using the Path: header, but for
technical reasons the Path: header in a moderated message cannot point to
the actual author.  In fact, the Path: header in a compilers message is
deliberately a bad mail address, so if you have such a news reader you'll
have to edit the addresses in responses yourself and, I hope, encourage your
system manager to update your news and mail software.

Sometimes mail to an author bounces, either because a gateway isn't
working or because the return address is unregistered or otherwise bad.
Please don't ask me to forward it, since my machine is no better connected
than anyone else's.  (It's not on the Internet and only talks uucp.)  If
you send me a message obviously intended for the author of an item, I will
discard it on the theory that if it wasn't important enough for you to
send it to the right place, it isn't important enough for me, either.

-- How do I contact the moderator?

Send me mail at [e-mail].  If for some
reason your system chokes on that address (it shouldn't, it's registered)
mail to [e-mail] or [e-mail] will get to me.  I treat
messages to compilers-request as private messages to me unless they state
that they are for publication.

-- Are back issues available?

I have complete archives going back to the original mailing list in 1986.
The archives now fill about 6 megabytes, and are growing at over 200K per
month.  I update the archives at the end of each month.  People with ftp
access can get them from primost.cs.wisc.edu, (128.105.2.115) where James
Larus has kindly provided space.  The archives contain a compressed Unix
mailbox format file for each month, with names like 91-08.Z.  The file
INDEX.Z lists all of the subject lines for every message in the archives,
and in most cases is the first file you should retrieve.

The archives are available via modem from Channel One, an excellent local
BBS.  You have to register, but no payment is needed to download the
archives which are in Area 6.  (If you call more than once or twice, it
would be nice to sign up for at least the $25 trial membership.)  The 2400
BPS telephone number is [phone], and the Telebit number is +1 617
354 0470.  There is a ZIP format archive per month with names like
comp9108.zip, with the most recent archive also containing the index.

There is now a mail server at [e-mail] that can
mail you indexes, messages, and the files mentioned below.  Send it a
message containing "help" to get started.

I have also published a printed edition of the 1990 messages grouped
by thread and topic, and with some indexes, and expect to publish a
1992 and maybe 1991 edition.  Send me mail for further details, or
see the message about the book which should immediately follow this
one.

-- Some Frequently Asked Questions:

NOTE: Many issues are discussed occasionally on comp.compilers, but not
frequently enought to make the FAQ sheet.  If you have a question but the
answer isn't in the FAQ, you may well be able to get good background by
reading the appropriate articles in the archive.  If you can FTP, please
at least get the index and look through it.

The various files that I mention below that I have are in the compilers
archive at primost.cs.wisc.edu, and are also available from the mail
server mentioned above.  If you can FTP them, please do so rather than
using the mail server, since the mail bandwith is quite small.

* Where can I get a C or C++ grammar in yacc?

Jim Roskind's well-known C++ grammar is in the archive, as is a C grammar
written by Jeff Lee.  Dave Jones posted a parser as message 91-09-030.
Another C grammar was posted to comp.sources.misc in June 1990, v13 i52,
archive name ansi-c_su.  GCC and G++ are based on yacc grammars, see
below.

* Where can I get the Gnu C compiler?

GCC is a high-quality free C and C++ compiler.  (Free is not the same as
public domain, see the GCC distribution for details.)  It is available in
source from from prep.ai.mit.edu.  You need an existing C compiler and
libraries to bootstrap it.

A version for 386 MS-DOS by DJ Delorie <[e-mail]> is available by FTP
from barnacle.erc.clarkson.edu or wowbagger.pc-labor.uni-bremen.de and by
mail from [e-mail] in the archive msdos/djgpp.
See messages 91-09-054 and 91-09-066.

* Are there other free C compilers?

The lcc compiler, written by people at Princeton and Bell Labs, is
available via FTP from princeton.edu.  It is supposed to generate code as
good as GCC while being considerably faster and smaller.  It comes with a
demonstration VAX code generator and documentation on the code generation
interfaces.  Production code generators for the VAX, MIPS, and Motorola
68020 are available for research use to universities willing to execute a
license agreement; the FTP package elaborates.  Lcc uses a hard-coded C
parser because it's faster than yacc.

* Where can I get a Fortran grammar in yacc?

I have a small subset parser in the archive mentioned above.  The F2C
Fortran to C translator contains a full F77 parser and is available in
source form via FTP from research.att.com and by mail from
[e-mail].

* Where can I get Modula-2, Pascal or Ada grammars in yacc?

I have one each of those, too, in the archive mentioned above, though I
haven't tried to use any of them.

* Where can I get a Cobol grammar in yacc?

Nowhere for free, as far as I can tell.  This question is asked every few
months and there has never, ever, been any positive response. Perhaps some
of the interested people could get together and write one.  The commercial
PCYACC from Abraxas (see below) comes with a bunch of sample grammars
including one for Cobol-85.

* Where can I get a Basic grammar in yacc?

Take a look at ftp.uu.net:comp.sources.unix/volume2/basic which contains
a Basic interpreter with yacc parser.

* Are there free versions of yacc and lex ?

Vern Paxton's flex is a superior reimplementation of lex.  It is available
from the same places as Gnu sources.  Berkeley Yacc is a quite compatible
PD version of yacc by Bob Corbett, available as ~ftp/pub/byacc.tar.Z on
okeeffe.berkeley.edu.  Gnu Bison is derived from an earlier version of
Corbett's work and is also fairly compatible with yacc.

* Are there versions of yacc and lex for MS-DOS?

There are several of them.  Commercial versions are MKS lex&yacc from MKS
in Waterloo Ont., [phone] or [e-mail], and PCYACC from
Abraxas Software in Portland OR, [phone].  Both include both yacc
and lex along with a lot of sample code.

The standard flex source compiles under the usual DOS compilers, although
you may want to make some of the buffers smaller.  A DOS version of Bison
is on wuarchive.wustl.edu [128.252.135.4] and other servers under
/mirrors/msdos/txtutl/bison111.zip. See message 92-07-012 for more info.

* What other compilers and tools are freely available?

There is a two-part FAQ posting in comp.lang.misc, comp.sources.d,
comp.archives.admin, and news.answers listing compiler tools freely
available in source form, maintained by David Muir Sharnoff
<[e-mail]>.  It is posted once every three months.  If it's
not on your system, you can FTP it from pit-manager.mit.edu in the
directory /pub/usenet/news.answers/free-compilers, or via mail by sending a
message to to [e-mail] with the command "send
usenet/news.answers/free-compilers/*" in the text.

* How can I get started with yacc and lex and compiler writing in general?

By reading any of the many books on the topic.  Here are a few of them.
Also see message 93-01-155 which reviews many compiler textbooks.

Aho, Sethi, and Ullman, "Compilers: Principles, Techniques, and Tools,"
Addison Wesley, 1986, ISBN 0-201-10088-6, the "dragon book".  Describes
clearly and completely lexing and parsing techniques including the ones in
yacc and lex.  The authors work or have worked at Bell Labs with Steve
Johnson and Mike Lesk, the authors of Yacc and Lex.

Alan Holub, "Compiler Design in C," Prentice-Hall, 1990, ISBN
0-13-155045-4.  A large book containing the complete source code to a
reimplementation of yacc and lex and a C compiler.  Quite well written,
too, though it has a lot of errors.  The fourth printing is supposed to
correct most of them.

John R. Levine, Tony Mason, and Doug Brown, ``Lex & Yacc,'' 2nd Edition,
O'Reilly and Associates, 1992, ISBN 1-56592-000-7, $29.95.  A concise
introduction with completely worked out examples and an extensive
reference section.  The new edition is completely revised from the earlier
1990 edition.

Donnely and Stallman, "The Bison Manual," part of the on-line distrubution
of the FSF's Bison, a reimplementation of yacc.  As with everything else from
the FSF, full source code is included.

Axel T. Schreiner and H. George Friedman, Jr., "Introduction to Compiler
Construction with UNIX," Prentice-Hall, 1985.  Oriented to tutorial work.
Good for beginners.  Develops a small subset-of-C compiler through the book.
(Recommended by Eric Hughes <[e-mail]>.)  Richard Hash
<[e-mail]> comments that the book has many typographical errors, and
readers should be suspicious of the examples until they actually try them.
Richard Y. Kim <[e-mail]> reports that sources are available for
FTP as a.cs.uiuc.edu:pub/friedman/tar.

Bennett, J.P. "Introduction to Compiling Techniques - A First Course Using
Ansi C, Lex and Yacc," McGraw Hill Book Co, 1990, ISBN 0-07-707215-4.
It's intended for a first course in modern compiler techniques, is very
clearly written, and has a full chapter on YACC.  I found it to be a good
introductory text before getting into the 'Dragon book'.  (Recommended by
John Merlin <[e-mail]>.)  Source code is available
at ftp.bath.ac.uk.

Charles N. Fischer & Richard J. LeBlanc, "Crafting A Compiler", Benjamin
Cummings Publishing, Menlo Park, CA, 1988, ISBN 0-8053-3201-4.  There's
also a revised version as of 1990 or 1991 titled "Crafting A Compiler in
C", with all examples in C (the original used ADA/CS).  Erich Nahum
<[e-mail]> writes: A key compiler reference.  We used the
original to great effect in Eliot Moss' graduate compiler construction
class here at UMass.  My feeling is that Fischer & LeBlanc is a good
tutorial, and one should use Aho, Sethi, & Ullman as a reference.

Des Watson, "High-Level Languages and Their Compilers," International
Computer Science Series, Addison-Wesley Publishing Company, Wokingham
England, 1989.  Adrian Howard <[e-mail]> writes: This is
the kindest, most readable introduction to compilers at the graduate level
I have ever read - an excellent example of what textbooks should all be
like.

W.M. Waite and G. Goos, "Compiler Construction," Springer-Verlag, New
York, 1984.  Dick Grune <[e-mail]> writes: A theoretical approach to
compiler construction. Refreshing in that it gives a completely new view
of many subjects. Heavy reading, high information density.

J.P. Tremblay and P.G. Sorenson, "The Theory and Practice of Compiler
Writing," McGraw-Hill, 1985.  Dick Grune <[e-mail]> writes: Extensive
and detailed. Heavy reading. To be consulted when other sources fail.

James E. Hendrix, "The Small-C Compiler", 2nd ed., M&T Books, ISBN
0-934375-88-7 <Book Alone>, 1-55851-007-9 <MS-DOS Disk>,
0-934375-97-6 <Book AND Disk>.

William Jhun <[e-mail]> writes: It explaines the C-language is
thorough....and explains every single aspect of the compiler. The book
compares source code to p-code to assembly. It goes over a nice set of
optimization routines, explains the parser, the back end, and even
includes source code, which the compiler on the disk can actually compile
itself. It's an extremely interesting book, check it out.

If anyone sends in others, I'll be happy to add them to the list.

* Where I can I FTP the sources to the programs in Holub's "Compiler
Design in C" ?

You can't.  See page xvi of the Preface for ordering information.

Regards,
John Levine, comp.compilers moderator
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 07:00:20 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (John R. Levine)
Subject: Comp.compilers 1990 Annual
Message-ID: <[e-mail]>
Keywords: administrivia
Sender: [e-mail]
Supersedes: <[e-mail]>
Organization: Compilers Central
Date: Mon, 1 Feb 1993 12:00:15 GMT
Approved: [e-mail]
Expires: Mon, 1 Mar 1993 23:59:00 GMT

NOTE: This is a monthly repost of the message about the printed version of
the 1990 comp.compilers message.

            Comp.compilers 1990 Annual
             Edited by John R. Levine

The Comp.compilers 1990 Annual is a printed edition of the messages posted
to the usenet newsgroup comp.compilers in 1990.  Usenet is an informal
distributed electronic bulletin board system connecting thousands of
computers around the world.  Most of the systems attached to it run some
version of Unix, though others systems ranging from MS-DOS personal
computers to Cray mainframes now participate.  Comp.compilers is a
moderated usenet news group addressing the topics of compilers in
particular and programming language design and implementation in general.
It started in 1986 as a moderated mailing list, but interest quickly grew
to the point where it was promoted to a news group.  Recent topics have
included optimization techniques, language design issues, announcements of
new compiler tools, and book reviews.

Messages come from a wide variety of people ranging from undergraduate
students to well-known experts in industry and academia.  Authors live all
over the world - there are regular messages from the U.S, Canada, Europe,
Australia, and Japan, with occasional ones from as far away as Malaysia.
The anarchic nature of usenet makes it impossible to tell how large the
readership is, but the total is probably in the tens of thousands.

The book's contents include 807 of the year's total 914 messages, leaving
out only administrative messages and unanswered questions.  The messages
themselves are unedited except for removing boilerplate header and trailer
lines.

The book is 604 pages, each 11 x 8.5 inches with two pages of text side by
side in reasonably legible 8 point type.  Messages are grouped by topic
(C, optimization, book reviews, etc.) and within each topic messages in a
thread are grouped together.  There is a permuted subject index, a keyword
index, and an author index.  The book is GBC bound, a plastic spiral
binding that lies flat.

Pricing

The price is $40 per book, plus $2 sales tax for copies delivered in
Massachusetts, plus appropriate postage and packaging per copy:

  Pick up in Cambridge  free |  Foreign surface        $10
  U.S. surface            $3 |  Foreign airmail:
  U.S. priority           $5 |             Americas    $12
  U.S. Federal Express   $20 |             Europe      $20
  Canada              $7 |             All other   $30

No further discounts apply on single copies of the book, as this price is
pre-discounted from the list price of $50.  Quantity discounts and
shipping charges for large or unusual orders can be negotiated.

How to order

All orders must be prepaid.  Send a check payable to I.E.C.C. along with
the delivery address.  We cannot take purchase orders, credit cards, or
COD orders.  Foreign orders must be prepaid in U.S. dollars, preferably by
a check on a U.S. bank, but anything our bank can handle is acceptable.
(They charge $20 extra for foreign checks and $5 for incoming bank wires.)

The mailing address is:

I.E.C.C.
P.O. Box 349
Cambridge MA 02238-0349

The book is also available at list price from several bookstores.
Being real bookstores, they take credit cards and the like.

    Computer Literacy Bookshop, 2590 N 1st St, San Jose CA 95131
        [phone], [e-mail]

    Quantum Books, 4 Cambridge Center, Cambridge MA 02141
        [phone], [e-mail]

The book has ISBN 0-944954-02-2, and is under the imprint of Center Book
Publishers, Inc.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:09:12 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: Michael John Haertel <[e-mail]>
Subject: Thompson's 2c vs. gcc
Message-ID: <[e-mail]>
Keywords: architecture, GCC
Sender: [e-mail]
Reply-To: Michael John Haertel <[e-mail]>
Organization: Compilers Central
References: <[e-mail]>
Date: Fri, 29 Jan 1993 04:41:12 GMT
Approved: [e-mail]

Pardo wrote:
>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.

I've used 2c.  My experience is that gcc produces better code, contrary to
Thompson's claim.  He most likely forgot to turn on -O with gcc.  Without
-O, gcc produces really pessimal code, considerably slower than pcc
without -O for example.

The gcc source code (currently ~200,000 lines for the machine independent
part only, not counting the C++ and ObjC front ends) is more than 10 times
the size of the 2c source code.  I would not say that gcc produces 10
times better code.  Perhaps 10% better.  This may be another case of 90%
of the benefit for 10% of the work.  In addition, 2c compiles much faster.
Thompson's claim that 2c typically compiles in 50% of the time gcc takes
is probably an understatement, in fact.  2c is the most nearly I/O-bound
compiler I've ever used.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:11:17 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Barton Christopher Massey)
Subject: Re: justify use of flex vs lex
Message-ID: <[e-mail]>
Keywords: lex
Sender: [e-mail]
Reply-To: [e-mail] (Barton Christopher Massey)
Organization: University of Oregon Computer and Information Sciences Dept.
References: <[e-mail]>
Date: Fri, 29 Jan 1993 07:39:23 GMT
Approved: [e-mail]

[e-mail] (Steve Layten x3451) writes:
[Why flex not lex?]
>    Support across multiple platforms/environments
>    Fewer constraints or "limits" built in.
>    I believe that support for flex is "better" than most vendors

And, if it matters, don't forget speed -- flex scanners may be
comparable to hand-coded ones in speed, whereas lex scanners aren't
even in the running...

                    Bart Massey
                    [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:13:35 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: thutt <[e-mail]>
Subject: EBNF Parser generator information (RRPG reply)
Message-ID: <[e-mail]>
Keywords: parse, tools
Sender: [e-mail]
Reply-To: thutt <[e-mail]>
Organization: Compilers Central
References: <[e-mail]>
Date: Fri, 29 Jan 1993 12:35:43 GMT
Approved: [e-mail]

> 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
> ...
> There are various notations for writing RRPGs (or slight restrictions
> thereof), many called "extended BNF".
> What parser-generators are available that accept some form of RRPG?

The LALR program from ProSoft (formerly LALR Research) is the fastest, and
best parser generator used.  It accepts EBNF as its input, and produces
fantastically fast parsers.  It automatically creates an AST for you, and
actually traverses it, calling your semantic action functions associated
with that type of tree node.

I don't have my docs handy, and its been quite a long time since I have
actually used it, but it accepts the entire EBNF syntax.  Really an
incredible parser generator.

It comes free with a YACC->LALR translator, and a program that will allow
you to visually see how your productions are working.  (It's an
interactive program that shows you each production in a menu, you
selection a production, and it pops up a new window with all the new
productions that are available.  Really neat.  Good for understanding how
these type of parsers actually operate.)

And, its a hell of a lot easier to use than YACC!  On the downside, the
documentation is rather skimpy (don't know about today.  I bought mine in
1989), BUT all the information you need _is_ in the documentation.  You
just have to read it, over and over.  Read the code, experiment.  It will
not hit you over the head with blatant info, but you can figure things out
every single time!

I have no association with this company.  I'm just a convert to his
program.  Plus, he's a real nice guy to boot!

Taylor Hutt
[e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:14:37 EST 1993
Xref: iecc comp.compilers:4176 comp.lang.fortran:8917
Newsgroups: comp.compilers,comp.lang.fortran
Path: iecc!compilers-sender
From: [e-mail] ("Steve" Stevenson)
Subject: Re: Wanted: folk theorems in Fortran Programming.
Message-ID: <[e-mail]>
Keywords: Fortran, optimize
Sender: [e-mail]
Reply-To: [e-mail] ("Steve" Stevenson)
Organization: Clemson University
References: <[e-mail]> <[e-mail]>
Date: Fri, 29 Jan 1993 14:30:29 GMT
Approved: [e-mail]

[e-mail] (David Moore) writes:
>[re folk Fortran wisdom]
>The point is that any decent optimizing compiler is going to recognize all
>of these "bad" forms and convert them into something better.

The point is that the left and right hand columns are from a current
teaching module from NCSA. Compilers and compiler people do not
necessarily get through to the people who are actually coding. The reason
to look for this stuff is to find out what people are being told.
--
Steve (really "D. E.") Stevenson           [e-mail]
Department of Computer Science,            [phone].mabell
Clemson University, Clemson, SC 29634-1906
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:17:54 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail]
Subject: Re: Recursive descent is better than LL(1)
Message-ID: <[e-mail]>
Keywords: LL(1), parse
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Compilers Central
References: <[e-mail]> <[e-mail]>
Date: Fri, 29 Jan 1993 16:20:11 GMT
Approved: [e-mail]

Barton Christopher Massey <[e-mail]> writes:
>I would like to prove or disprove the following conjectures:
> LL(1) Transformability: There exists an algorithm which, given any grammar G
> which is unambiguous and describes an LL(1) language L(G), produces an LL(1)
> grammar G' for the language L(G).
> LL(1) Decidability: There exists an algorithm which, given any grammar G
> which is unambiguous and describes a language L(G), decides whether L(G) is
> an LL(1) language.
>it seems most likely to me that LL1T is true, but I'm skeptical about LL1D.

Bill Purvis <[e-mail]> writes:
>... SID... accepts a fairly arbitrary BNF description... produce an LL(1)
>grammar (assuming that the language is LL(1). - the first conjecture.
>...I suspect that in practical terms it probably covers the second conjecture.
[e-mail] writes:
>I present a simple contra-example:
>    S -> A | B
>    A -> `x' A `y' | `a'
>    B -> `x' B `z' | `b'
>...`SID may also report failure because
>its attempt to transform the grammar causes it to loop.'

Pete Jinks <[e-mail]> writes:
> Jan's example causes SID problems, so SID may establish LL1T but can't
> establish LL1D. I believe this is because his example is not LL(1), but
> no-one has said so explicitly so far and I can't find the example in the
> Dragon book - is it a well-known example?

I'm teaching compiler construction on the school mentioned below.  I have
been doing some spare time tinkering on the problem of transforming a
grammar to LL(1) form along the lines advocated by the `dragon book'.
That means it's done the same way as Foster's SID.  There are some
differences though. My program accepts a `simple syntax directed
translation scheme' in the form of a `regular right part grammar'. The
translation scheme is expected to specify translation to postfixcode that
could easily be converted to an abstract syntax tree if you like.  The
reason for this approach is that the transformation process messes up any
carefully designed grammar. The resultant abstract syntax trees however
remain invariant in the transformation process. So you can neglect the
messed up grammar. Any further translation can be defined in terms of an
attribute grammar for the resultant postfix code or equivalently the
abstract syntax trees.

I tested it mainly with two grammars: one derived from the Pascal-grammar
in `Jensen & Wirth - Pascal: User Manual and Report', the other derived
from James Roskind's YACC-grammar for C. On Pascal my program did a
marvelous job. On the Roskind-C grammar it runs into an infinite loop. (I
wasn't aware of the problem at the time.) So figuring out wat went wrong I
designed some small examples running into the same problem.

The problem is of course the restricted set of transformations used. After
elimination of direct and indirect recursion only two transformations
remain:
- substitution of leading nonterminals in rules with conflicting FIRST-sets.
- factorization of common prefixes of rules.

Even simpler grammars might get SID and my program into a loop when we
restrict ourselves to these transformations:

Example:
S -> A | B
A -> `x' A | `a'
B -> `x' B | `b'

Substituting A and B in the S rules and factorizing gives:

S -> `x' S1 | `a' | `b'
S1 -> A | B
A -> `x' A | `a'
B -> `x' B | `b'

So you run into the same loop.

Noting the rules of S1 match the original rules for S you might substitute
the name S for S1 to get:

S -> `x' S | `a' | `b'

That's a different transformation however! At least Foster doesn't mention
it, nor does the dragon book.

This transformation can be used sometimes. It works also on the next example:

S -> A | B
A -> `x' A `y' | `a'
B -> `x' B `y' | `b'

It doesn't work however on the contra-example from my previous posting:

S -> A | B
A -> `x' A `y' | `a'
B -> `x' B `z' | `b'

I chose this example in my previous posting while the other examples
couldn't disproof any of the conjectures. However it's no LL(1) language.

In fact the conjectures have not been disproved at all. Only if we
restrict our transformations to the set mentioned by Foster. I don't
expect the suggested transformation above solves the looping problem in
the general case for LL(1) languages, but I don't have any contra example.

The wider approach to recusive descent parsing as exposed in my previous
posting handles all the examples above. So why bother to much with strict
LL(1) languages. It's simple: anything that can be done with a table
driven LL(1) parser can also be done with a recursive descent parser.  But
the converse is not true. Recursive descent can do much more than just
handling LL(1) languages.

Let's wind up this discussion:

Returning to Massey's second conjecture:

> LL(1) Decidability: There exists an algorithm which, given any grammar G
> which is unambiguous and describes a language L(G), decides whether L(G) is
> an LL(1) language.

LL(1) languages are only very weakly defined as languages for which an
LL(1) grammar exists. There's no description of an LL(1) language without
reference to an LL(1) grammar. `Dragon book' states, it after showing how
the table of a table driven parser is constructed, as `A grammar whose
parsing table has no multiply-defied entries is said to be LL(1).'.

So if you are lucky your search for an LL(1) grammar may succeed.

But how about proving a language defined by an arbitrary grammar is not
LL(1). Do we have to search an infinite universe of equivalent grammars?
After all we don't have any better characterization of being NOT LL(1)
than `there's no grammar for this language in our infinite universe of
equivalent grammars . . . etc.'  This tends to an infinite loop. We need a
better characterization of being LL(1).

Popping our discussion stack again. What do we prefer? Education with
top-down or bottom-up techniques?

I present a bit of recursive descent parsing in a very early stage as part
of a course in datastructures and algorithms. This follows the course on
ordinairy Pascal and starts with pointers and recursion.  I use
elementairy recursive descent technique based on syntax-diagrams as a
means to point out that recursion is'nt meant for stupid examples like
factorial functions, but instead a very powerfull programming technique.
As an exercise students have to read propositional expressions with
operators and or not <=> => parantheses and a few variables, have to
convert the expressions to abstract syntaxtrees, interprete the trees and
print a corresponding truth-table. Just to let them taste it.

In a later stage my collegues give seperate courses on the theory of
grammars, languages regular expressions etc. and on the usage of LEX and
YACC. Next a short course on theory of compiler construction containing
LL(1) and SLR(1) table construction, among other things.  We end with a
practical assigment on building a translator with LEX and YACC for a
simplified version of Pascal (just integers and booleans, no type
constructions).

Concerning the choice between top-down and bottom-up my advice is: Take a
look at the language first. What did the inventors of the language have in
mind? Don't tell me they had no idea while defining the language.

Jan Schramp

--
Jan Schramp, Haagse Hogeschool - Sector Informatica. Louis Couperusplein 19,
2514 HP  Den Haag, Netherlands. E-mail: [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:19:56 EST 1993
Xref: iecc comp.compilers:4178 comp.lang.fortran:8918
Newsgroups: comp.compilers,comp.lang.fortran
Path: iecc!compilers-sender
From: [e-mail] (Mitchell Wand)
Subject: Re: Wanted: folk theorems in Fortran Programming.
Message-ID: <[e-mail]>
Keywords: Fortran, arithmetic
Sender: [e-mail]
Reply-To: [e-mail] (Mitchell Wand)
Organization: College of Computer Science, Northeastern University
References: <[e-mail]> <[e-mail]>
Date: Fri, 29 Jan 1993 17:01:58 GMT
Approved: [e-mail]

> [e-mail] ("Steve" Stevenson) writes:
>I am trying to make a catalog of folk wisdom in fortran programming.

You might also want to look at

David Goldberg,
"What Every Computer Scientist Should Know about Floating-Point Arithmetic"
Computing Surveys, March 1991, 5--49.

It's not Fortran-specific, but Steve's examples suggested a particular
interest in numerical coding.

--Mitch

--
Mitchell Wand
College of Computer Science, Northeastern University
360 Huntington Avenue #161CN, Boston, MA 02115     Phone: [phone]
Internet: [e-mail]                Fax:   [phone]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:21:17 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Terence J Parr)
Subject: Re: parser-generators for RRPGs
Message-ID: <[e-mail]>
Keywords: parse, tools
Sender: [e-mail]
Reply-To: [e-mail] (Terence J Parr)
Organization: Compilers Central
References: <[e-mail]>
Date: Fri, 29 Jan 1993 17:55:40 GMT
Approved: [e-mail]

Michael Dyck <[e-mail]> writes:

> 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?

ANTLR, the parser generator in PCCTS (Purdue Compiler Construction Tool
Set), supports the following EBNF constructs:

Make a subrule:
     ( alternative 1 | alternative 2 | ... | alternative n )

Make an optional subrule:
     { alternative 1 | alternative 2 | ... | alternative n }

Make a zero-or-more looping subrule:
     ( alternative 1 | alternative 2 | ... | alternative n )*

Make a one-or-more looping subrule:
     ( alternative 1 | alternative 2 | ... | alternative n )+

Subrules are treated like ordinary grammar symbols and hence can be nested
arbitrarily.

In a related subject, the next release, 1.07, will allow arbitrary regular
expressions of tokens to be used to predict many productions which require
arbitrary lookahead.  e.g.  (...)+ loops as prefixes tend to cause
problems:

a : (A)* X
  | (A|B)* Y
  ;

This is a major problem for LL-based parsers (assuming one cannot left
factor).  However, using the semantic predicate mechanism also supported
by PCCTS, one can do the following:

a : << predict(A* X) >>?        (A)* X
  | << predict([AB]* Y) >>?     (A|B)* Y
  ;

PCCTS constructs a DFA for each parsing decision which has these predict
"functions".  Then, at runtime, the DFA spins until it matches (or doesn't
match) one of the predicting regular expressions.  Upon a successful
match, it knows which production to predict.  NOTE that it is a predicting
regular expression of TOKENS not characters.  There's lots of theory and
stuff behind the power and usefulness of this technique which I'll leave
out.  This feature works in my 1.07 alpha version (in house).

> [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]

Actually, for recursive-descent parser generators like ANTLR, the (...)*
looping constructs etc... are best left in that form rather than
converting to BNF (although this is easy to do and I built one with
PCCTS).  For example,

a : WORD ( COMMA WORD )*
  ;

would be mapped to something like:

a()
{
    MATCH(WORD);
    while ( LA(1)==COMMA ) {
        MATCH(COMMA);
        MATCH(WORD);
    }
}

where LA(1) is the next token of lookahead.  This is much more efficient
than performing tail (LL) or left recursion (LR).

Terence
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:22:06 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Ramki Thurimella)
Subject: Automatic Transformation of CFG to LL/LR
Message-ID: <[e-mail]>
Keywords: LL(1), parse
Sender: [e-mail]
Reply-To: [e-mail] (Ramki Thurimella)
Organization: Compilers Central
References: <[e-mail]> <[e-mail]>
Date: Fri, 29 Jan 1993 18:13:15 GMT
Approved: [e-mail]


I remember seeing recently a posting on this newsgroup requesting
pointers to the following question: given an arbitrary context-free
grammar, does there exist a program/tool that would automatically
convert it to LL(1) or LR(1) grammar.

While testing to see if a given CFG is LL(1) or LR(1) simple and
decidable, converting one is undecidable. Exercises 5.1.12 and 5.2.12 of

     Aho, A.V. and Ullman, J.D., "The Theory of Parsing, Translation,
     and Compiling," Vol. 1: Parsing, Prentice-Hall, Englewood Cliffs,
     N.J., 1972.

raise the same issues as that of the previous posting.

Ramki Thurimella
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:24:19 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (David Petrie Stoutamire)
Subject: GCC as back-end summary
Message-ID: <[e-mail]>
Keywords: GCC
Sender: [e-mail]
Reply-To: [e-mail] (David Petrie Stoutamire)
Organization: International Computer Science Institute, Berkeley, CA, U.S.A.
Date: Fri, 29 Jan 1993 19:41:05 GMT
Approved: [e-mail]

This is a summary of responses to my query about using gcc as a
back-end for our new Sather compiler.  Eight other people responded
asking to be forwarded any info, so I'm posting this.  These messages
are trimmed a bit.

    - Dave

    We are about to write the compiler for the next release of Sather.  Our
    previous compiler (written for the most part in Sather) used Yacc and Lex,
    did some Sather processing, and output in C as a sort of portable
    assembly.

    Most of the compiling time is currently spent compiling the resultant C
    code.  Naturally, we are thinking about using RTL as an intermediate form
    to hand to gcc.  This would result in a much faster compiler that would be
    nearly as portable, although we would still have to be able to generate C
    in order to let people bootstrap Sather.

    RTL (from the gcc manual) isn't too bad, but removing the C-specific part
    of gcc and linking in our code looks like it would require a lot of
    knowledge of gcc.  The new versions of the compiler look much cleaner than
    before, but we would rather be spending time on language issues than
    mucking with the code.

    I would love to hear from anyone who has used gcc as a back-end, or
    pointers to other attempts to do so.  Ideal would be a stripped down
    version which read RTL instead of C files.  I imagine such a thing would
    be very useful to others as well.

    I will appreciate any help... thanks!
-----------------------------------------------------------------
>From comp.compilers moderator:
[The GNU Fortran project must have faced a similar problem.  It's headed up
by Craig Burley <[e-mail]>. -John]
-----------------------------------------------------------------
>From [e-mail] Wed Jan 20 13:15:35 1993

Our group at Hamburg University, Germany, also uses C as a "portable"
target assembly language for the compilation of a higher-order persistent
language.  Based on our previous experience in generating code for the
commercial Sun optimizing compiler back end shared by their C, C++,
Modula-2, Pascal and Fortran compiler, we decided to stay away from
intermediate representations a la RTL.

Nevertheless, I would be very interested to learn more about the
experience of other groups in this field. Perhaps there has been some
progress to truely decouple the frontends from the bits and bytes of the
IR. I would therefore appreciate if you could forward (a summary of) the
information you receive.
-----------------------------------------------------------------
>From [e-mail] Wed Jan 20 13:27:23 1993

I tried exactly what you're describing back in '89, when I was taking a
compilers class. I spent spring break (all of it) trying to separate the
RTL back end, and ended up failing - the linking dependencies killed it. I
then did my own RTL'ish intermediate language and the back-end to 68000
code, but it kept me from having the time to add more functionality to the
front end.

I think having the RTL translator available separately would be great, and
am surprised no-one has done it yet. Best of luck :-).
-----------------------------------------------------------------
>From [e-mail] Thu Jan 21 07:06:41 1993

I think is is exactly what the GNU ADA (GNAT) project is doing.  Check
with Ed Schonberg ([e-mail]) for more information.
-----------------------------------------------------------------
>From [e-mail] Thu Jan 21 10:53:48 1993

We are investigating the same thing for the (locally developed)
applicative programming language OPAL, the main aspect of whose back - or
rather middle - end is compile time optimization of garbage collection.

The current solution is, as you did, to generate C source code to be
further handled by the Gnu C Compiler. And of course, to skip the step of
flattening an abstract tree to text form and then having it parsed again
should be a significant speedup.

A group of of three students, including me, was assigned the task of
finding, analyzing and reporting possible interfacing methods.

This is what we found out so far:

At the initial moment of their generation during the parsing process (i.e.
before further optimizations take place), RTL expressions are restricted
to machine specific formulations of the intended semantic action. For
example, the code generated for the SPARC architecture for loading an
immediate value of sufficient size (= not fitting in a single opcode) into
a (at that time, virtual) register will consist of code for loading the
more significant bits and then adding the rest, because this is the way
the SPARC will do it.

So, generating your own RTL expressions would mean to implement all those
machine specific decisions, unless you make use of gcc's RTL generating
functions. These get adapted to the machine dependent needs at the time of
compiling gcc itself. Most of them, unfortunately, do expect appropriate
variants of gcc's tree data structure to be guided in what functionality
to generate.  Gcc constructs partial syntax trees per top level definition
(e.g. function) from the sourcecode, then generates RTL code from it and
discards the tree.  It seems there is no routine included for reading in
either RTL or trees.

Luckily, as far as we can tell gcc accesses the tree objects only via some
#define macros from tree.h . Therefore, it should be possible to construct
a new tree.h which makes gcc believe that our own abstract "imperative
code" tree is just what it expects. Of course, this would also require to
appropriately link the executables together, including control flow.
Also, the implications of gcc's destructive access to otherwise
functionally clean data structures must be considered. If we have to copy
them to avoid problems, we could even adapt them to the expected form.

The effort to implement this scheme should not be underestimated.

There are quite many possibilities to draw the border line. A clean and
easy solution would be to define a functional datatype which resembles the
tree structure logically (maybe leaving out relative obscurities like the
++ operation etc.), and write a new .y grammar description file for gcc
which parses a simple prefix notation of the tree, which can be easily
output from the functional parser back end. The parsing function could
(later on?) be hand coded to avoid large tables.

One could even try to translate the RTL generating functions from C to the
functional language of your choice - either manually, or better yet
automatically.

Any way, a thorough investigation of struct tree, or rather its macro
interface and an exact documentation of what we found should be the next
thing to do.

It is not sure whether our project will be continued to reach any
implemenation, for the prospectable amount of work which is required
exceeds the limitations of the course this project is part of.
-----------------------------------------------------------------
>From [e-mail] Fri Jan 22 01:54:28 1993

try to contact J"orn von Holten aka <[e-mail]>.
They are implementing a strict functional language named aspect, have been
generating C code and are switching to using RTL, as I'm told.
-----------------------------------------------------------------
>From [e-mail] Fri Jan 22 07:43:57 1993

You can try to GNU Ada people at NYU. One contact is Professor Ed
Schonberg ([e-mail] (note spelling of user id!)). They have an
Ada front end that output RTL to the gcc back end. I lead the GNU Modula-3
project, which wrote a new front-end, but it's more "in bed" with gcc's
way of doing things.
-----------------------------------------------------------------
    This is a message sent to our internal Sather group which is related,
    so I'm including it in the summary (we have garbage collection in
    Sather).

>From CRAFTY.FOX.CS.CMU.EDU!moss Fri Jan 22 20:38:22 1993

Thanks for your inquiry concerning our gc enhancements. I don't have a lot
of time at the moment, but I should be able to give you the general
picture.

One of my students, Amer Diwan, enhanced the gcc back-end to keep track of
pointers, address arithmetic optimizations, etc., and to output tables to
support gc. The idea is that for selected execution points where gc can
occur (e.g., at calls, allocations, etc., but, to keep table size down,
etc., NOT at every instruction) the table allows one to determine which
registers have live pointers to objects, and which stack locations in the
current frame. By using the return pc values into previous frames, we can
probe the table for other frames, and reconstruct the contents of
registers, and thus "decode" the entire stack.

Additionally, one may have what we call "derived values", which are based
on either pointers to (the starts of) objects or other derived values. To
perform a gc, one "subtracts off" the values from which a derived value is
derived, does the gc (possibly moving objects), and then "adds back" the
values back into the derived value, thus adjusting it. This works for
derived values that are the sum or difference of one or more pointers,
plus any additional offset (the offset need not be a constant). The
derived value stuff handles strength reduction topimizations (which
produce pointers that step through arrays), and a variety of other
optimizations that result in derived values that do NOT point anywhere
into the object(s) to which they are connected. We also guarantee the base
pointers are still live and available for this computation at the gc
points, etc. Finally, the scheme does significant compression on the
tables. This is all reported in our paper presented at SIGPLAN '92, which
you can obtain via anonymous ftp from ibis.cs.umass.edu (look in
~pub/papers for interesting stuff).

There are two other things needed to support gc. One is a way of informing
the collector of stores of pointers. This is needed because the collector
is generational, and need to know about new pointers from old generations
into younger ones. The compiler has support for a number of schemes for
doing that, selectable by command line options.  Finally, one needs the
actual colelctor and the stack decoding run time. Both of these have been
built. The collector we use is the UMass Language Independent GC Toolkit.
There is a technical report describing an earlier version of this
collector in the aforementioned pub/papers directory. We can make the
toolkit available for research use only; commercial use may require
licensing. The directly gcc related stuff will be offered back to the FSF,
though we have not handed it out yet, since GNU M3 is not even into the
alpha release stage (though that is only a matter of weeks now).
-----------------------------------------------------------------
>From [e-mail] Fri Jan 22 16:14:33 1993

I think it might be worth measuring how much time is actually spent in
these routines. Optimizing takes up a lot of time and the gcc front end is
designed to be pretty fast (at the expense of being 1 pass). You might end
up with less speedup that you anticipate.

> RTL (from the gcc manual) isn't too bad, but removing the C-specific part
> of gcc and linking in our code looks like it would require a lot of
> knowledge of gcc.  The new versions of the compiler look much cleaner than
> before, but we would rather be spending time on language issues than
> mucking with the code.

The dream of us all, but the reality of getting a Modula-3 compiler that
produces quality code has forced us to redo the frontend of gcc and add to
the backend.  We changed the front end to build a parse tree using an
enhanced version of the tree.h nodes. From there we type checked and
generated rtl that included the type information we needed and off we
went. Going to our internal parse tree nodes might be a another approach
since it buys into some of our backend type work with greater ease.  The
down side of our approach is that we ended up hacking in C instead of
Modula-3 (or Sather).  To understand some of the work we did see

@InProceedings{DMH91,
  author =      "Amer Diwan and J. Eliot B. Moss and Richard L. Hudson",
  title =      "Compiler Support for Garbage Collection in a Statically
  Typed Language",
  pages =      "273--282",
  booktitle = "Conference on Programming Language Design and Implementation",
  year =      1992,
  organization = "SIGPLAN",
  publisher = "ACM Press",
  address =      "San Francisco, California",
  month =      "June"
}

If Sather needs a GC you should at least look at this paper. As for timing
we are still several months away from having gm3 ported to a MIPS or Alpha
machine so you might just keep us in mind and talk to us this summer to
see where we are. Good luck. Eliot ([e-mail]) is also working on
this project.
-----------------------------------------------------------------
>From [e-mail] Thu Jan 28 14:09:09 1993

We are working on a Modula-3 compiler that uses gcc as its back-end.  Not
everything is working but we have made good progress so far, and here is a
summary.

First, you probably don't want to generate RTL directly.  If you look at
tree.def, you will see that there is another representation of the code,
let's call it the tree representation.  The parsers generate tree
representations that are essentially machine and language-independant.
The code that transforms this tree representation to RTL knows a lot about
the machine for which you are compiling; for example it knows the calling
conventions, such are r4 to r7 contains the first 4 words of integer type
actual arguments on mips.

Unfortunately, the tree representation is very poorly documented; in
particular, the collection of functions you need to call is not very
clear.  Some of the node types are not implemented, and some of them are
still language dependant (for example, integer addition does not check for
overflow).

Since gcc was not the obvious choice of back-end for us, we have written
our own back-end interface.  Our hope was to be able to implement that
interface in various ways to satisfy our needs.  One of the goals was that
it should be possible to implement a naive code generator easily; this
means that the interface is very low level; for example, frame pointers
for nested procedures are manipulated explicitly.

The implementation of our interface consists mostly into making the calls
that the C parser would make if presented with a C program that does the
same as the Modula-3 program we are compiling.  We save cpp, the parsing,
a fair amount of checking.

So far, we have made only one small modification in the code that
generates the RTL (which we don't consider to be ours) to support nested
procedures.  We expect more extensive modifications to handle correctly
exceptions.

I have included our interface below (it's actually in two interfaces, plus
one machine specific interface).  It will probably be modified somewhat
before we have a running compiler, and it probably needs a lot of
documentation.  [text not included in this summary - Dave]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:25:36 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Bala Ramakrishnan)
Subject: Global Data flow analysis
Message-ID: <[e-mail]>
Keywords: analysis, comment
Sender: [e-mail]
Reply-To: [e-mail] (Bala Ramakrishnan)
Organization: U S WEST Advanced Technologies
Date: Fri, 29 Jan 1993 22:44:59 GMT
Approved: [e-mail]

While local (function level) data flow analysis is fairly well defined,
does anyone have any info on techniques/problems associated with global
data flow. Can you suggest any papers/books on this subject?

Thanks for the info.
--
Bala Ramakrishnan  E-mail: [e-mail]  Phone: [phone]
USWEST Advanced Tech., 4001 Discovery Dr., Boulder, CO - 80303
[Other than the practical issues involved with separate compilation or
the lack thereof, are there any issues peculiar to global dataflow? -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:26:42 EST 1993
Xref: iecc comp.sys.super:1911 comp.arch:25794 comp.compilers:4183
Newsgroups: comp.sys.super,comp.arch,comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Shubhendu S. Mukherjee)
Subject: Re: How many vector registers are useful?
Message-ID: <[e-mail]>
Keywords: vector
Sender: [e-mail]
Reply-To: [e-mail] (Shubhendu S. Mukherjee)
Organization: Univ. of Wisconsin @ Madison, CS Dept.
References: <[e-mail]> <[e-mail]>
Date: Sat, 30 Jan 1993 00:22:10 GMT
Approved: [e-mail]


[e-mail] (J. Giles) writes:
>Vectors and scalars are not really all that different.  Unless you have
>overlap between the vectors they really behave just like large scalars.

[e-mail] (Robert Hyatt) writes:
> Same holds true for vectors.  You don't necessarily have to have high
> reuse to win, just enough registers to keep data flowing (a) from memory
> (b) to memory and (c) between functional units....

This is the THE bottom line.  So you are actually talking about high-speed
load and store buffers and intermediate registers for chaining as in Cray.

However, codes like blocked matrix multiplication could potentially make
effective use of vector registers.

-Shubu
--
Shubhendu Sekhar Mukherjee      University of Wisconsin @ Madison, C.Sc.
Net:shubu@cs.{wisc,utexas}.edu   [W]:[phone]    [H]:[phone]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:27:57 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: moliere![e-mail] (Peter Michael Klausler)
Subject: Vector registers
Message-ID: <[e-mail]>
Keywords: vector, architecture
Sender: [e-mail]
Reply-To: moliere![e-mail] (Peter Michael Klausler)
Organization: Compilers Central
References: <[e-mail]> <[e-mail]>
Date: Sat, 30 Jan 1993 04:41:55 GMT
Approved: [e-mail]

Although lots of folks know about this, in the interest of completeness in
the discussion about the best number of vector registers I'd like to point
out the capability of "tailgating" found on a couple of machines I've had
the pleasure of working with.

Tailgating permits results to flow into a vector register while data are
concurrently flowing out. E.g.,

    V0 <- V1+V2
    V1 <- V3*V4    ! no need to wait for V1

can run in parallel, subject to initial availability of V1-4. This
capability increases the number of registers available to a scheduler, for
the operand registers coming into their last (or only) uses in a chime can
also serve as result registers in that same chime.

In kernels with no reused vector registers, then, tailgating means that
you can get by with about as many vector registers as you have functional
units. This capability is useful for machines without more flexible (but
expensive) chaining mechanisms, for it permits construction of a very
efficient polycyclic schedule for the kernel.

(In the absence of tailgating, aggressive schedulers can run out of result
registers and must delay instructions to later chimes.  Polycyclic
scheduling techniques that construct a regular pattern of operations, such
as modulo reservation table SW pipelining, can run into trouble. An
irregular polycyclic method seems to fare a little better under register
pressure in my experience.)
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:28:47 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: nzkite![e-mail] (Foster Schucker)
Subject: Compilers for Microchip PIC16C5x
Message-ID: <[e-mail]>
Keywords: question
Sender: [e-mail]
Reply-To: nzkite![e-mail] (Foster Schucker)
Organization: Kiteflyers Roost
Date: Fri, 29 Jan 1993 22:40:22 GMT
Approved: [e-mail]

I'm looking for a compiler for the PIC 16C5x series of microprocessors.

I'd prefer C or Pascal, hosted on MS-DOS but beggars can't be choosers.

The Microchip PIC 16C5x series of microprocessors is a small (18-28 pin)
chip with 33 instructions, a 12 bit word, with 2K of EPROM.  They are
ideal for small jobs.  At 5 volts / 2 ma battery projects are possible.
With clock speeds up to 20Mhz you can do calculation intensive systems.

The instructions are all single word, all operations with the exception of
brances occur in one cycle.  Branches take two cycles.  There are 15-72
registers(depending on the specific model) for programming use.

I know that most people will (should?) be using assember, I'd rather
program them in a HLL.

Thanks!!
Foster Schucker -- [e-mail] -- [phone] (voice)
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:29:36 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: idacrd![e-mail] (David desJardins)
Subject: Re: Re How many vector registers are useful?
Message-ID: <[e-mail]>
Keywords: vector, architecture
Sender: [e-mail]
Reply-To: idacrd![e-mail] (David desJardins)
Organization: IDA Center for Communications Research, Princeton
References: <[e-mail]> <[e-mail]>
Date: Sun, 31 Jan 1993 05:15:43 GMT
Approved: [e-mail]

Bill Mangione-Smith <[e-mail]> writes:
> Santosh Abraham, Ed Davidson, and I had a paper two asplos's ago that
> looked at the minimal number of vector registers required for specific
> codes.  [.... W]e decided to focus on the minimal number of registers
> required to achieve optimal performance.

I haven't looked at your paper, but I think that you have to be very
careful in using the word "optimal" here.  I have written a fair number of
assembly-language routines for vector machines, and it is very often the
case that the number of vector registers needed for "nearly optimal" code
is substantially less than that needed for "perfectly optimal" code.

In my experience, what often happens is that you can get a code which is
"nearly optimal" in the sense of taking the correct number of chimes to
execute the loop, but a few more ticks than is strictly necessary, because
the usage of the vector registers is not perfectly synchronized.  A vector
functional unit might have to wait for its input for a few ticks, for
example, because the latency of the unit feeding it is greater than its
own latency.  These few ticks might only add a few percent to the
execution time of the loop, but it might take as much as double the number
of vector registers to eliminate them.

Perhaps you were looking at some sort of "ideal" vector machine?  Assuming
things like constant latencies in the functional units would certainly
simplify a truly optimal analysis while probably producing nearly
equivalent results for practical purposes.

                                        David desJardins
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:39:39 EST 1993
Xref: iecc comp.compilers:4187 misc.jobs.offered:23090
Newsgroups: comp.compilers,misc.jobs.offered
Path: iecc!compilers-sender
From: [e-mail]
Subject: Compiler positions available for week ending January 31
Message-ID: <[e-mail]>
Keywords: jobs
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Compilers Central
Date: Sun, 31 Jan 1993 13:00:02 GMT
Approved: [e-mail]

This is a digest of ``help wanted'' and ``position available'' messages
received at comp.compilers during the preceding week.  Messages must
advertise a position having something to do with compilers and must also
conform to the guidelines periodically posted in misc.jobs.offered.  To
respond to a job offer, send mail to the author of the message.  To submit
a message, mail it to [e-mail].


-------------------------------

Reply-To: [e-mail] (Keith Bierman)
Subject: compiler positions open
Date: 27 Jan 93 14:20:17

SunPro, the division of Sun Microsystems Inc. which develops and markets
compilers and programming environments, has several openings in a project
to build a compiler for a new advanced RISC architecture.  This compiler
will extend the state-of-the-art in the areas of profile feedback, scalar
optimization and global instruction scheduling.  Other areas of interest
include cache optimization and interprocedural analysis.  If you are
interested in contributing to such a project please contact:

    [e-mail]
    voice: 415 336 5846
    fax  : [phone]
    snail: 2550 Garcia Ave
               UMTV:12-40
           Mountain View, CA 94043-1100
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  1 18:40:13 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Nigel Pearson)
Subject: Re: [TDR] Token-Based Compilers
Message-ID: <[e-mail]>
Keywords: C, interpreter
Sender: [e-mail]
Reply-To: [e-mail] (Nigel Pearson)
Organization: School of Computer Science, UTS
References: <[e-mail]>
Date: Mon, 1 Feb 1993 01:41:50 GMT
Approved: [e-mail]

[e-mail] (Paul Robinson) asks:
>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.

    One system which uses this is ACK, the Amsterdam Compiler Kit.  It
has a set of Front Ends which generate EM instructions. EM is the machine
language of a ficticious Extended von-Neumann machine.  (no, I don't know
where they got the M from either!)

    The ACK system provides both interpreters and translators for the
EM code.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb  2 08:30:01 EST 1993
Xref: iecc comp.sys.super:1912 comp.arch:25806 comp.compilers:4189
Newsgroups: comp.sys.super,comp.arch,comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Volker Kurz)
Subject: Re: How many vector registers are useful?
Message-ID: <[e-mail]>
Followup-To: comp.sys.super
Keywords: architecture, performance
Sender: [e-mail]
Reply-To: [e-mail] (Volker Kurz)
Organization: University of Frankfurt/Main, Dept. of Mathematics
References: <[e-mail]>
Date: Mon, 1 Feb 1993 15:00:03 GMT
Approved: [e-mail]

[e-mail] einhard Kirchner) writes:
> [is a large vector] register file useful at all ?

Definitely yes.

> A register has an optimizing effect only when the value in it can be used
> several times, at least twice, ...
>
> But how is this on vector machines ? The register creates a speedup only
> when it can hold an entire vector, which can be used again later. This
> requires a register long enough to do so. That means vectors of e.g. a
> length of 5000 can not be held anyway, every machine must load, process,
> and store it in pieces, and only a lot of memory bandwidth helps.

Every vector command introduces a new startup period.  So if you have to
cut your original vector(s) into pieces that fit into a vector register,
it helps if you need fewer pieces.  That is the advantage of configuring a
few very long registers.

> When configured as a few long vectors the Fujitsu vector registers may
> help, but then comes the second question: Are there any statistics on the
> reusing of vectors? I know about such things for scalar registers, where
> people found that 32 is plenty enough, and only 8 help a lot. But in these
> cases registers are used for loop indexes, addresses etc., which can not
> be compared to the use of vector registers.
>
> So: what can be gained with such a big vector register file ? Or is it
> only of limited help ? Can the register file be traded against bandwith to
> load and store from memory ?

Yes it can, and this may be the main reason why Fujitsu gave us such a
large register file.

If you configure more but shorter registers, than you have enough space to
keep intermediate results.  This may be the most important advantage of a
large register file: to avoid memory traffic at all.

By keeping intermediate results in vector registers, you do increase
computational intensity which is defined as

    number of arithmetic operations
    -------------------------------
    number of (main-)memory references

This has to be seen together with the number of data paths (max number of
memory references per pipe per cicle), which is 3 for a Cray Y-MP, 2 for a
VP1xxx (as you have in Kaiserslautern) and, alas, only 1 for a VP2xxx.  As
a rule of thumb, a good estimate for an upper bound of the speed of an
arithmetic operation is

    min{computational intensity * data paths, 1} * peak performance

A simple vector add has a computational intensity of 1/3, so it requires 3
data paths for full speed.  This is the case on a Y-MP (at least
theoretically, you cannot get the full speed because of memory conflicts
with other processors).  On a VP2xxx however you get only roughly 1/3 of
peak performance.  On the latter machine, increasing computational
intensity has a dramatic impact on the sustained speed.  In many cases
(among these is matrix multiplication) you can increas computational
intensity by unrolling outer loops.  This is where a large number of
vector registers is very useful.

You can exploit this on your own machine fairly easily by using the
routines from level 2 BLAS and level 3 BLAS.  To the best of my knowledge,
Kaiserslautern uses the routines that were optimized at the University of
Karlsruhe as part of the ODIN project.

Hope this helps,
Volker Kurz

--
Dr. Volker Kurz                ***     J. W. Goethe-Universitaet
[e-mail]     ***     Fachbereich Mathematik
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb  2 08:32:36 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Willem Jan Withagen)
Subject: Re: Code quality
Message-ID: <[e-mail]>
Keywords: optimize, performance
Sender: [e-mail]
Reply-To: [e-mail] (Willem Jan Withagen)
Organization: Eindhoven University of Technology, The Netherlands
References: <[e-mail]> <[e-mail]>
Date: Mon, 1 Feb 1993 10:04:24 GMT
Approved: [e-mail]

>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.

On the third hand: :-)

I've got this large set of modules which are based on a few tree
structures.  Now if I change something in those structures, I've got to
recompile >50k lines.  Once everything is stable, it doesn't need
recompilation that often. But to emphasize your remark.

 Compiling the largest module with -W0,-opt,0 (Apollo-ees for noptimisation)
 it takes about 15 secs to compile. (CPU time that is, Wall time > 1.30)
 Doing the same with -W0,-opt,3 it takes over 2.5 minutes :{
 (And all this takeing a mere 15 minutes of wallclock time :{{ )

And the fun part with this is:

There's a rather large switch inside, and the compiler manages to mess up
its table, and generate eronous code, or backend failures. Which get fixed
once in a while by using level 3 optimisation. (Hence I knew the time.)
Supposedly GCC has some of the same features, most compilers are not very
often exersized at the nopt. level and have relatively more bugs in that
part.

Once programs are finished and release upon the poor user, I'll start
optimising.  (And test before release). Only when a program has run
flawlessly for a long while I'll take out all the asserts to get your last
1%.

>The marketplace takes all kinds.

Which I fully underscribe, as you've guessed.

    Willem Jan Withagen

--
Digital Information Systems Group, Room EH 10.35
Eindhoven University of Technology
P.O. 513                             Tel: [phone],Fax: [phone]
5600 MB Eindhoven                    The Netherlands
Internet:  [e-mail]
X400:      C=nl;ADMD=400net;PRMD=surf;O=tue;OU=ele;OU=eb;S=WJW;
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb  2 08:34:21 EST 1993
Xref: iecc comp.misc:11434 comp.programming:3495 comp.compilers:4191
Newsgroups: comp.misc,comp.programming,comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Willem Jan Withagen)
Subject: Re: Architecture description languages for compilers?
Message-ID: <[e-mail]>
Keywords: architecture
Sender: [e-mail]
Reply-To: [e-mail] (Willem Jan Withagen)
Organization: Eindhoven University of Technology, The Netherlands
References: <[e-mail]>
Date: Mon, 1 Feb 1993 10:41:59 GMT
Approved: [e-mail]

[e-mail] (Todd R. Eigenschink) writes:
>I'm planning on doing some research in optimization and code generation
>next quarter.  One of the topics I'm interested in is machine
>descriptions--some vanilla way to describe the architecture of a machine
>for purposes of code generation.  (Numbers of registers, addressing modes,
>etc.)

Well as far as I know, is there still some work going on on this topic.
Not as much as a few years ago, when a system like ISPS was really hot
topic.  VHDL sort of flattened out some of the hardware description
desires, but not the type you describe.

But still things are happening, I know of a person/group on the Munich
University who's doing a Phd on this subject.  Unfortunatly is he not
allowed to show any results before the submission of the thesis. :(
Another group in Paderborn is looking into tools to describe optimisations
in a more system independant way.

It is also the field of interest in which I trying to get my Phd. And
we've come up with a sort of hierachical description system which should
eventually lead to automagical (read: semi-automatic, with the hard part
thru 'human interaction') created assemblers, compilers, simulators,
performance evaluators.

If you are interested, I can mail you a user-manual of one of the language
definitions we designed. (and implemented)

And the moderator adds:
>[There have been lots of architecture description languages over the years.
>Whether any of them can be used to mechanically generate a compiler is
>another question.  I suspect they'd be more useful for validation. -John]

Well not quite true, I think the commercial variant of ISPS (endot) did
something like this. I've not been able to get much more info about this,
other than it should work.  And one thing that should not be forgotten is,
that some of these languages were done before we had abundant computing
power. Some of the early systems were done in assembler. Now that we've
got more fuel to burn, some things can/should be re-investigated. Which is
what I'm currently doing.

    Regards,
        Willem Jan Withagen

Some bibtex reference I've got lingering around:
@article
    (BarbacciISPS
    ,author       = "Mario~R. Barbacci"
        ,title     = "Instruction set processor specifications (ISPS):
              The notation and its apliccations"
        ,journal   = "IEEE Transactions on computers"
    ,volume       = "C-30"
    ,number       = 1
        ,year      = 1981
        ,month     = "january"
    ,indexkeys = "Architecture evaluation, automatic programming,
             behavioural description, computer-aided design,
             computer description languages, instruction set processor
             "
      ,abstract  = "
       The instructions set processor specifications (ISPS) computer
       description language is an evolutionary step towards the
       formalistation of the digital design process at the higher or
       behavioral levels. It has been used as a design tool, which
       covers a wider area of application than any other hardware
       description language. Thus, besides simulation and synthesis of
       hardware, software generation, program verification, and
       architectureal evaluation and control are among the the current
       applications based on ISPS. The range of current and
       contemplated applicaiton areas are proff of the usefulness of
       the notation and its extension mechanisms. ISPS supports a wide
       range of applications and areas of research to coexist and
       share machine descriptions. The second part describes some of
       the current applications of ISPS."
    )
@article(Barb77
    ,author    = "M.R. Barbacci"
    ,title     = "Evaluation of the CFA test program via formal
        computer descriptions"
    ,journal   = "Computer"
    ,month       = oct
    ,year       = 1977
    ,pages       = {36-43}
    )

And one which I haven't seen (yet):
@manual(Endot
    ,title    = "N.2 Introduction and tutorial"
    ,organisation = "Endot Inc."
    ,address = "11001 cedar Ave., Cleveland,  Ohio 44106"
    ,year = 1987
    )

--
Digital Information Systems Group, Room EH 10.35
Eindhoven University of Technology
P.O. 513                             Tel: [phone],Fax: [phone]
5600 MB Eindhoven                    The Netherlands
Internet:  [e-mail]
X400:      C=nl;ADMD=400net;PRMD=surf;O=tue;OU=ele;OU=eb;S=WJW;
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb  2 08:36:36 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Steve Layten x3451)
Subject: justify use of flex vs. lex - summary
Message-ID: <[e-mail]>
Keywords: lex, summary
Sender: [e-mail]
Reply-To: [e-mail] (Steve Layten x3451)
Organization: Compilers Central
Date: Mon, 1 Feb 1993 21:17:30 GMT
Approved: [e-mail]

Original question:

    I need to use flex instead of lex for a job I have that exceeds
    capacities of some lex features.  I want to put this into a
    "production" job stream, and our current "standards" seem to
    discourage use of public-domain code in production, the standard
    managment argument being that we should use vendor-supported code
    so we don't have to spend time maintaing the code ourselves.  I
    must justify the use of this "non-supported" code in production.

    I would appreciate hearing comments from this community regarding
    arguments for or against the use of flex vs. the vendor-supplied lex.
    Some additional considerations which I think are important are:

    [reasons deleted ]

Several persons, including the moderator indicated that flex contained
fewer bugs or had better support than lex: ([e-mail] (Ken Yap),
    [e-mail], [e-mail] (Zalman Stern),
    [e-mail] (Randy Wright),
    [e-mail] (Anton Ertl)).

One or two specifically mentioned performance:
    ([e-mail] (Scott David Daniels),
    [e-mail] (Randy Wright)).

Others indicated that I should consider paying others for support.  Cygnus
Support (contact: [e-mail] (Don Rector), 415/903-1408) was mentioned
by three persons: ([e-mail] (Craig Burley),
    [e-mail] (Joe Buck), (also gave
        [e-mail] as e-mail address)
    [e-mail] (Joe Korty)).

Randy Wright ([e-mail]) also pointed out some additional
features of flex:

    >For example, I needed a re-entrant scanner to interpret ansi terminal
    >codes into curses calls. It took an afternoon to modify flex to run
    >in a re-entrant fashion.

    >Flex has the exclusive start conditions that lex (at least my
    >version) lacks. I have found the exclusive start condition feature
    >very useful in state machine tasks.

Finally one person (Basile STARYNKEVITCH <[e-mail]>)
suggested that I look at PCCTS:
    "It is a lexical+syntaxical analyser generator having more
    features than yacc+lex and their derivatives (flex, bison). PCCTS
    is public domain, (not GPL copylefted) so you can use it for
    commercial products without violating its notice, which explicitly
    permit use for commerical or proprietary software (both prohibited
    by bison&flex's copyright)."
He include a README file (fairly long, which I will not include), and
indicated that PCCTS files are available via anon ftp from
marvin.ecn.purdue.edu (128.46.179) in the subdirectory pub/pccts/1.06
(beginning December 1, 1992).

Thank-you all for your help,

Steve Layten
--
Steven W. Layten, Senior Engineer
Chemical Abstracts Service, PO Box 3012, Columbus, OH 43210    [phone]
INET: [e-mail]         BITNET: swl26@cas      UUCP: osu-cis!chemabs!swl26
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb  2 08:37:21 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Barton Christopher Massey)
Subject: Re: Automatic Transformation of CFG to LL/LR
Message-ID: <[e-mail]>
Keywords: parse, theory
Sender: [e-mail]
Reply-To: [e-mail] (Barton Christopher Massey)
Organization: University of Oregon Computer and Information Sciences Dept.
References: <[e-mail]> <[e-mail]>
Date: Tue, 2 Feb 1993 08:23:12 GMT
Approved: [e-mail]

[e-mail] (Ramki Thurimella) writes:
> While testing to see if a given CFG is LL(1) or LR(1) simple and
> decidable, converting one is undecidable. Exercises 5.1.12 and 5.2.12 of
>      Aho, A.V. and Ullman, J.D., "The Theory of Parsing, Translation,
>      and Compiling," Vol. 1: Parsing, Prentice-Hall, Englewood Cliffs,
>      N.J., 1972.
> raise the same issues as that of the previous posting.

I'll check the ref, but note that detecting, much less eliminating, CFG
ambiguity is undecidable, which is sufficient to show that converting an
arbitrary CFG to a necessarily unambiguous LL(1) or LR(1) grammar is
undecidable.  My conjectures thus were limited to unambiguous CFGs -- it
has been my experience that provably unambiguous grammars are easily
constructed for *most* interesting programming languages.

                    Bart Massey
                    [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb  2 08:38:28 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Thomas Reid)
Subject: Re: EBNF Parser generator information (RRPG reply)
Message-ID: <[e-mail]>
Keywords: parse, tools
Sender: [e-mail]
Reply-To: [e-mail] (Thomas Reid)
Organization: Institute of Systems Science, NUS, Singapore
References: <[e-mail]> <[e-mail]>
Date: Tue, 2 Feb 1993 08:53:47 GMT
Approved: [e-mail]

I have followed the LL1 vs LALR vs EBNF debate waiting for someone to
mention that you do not have to convert your grammars to LL1 to do
recursive descent.  You can construct a parser (automatically) directly
from EBNF.  The best reference I have for doing it is Barrett, Bates,
Gustafson, and Couch "Compiler Construction - Theory and Practice, 2nd
Edition", pp. 167-173, with their description of grammar tree nodes
(gtns).

The basis is 1) you translate EBNF statements to gtns, 2) walk the gtns to
obtain first and follow sets, and 3) translate the augmented gtns to
procedures, one for each EBNF statement.  You never see LL1.  You can add
semantic actions naturally and by adding a four-tuple (attribute name, LHS
attached to, attribute data type, and an inherited/synthesized/local
indicator), you can automatically synthesize the formal and actual
procedure parameters.

With EBNF, you have ~3+ times fewer productions, the semantic actions are
clear and clean, and the resulting syntax-directed translator is readable.
Several translator classes and I have produced a TWS in Modula-2 based on
this style and it is elegant.  Avoiding LL1 makes a recursive descent TWS
intuitive and enjoyable.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb  2 17:08:23 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Bill Mangione-Smith)
Subject: Re: Re How many vector registers are useful?
Message-ID: <[e-mail]>
Keywords: optimize, vector
Sender: [e-mail]
Reply-To: [e-mail] (Bill Mangione-Smith)
Organization: University of Michigan
References: <[e-mail]> <[e-mail]>
Date: Tue, 2 Feb 1993 14:05:40 GMT
Approved: [e-mail]

Bill Mangione-Smith <[e-mail]> writes:
> Santosh Abraham, Ed Davidson, and I had a paper two asplos's ago that
> looked at the minimal number of vector registers required for specific
> codes.  [.... W]e decided to focus on the minimal number of registers
> required to achieve optimal performance.

idacrd![e-mail] (David desJardins) writes:
   I haven't looked at your paper, but I think that you have to be very
   careful in using the word "optimal" here.  I have written a fair number of
   assembly-language routines for vector machines, and it is very often the
   case that the number of vector registers needed for "nearly optimal" code
   is substantially less than that needed for "perfectly optimal" code.

I've certainly seen that happen as well.  We constructed a tool that used
implicit enumeration, along with a predictable set of latencies (as you
suspected), to guarantee optimal performance and minimal register
requirements.  The study really focused on register requirements, and not
code scheduling.  But once I convince you that we meant real optimal, and
not fuzzy optimal like most people seem to, you've got to either assume
that I don't know the problem complexity or I'm not selling compiler
technology.

   In my experience, what often happens is that you can get a code which is
   "nearly optimal" in the sense of taking the correct number of chimes to
   execute the loop, but a few more ticks than is strictly necessary, because
   the usage of the vector registers is not perfectly synchronized.  A vector
   functional unit might have to wait for its input for a few ticks, for
   example, because the latency of the unit feeding it is greater than its
   own latency.  These few ticks might only add a few percent to the
   execution time of the loop, but it might take as much as double the number
   of vector registers to eliminate them.

In our study we did assume an idealized machine model, but you could
easily account for these effects without increasing the complexity of the
problem.  In fact, the addition of resource hazards tends to reduce the
search time by pruning the tree sooner.  But you are right, in practice
you probably want to ignore these issues.  Jalby, Eisenbies, and
Lichnewsky had a very simple machine model for the Cray-2 which achieved
very good results.  Of course, you could get into trouble if you were
scheduling on a machine with either short vector registers or a
programmable scratch pad that the compiler decided to divide into lots of
short registers.

   Perhaps you were looking at some sort of "ideal" vector machine?  Assuming
   things like constant latencies in the functional units would certainly
   simplify a truly optimal analysis while probably producing nearly
   equivalent results for practical purposes.

I don't see how we can discuss real optimal schedules without assuming
constant latencies.  For many machines the function units really have
constant latencies, and even without multiprocessor contention memory
references are a tough problem (to say the least).  But one thing we can
do is assume a pessimistic memory system (maybe modeled in the compiler as
a varied load depending on the code) and schedule to that, like the
Cydrome people did.

Ultimately, who knows what the memory is going to do from run to run,
except in a really degenerate case?  Scheduling pessimistically can cause
resource collisions that you would not have otherwise seen.  It may not be
possible to say for sure what the optimal performance on live hardware is,
let alone identify or generate code that achieves it.

Bill
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb  2 17:14:08 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Charles R. Martin)
Subject: Looking for references on correctness concerns in compilation
Message-ID: <[e-mail]>
Keywords: theory
Sender: [e-mail]
Reply-To: [e-mail] (Charles R. Martin)
Organization: UNC Department of Computer Science
Date: Tue, 2 Feb 1993 15:30:23 GMT
Approved: [e-mail]

I'm at work on a project involving the development of "trusted compilers"
--- compilers for which there is a strong guarantee of correct
compilation.  I would like to hear from anyone who is involved in
something similar; in particular, I'm interested in finding research that
relates to provably confirming the results of optimizations and code
generation.

Also, I'd be interested in any recommendations of conference or workshop
proceedings that might relate to this.  What are the best sources and
journals for correctness concerns in compilers?  What about new
compilation results in general?  Are there any organizations that have
produced technical reports on results that have not appeared in the
journal or conference literature?

Thanks for any help you can give.
--
        Charles R. Martin/(Charlie)/[e-mail]
     Dept. of Computer Science/CB #3175 UNC-CH/Chapel Hill, NC 27599-3175
        3611 University Dr #13M/Durham, NC 27707/[phone]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb  2 17:25:27 EST 1993
Xref: iecc comp.ai.neural-nets:8033 comp.arch:25812 comp.compilers:4197
Newsgroups: comp.ai.neural-nets,comp.arch,comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Hilfred Chau)
Subject: Parallel Compilation Problem
Message-ID: <[e-mail]>
Keywords: question
Sender: [e-mail]
Reply-To: [e-mail] (Hilfred Chau)
Organization: Dept. of Computing, Imperial College, University of London, UK.
Date: Tue, 2 Feb 1993 17:28:05 GMT
Approved: [e-mail]

          Compiling "FlowCharts like" Lang. into arrays of parallel "nodes"
          ----------------------------------------------------------------

Can you help ?

This is a parallel compilation problem.

Two of my friends (with Elect. Eng. background) are interested in how to
compile from (possibly) Flow Charts (need NOT be graphical, just a
representation) with logical (and, or, conditional, etc.)  & numerical
(integratin, differentiation, addition, etc) "boxes" (operations) into N x
M arrays of (parallel) "smart" nodes.  The flow chart may look like this:

          <input>
            |
           \|/
       |-->[Compare with 1]-YES->[integrate]---> Output
       |      |
       |     NO
       |     \|/
       |    [Differentiate]
       |      |
       ---<---

Note that, the representation of flowcharts is unimportant, since they can
be regarded as just another language. The point is that it has loops and
high level instructions eg. integration, as well as low level logical ones
eg. AND, OR, conditionals, etc.

Each node has a set of instructions (microcoded) with eg.  Inc, Dec, ADD ,
SUB, AND, OR, Buffer etc. Codes at each node are not fixed but determined
at compiled time. Also, the connection between each node is determined at
compiled time. Eg.

             [#](1,1)  [#](2,1) ......... [#](N,1)

             [#](1,2)

              .
              .
              .
             [#](1,M)  [#](2,M) ......... [#](N,M)

where each node [#](x,y), for all x<=N, y<=M, may contain:

             ---------------
             | AND | OR |  |
             ---------------
             | INC | DEC   |
             ---------------
             | Buffer | and many other possible instructions
             ---------------

Node that, a node [#](i,j) may be connected with [#](c,b), where i =/= j
=/= c =/= b, for one particular "flowchart" description, but it may NOT be
the case for another. One may regard each node as a mini "naive
processor".

My friends have a "virtual" machine which can execute the instructions of
the nodes in parallel. They want it to be generic so that even if the flow
charts changed, such that the compiled codes on each node and connections
among nodes changed, the underlying architecture (arrays of parallel
"smart" node) remains.

This seems obvious. But I am not a "compiler person".

They have a rather naive approach to this problem.

Do you know anyone, textbook or paper that describe something similar,
and/or with methodology (and algorithms/programs/packages for automated
compilation) doing such thing?


I hope my description is sufficiently clear!

Thank you in advance.

******Please answer by email:  [e-mail]***********

Yours,
Hilfred CHAU
--
Hilfred (Hiu Fai) CHAU        Email:     JANET       [e-mail]
Department of Computing                  UUCP        ...ukc!icdoc!hfc
Imperial College             Tel(office):([phone] ext.4990
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb  2 17:28:07 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Preston Briggs)
Subject: Re: Global Data flow analysis
Message-ID: <[e-mail]>
Keywords: analysis, bibliography
Sender: [e-mail]
Reply-To: [e-mail] (Preston Briggs)
Organization: Rice University, Houston
References: <[e-mail]>
Date: Tue, 2 Feb 1993 17:52:03 GMT
Approved: [e-mail]

[e-mail] (Bala Ramakrishnan) writes:
>While local (function level) data flow analysis is fairly well defined,
>does anyone have any info on techniques/problems associated with global
>data flow. Can you suggest any papers/books on this subject?

and the moderator writes:
>[Other than the practical issues involved with separate compilation or
>the lack thereof, are there any issues peculiar to global dataflow? -John]

Sure.  First though, let's follow tradition and say "interprocedural
analysis", since global analysis (traditionally!) means analysis
encompassing an entire routine.

Major differences include

    Definition of the problems and interpretation of the results.
    Typical interesting questions include: what variables _might_
    be referenced during this call, what variables _will_ be
    referenced during this call, what variables are live at the
    end of this procedure, what paramters are constant at upon
    invocation of this procedure, ...

    Asymptotic complexity.  The difference between "might be
    referenced" and "will be referenced" is considerable.

    Construction of the call (multi)graph, particularly in the
    presence of recursion, parameter aliasing, global variables,
    function-valued parameters and functions, multiple
    inheritence, ...  The more features you add, the more
    interesting it gets.

    And of course, the recompilation issue is significant.
    We can reasonably expect that individual procedures might have
    some maximum size, say 1000 statements.  It makes less sense
    to limit the size of programs!

There's a lot of interesting literature out there.  Here's a bunch of
papers in the area.  The '86 TOPLAS paper might be the best starting
point.  Be sure to check the bibliographies for further references.

Preston Briggs

------------------------------------------------------------------------------

title="Efficient Computation of Flow Insensitive Interprocedural
                 Summary Information",
author="Keith D. Cooper and Ken Kennedy",
pages="247--258",
journal=sigplan,
year=1984,
month=jun,
volume=19,
number=6,
note=pldi84

title="Analyzing Aliases of Reference Formal Parameters",
author="Keith D. Cooper",
booktitle=popl12,
year=1985,
month=jan,
pages="281--290"

title="Interprocedural Optimization: Eliminating Unnecessary Recompilation",
author="Keith D. Cooper and Ken Kennedy and Linda Torczon",
journal=sigplan,
year=1986,
month=jul,
volume=21,
number=7,
note=pldi86,
pages="58--67"

title="Interprocedural Constant Propagation",
author="David Callahan and Keith D. Cooper and Ken Kennedy and
        Linda Torczon",
journal=sigplan,
year=1986,
month=jul,
volume=21,
number=7,
note=pldi86,
pages="152--161"

title="The Impact of Interprocedural Analysis and Optimization in
                 the Rn Programming Environment",
author="Keith D. Cooper and Ken Kennedy and Linda Torczon",
pages="491--523",
journal=toplas,
year=1986,
month=oct,
volume=8,
number=4

title="Interprocedural Side-Effect Analysis in Linear Time",
author="Keith D. Cooper and Ken Kennedy",
pages="57--66",
journal=sigplan,
year=1988,
month=jul,
volume=23,
number=7,
note=pldi88

title="Fast Interprocedural Alias Analysis",
author="Keith D. Cooper and Ken Kennedy",
booktitle=popl16,
year=1989,
month=jan,
pages="49--59"

title="Constructing the Procedure Call Multigraph",
author="David Callahan and Alan Carle and Mary W. Hall and Ken Kennedy",
journal=ieeese,
volume=16,
number=4,
month=apr,
year=1990,

where ieeese = IEEE Transactions on Software Engineering
      toplas = Transactions on Programming Languages and Systems
      popl   = conference proceedings of Principles of Programming Languages
      pldi   = conference proceedings of Programming Language Design
        and Implementation
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb  2 17:30:23 EST 1993
Xref: iecc comp.compilers:4199 gnu.gcc.help:3950
Newsgroups: comp.compilers,gnu.gcc.help
Path: iecc!compilers-sender
From: [e-mail] (David Whitten)
Subject: GCC + Garbage Collect code = new GCC?
Message-ID: <[e-mail]>
Keywords: GCC, GC, question
Sender: [e-mail]
Reply-To: [e-mail] (David Whitten)
Organization: Science Applications Int'l, Corp. - Computer systems operation
References: <[e-mail]>
Date: Tue, 2 Feb 1993 18:08:32 GMT
Approved: [e-mail]

It sounds like someone has done a lot of work to analyze GCC for garbage
collection of intermediates, etc. (see previous posting on GCC as a back end)

Does anyone know if the GC code will be folded into the 'official' GCC
release?  It would make GCC a more palatable vehicle as a back end if it
were doing so...

David ([e-mail]) US:[phone]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb  2 17:31:31 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Preston Briggs)
Subject: Re: Thompson's 2c vs. gcc
Message-ID: <[e-mail]>
Keywords: architecture, GCC
Sender: [e-mail]
Reply-To: [e-mail] (Preston Briggs)
Organization: Rice University, Houston
References: <[e-mail]> <[e-mail]>
Date: Tue, 2 Feb 1993 19:11:38 GMT
Approved: [e-mail]

Pardo wrote:
>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.

Michael John Haertel <[e-mail]> writes:
>I've used 2c.  My experience is that gcc produces better code, contrary to
>Thompson's claim.  He most likely forgot to turn on -O with gcc.  Without
>-O, gcc produces really pessimal code, considerably slower than pcc
>without -O for example.

Is 2c the same compiler that Thompson writes about in his paper "A New C
Compiler"?  Very well.

Remember that Thompson wrote his paper about 3 years ago (published in
July 1990).  Gcc has evolved substantially since then.  Your experinces
today don't mean Thompson lied yesterday (or "forgot" the -O flag).

Thompson says:

    "Although it was not possible to directly compare gcc to the
    new compiler, lcc typically compiles in 50% of the time of gcc
    and the object runs in 75% of the time of gcc."

The times for lcc and the new C compiler are given as

     1.0s    new cc compile time
     0.5s    new cc load time
    90.4s    new cc run time

     1.6s    lcc compile time
     0.1s    lcc load time
    96.3s    lcc run time

Further, the tests were conducted with different operating systems.  So
Thompson only offers direct comparisons with lcc.  His comments about gcc
are probably a reflection of the experience described in Fraser and
Hanson's paper "A Retargetable Compiler for ANSI C".  They compare with
gcc version 1.35 (i.e., old!) with and without -O using four programs from
the SPECmark suite (gcc1.35, expresso, li, and eqntott) and running on 4
different machines.  I won't reproduce the entire table, but I'll try to
summarize honestly.

For object code speed, plain gcc usually produces slightly faster code on
the VAX and 68020; lcc produces faster code for the MIPS and Sparc
(Thompson's figure of 75% less run time is reasonable).  gcc -O dominates
lcc on the VAX, 68020, and Sparc, but lcc is wins more than it loses on
the MIPS.

For compile time, they don't compare with gcc -O.  However, lcc is
typically between 2 and 3 times as fast as plain gcc on all reported
architectures.

Thompson's comparisons with lcc were conducted on the MIPS.  It seems
reasonable that his remarks about gcc reflect the (at the time) poor
implementation of gcc on the MIPS.

Preston Briggs
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb  2 17:33:24 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Joe Mueller)
Subject: common C compiler benchmarks?
Message-ID: <[e-mail]>
Keywords: benchmarks, question, C
Sender: [e-mail]
Reply-To: [e-mail] (Joe Mueller)
Organization: Compilers Central
Date: Tue, 2 Feb 1993 19:09:55 GMT
Approved: [e-mail]

Can someone send me a copy of the common C compiler benchmarks
like dhrystone, whetstone, sieve, etc? Either send them directly
to me or point me at a ftp site...

Thanks in advance,
[e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb  3 18:22:04 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Vivek Buzruk)
Subject: Compiler construction in C++ and OOD
Message-ID: <[e-mail]>
Summary: Is any research done on object oriented design of compiler?
Keywords: OOP, C++, question, comment
Sender: [e-mail]
Reply-To: [e-mail] (Vivek Buzruk)
Organization: Sequent Computer Systems, Inc.
Date: Wed, 3 Feb 1993 00:39:37 GMT
Approved: [e-mail]

Some time back I read in Software Practice and Experience an article on
compiler construction using O-O methodology (I don't remember the name, it
must be within the last year). The article was not that complete, and
concentrated only on the front end. Obviously one can not go away from
traditional phase structured design to define the functionality of a
compiler.

But the same article gave me some thoughts about considering object
oriented design of a compiler.  Does anyone know about research done on
this topic?  OR any practical compilers using this methodology, and how
they do it?  Till now I thought a compiler is not a good application for
O-O design. If the parser and lexer are hand written, one can consider
them state machine. But what happens if you use LEX and YACC?

I will be happy if any one tells whether any complete compiler is written
in C++ either. Also in what way C++ is used, only as a better C or flavor
of OOD.

  -- Vivek -> [e-mail]
[There have been C++ derivatives of yacc, some just fixing the syntax a
little, others making parsing classes.  Flex produces legal C++ code but
doesn't do anything OOPish. -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb  3 18:22:55 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Andy Glew)
Subject: Re: Practicality of functional and logic languages?
Message-ID: <[e-mail]>
Keywords: functional
Sender: [e-mail]
Reply-To: [e-mail] (Andy Glew)
Organization: Intel Corp., Hillsboro, Oregon
References: <[e-mail]>
Date: Wed, 3 Feb 1993 06:32:47 GMT
Approved: [e-mail]

    I would like to know some opinions concerning functional and logic
    programming languages and their practical usability for programming:

Not directly related, but some varieties of functional and applicative
languages map much more naturally into hardware (VLSI) implementations
than procedural languages.

If efficient compilers could be generated for these languages, they would
be the preferred hardware modelling technique for many designers.

Ironically, in many design groups procedural languages are considered
"higher level", because the better compiled code permits simulations to be
done much quicker than code produced in the applicative style.  The
applicative style is often used for lower level "structural" design.

Note: I must admit that I am keying off single assignment form languages.
although many of the other features of functional and applicative
languages are also useful in hardware design.
--
Andy Glew, [e-mail]
Intel Corp., M/S JF1-19, 5200 NE Elam Young Pkwy,
Hillsboro, Oregon 97124-6497
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb  3 18:24:18 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Paul Curzon)
Subject: Re: Looking for references on correctness concerns in compilation
Message-ID: <[e-mail]>
Keywords: theory, bibliography
Sender: [e-mail]
Reply-To: [e-mail] (Paul Curzon)
Organization: Cambridge Automated Reasoning Group
References: <[e-mail]>
Date: Wed, 3 Feb 1993 12:40:50 GMT
Approved: [e-mail]

> I'm at work on a project involving the development of "trusted compilers"
> --- compilers for which there is a strong guarantee of correct
> compilation.  I would like to hear from anyone who is involved in
> something similar; in particular, I'm interested in finding research that
> relates to provably confirming the results of optimizations and code
> generation.

I have been working on a project (soon to finish) on the mechanical formal
verification of a code generator using the HOL system.  The language in
question is Vista which is a structured assembly language for the Viper
microprocessor. I have also looked at ways of executing a verified
compiler specification securely using a theorem prover, and formally
connecting a compiler proof with a programming logic.  There has also been
other work done here at Cambridge. The journal of automated reasoning had
a special issue on the Boyer-Moore system verification work a few years
back which you should check out. Polak's work is also worth looking at.
Jeff Joyce's tech report has quite an good overview of early compiler
verification work. There has also been a vast amount of work done on the
ProCos project at various institutions. I can send you copies of my papers
or other Cambridge tech.  reports if you are interested.  If it would be
useful I could send you a copy of my full bibliography of compiler
verification literature.


Paul Curzon

-----------

@TechReport{CamilleriJ91a,
  author =     "Juanito Camilleri",
  title =     "Symbolic Compilation and Execution of Programs by Proof: A
         Case study in {HOL}",
  institution =     "University of Cambridge, Computer Laboratory",
  year =     "1991",
  number =     "240",
  month =     dec,
}

@InProceedings{Curzon91,
  author =     "Paul Curzon",
  title =     "A Verified Compiler for a Structured Assembly Language",
  booktitle =     "Proceedings of the 1991 International Workshop on the {HOL}
         Theorem Proving System and its Applications",
  year =     "1992",
  OPTeditor =     "Myla Archer and Jeffrey J. Joyce and Karl N. Levitt and
                 Phillip J. Windley",
  publisher =     "{IEEE} Computer Society Press",
  OPTnote =     "A compiler for a small structured assembly language schema
         based on  Vista is verified using HOL. It compiles to a flat
         assembly language. Properties of safety and liveness are
         defined and it is suggested that proofs of source language
         programs could be mapped to proofs of target language
         programs.The compiler can be executed using the theorem
         prover."
}

@InProceedings{Curzon92DCCA,
  key = "Curzon92b",
  author =     "Paul Curzon",
  title =     "Compiler Correctness and Input/Output",
  booktitle =     "Proceedings of the 3rd {IFIP} Working Conference on
         Dependable Computing for Critical Applications",
  year =     "1992",
  publisher =     "Springer-Verlag",
  series =     "Dependable Computing and Fault-Tolerant Computing",
  OPTnote =     "The proof of correctness for the Vista compiler is extended
         to include IO commands. An oracle model of IO is used in the
         semantics, and it is shown that this does not hinder the
         proof."
}

@InProceedings{Curzon92LPAR,
  key = "Curzon92a",
  author =     "Paul Curzon",
  title =     "A Programming Logic For a Verified Structured Assembly
          Language",
  booktitle =     "Logic Programming and Automated Reasoning",
  year =     "1992",
  editor =     "A. Voronkov",
  pages =     "403-408",
  publisher =     "Springer-Verlag",
  volume =     "624",
  series =     "Lecture Notes in Artificial Intelligence",
  OPTnote =     "A programming logic of total correctness for a subset of the
         structured assembly language Vista is developed. It includes
         IO commands. Assertions about IO behaviour are made in the
         preconditions as predictions. The logic has been derived from
         a relational semantics in HOL."
}

@InProceedings{Curzon92HOL,
  author =     "Paul Curzon",
  title =     "Deriving Correctness Properties of Compiled Code",
  booktitle =     "International Workshop on Higher
                 Order Logic Theorem Proving and its Applications",
  year =     "1992",
  editor =     "L. Claesen and M. Gordon",
  OPTnote =     "A derived programming logic is combined with a verified
         implementation of Vista. This allows total correctness proofs
         to be performed on high level programs, and total correctness
         theorems about compiled code can be automatically obtained."
}

@TechReport{Curzon92WhyTR,
  author =     "Paul Curzon",
  title =     "Of What Use is a Verified Compiler Specification?",
  institution =     "University of Cambridge, Computer Laboratory",
  year =     "1992",
  number =     "274",
  OPTnote =     "Splitting a proof into implementation correctness and
         Specification correctness. A secure way of executing a
         verified specification by proof. Bootstrapping a
         verified compiler in a low level language, without first
         having a verified compiler implementation
                 available by ftp from ftp.cl.cam.ac.uk in the
                 directory hvg/papers. It is in the file WhyCompilerSpec.ps.Z"
}

@InProceedings{Joyce89b,
  author =     "Jeffrey J. Joyce",
  title =     "Totally Verified Systems: Linking Verified Software to
         Verified Hardware",
  booktitle =     "Specification, Verification and Synthesis: Mathematical
         Aspects",
  year =     "1989",
  editor =     "M. Leeser and G. Brown",
  publisher =     "Springer-Verlag",
}

 @TechReport{Joyce89,
   author =     "Jeffrey J. Joyce",
   title =     "A Verified Compiler for a Verified Microprocessor",
   institution =     "University of Cambridge, Computer Laboratory",
   year =     "1989",
   number =     "167",
   month =     mar,
 }

@Book{Polak81,
  author =     "Wolfgang Polak",
  title =     "Compiler Specification and Verification",
  publisher =     "Springer-Verlag",
  year =     "1981",
  OPTeditor =     "G. Goos and J. Hartmanis",
  volume =     "124",
  series =     "Lecture Notes in Computer Science",
}

@Article{StrotherMoore88,
  author =     "J. Strother Moore",
  title =     "A Mechanically Verified Language Implementation",
  journal =     "Journal of Automated Reasoning",
  year =     "1989",
  volume =     "5",
  pages =     "461--492",
}

@Article{Young89,
  author =     "William D. Young",
  title =     "A Mechanically Verified Code Generator",
  journal =     "Journal of Automated Reasoning",
  year =     "1989",
  volume =     "5",
  pages =     "493--519",
}
--
Paul Curzon            |  Tel: [phone]
University of Cambridge        |  Fax: [phone]
Computer Laboratory        |
New Museums Site                |
Pembroke Street            |  Email: [e-mail]
Cambridge CB2 3QG        |
United Kingdom            |
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb  3 18:27:47 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail]
Subject: yytext in POSIX lex
Message-ID: <[e-mail]>
Keywords: lex, question, comment
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Compilers Central
Date: Wed, 3 Feb 1993 14:49:17 GMT
Approved: [e-mail]

In an earlier post to comp.compilers, I solicited help from the net to
test the POSIX extensions to lex and yacc.  Few people responded to my
request due to the lack of existing POSIX implementations of lex and yacc.
Thank you to one and all for your help.  John Levine, recommended his and
his colleagues' book on lex and yacc, second edition.  A very good book
indeed.  I was able to construct test cases for exclusive and inclusive
start states, collating symbols, etc ...

The one thing I am having a problem with is the %array and the %pointer.
It sounds too easy, however, I am confused due to the lack of experience
and examples describing them in the book.  Moreover, I am having a tough
time coming up with a scenario where such %pointer and %array are applied
or helpful.  What is the difference in real life applications?  How are
they used?

Thank you much.

My news access is not very dependable, please use e-mail if possible.

Regards,
--
Amin Kassem - Unisys Corporation
System Software & Interface - R&D
e-mail: [e-mail]
[Of the two major implementations of lex, AT&T lex makes yytext an array
and flex makes it a pointer.  Some poorly written lexers depend on it
being one or the other, and %array and %pointer make it easier to port
such code.  You have to try fairly hard to tell the difference, e.g. use
sizeof(yytext). -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb  3 18:28:58 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Eliot Moss)
Subject: Re: GCC + Garbage Collect code = new GCC?
Message-ID: <[e-mail]>
Keywords: GCC, GC
Sender: [e-mail]
Reply-To: [e-mail] (Eliot Moss)
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
References: <[e-mail]> <[e-mail]>
Date: Wed, 3 Feb 1993 16:06:31 GMT
Approved: [e-mail]

On 2 Feb 93 18:08:32 GMT, [e-mail] (David Whitten) said:
> It sounds like someone has done a lot of work to analyze GCC for garbage
> collection of intermediates, etc. ... Does anyone know if the GC code will
> be folded into the 'official' GCC release?  It would make GCC a more
> palatable vehicle as a back end if it were doing so...

We have done work on gcc to add support for *run-time* garbage collection,
i.e., finding pointers and pointer-related quantities in registers and the
stack. I am not aware of garbage colleciton in the compiler *itself*.
--

J. Eliot B. Moss, Associate Professor    Visiting Associate Professor
Department of Computer Science        School of Computer Science
Lederle Graduate Research Center    Carnegie Mellon University
University of Massachusetts        5000 Forbes Avenue
Amherst, MA  01003            Pittsburgh, PA  15213-3891
[phone], 545-1249 (fax)        [phone], 681-5739 (fax)
[e-mail]            [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb  3 18:29:58 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Ramki Thurimella)
Subject: Re: Automatic Transformation of CFG to LL/LR
Message-ID: <[e-mail]>
Keywords: parse, theory
Sender: [e-mail]
Reply-To: [e-mail] (Ramki Thurimella)
Organization: Compilers Central
References: <[e-mail]> <[e-mail]>
Date: Wed, 3 Feb 1993 21:24:52 GMT
Approved: [e-mail]

[e-mail] (Barton Christopher Massey) writes
>I'll check the ref, but note that detecting, much less eliminating, CFG
>ambiguity is undecidable, which is sufficient to show that converting an
>arbitrary CFG to a necessarily unambiguous LL(1) or LR(1) grammar is
>undecidable.  My conjectures thus were limited to unambiguous CFGs -- it

Could you elaborate on how the ambiguity problem can be reduced to that of
transforming a CFG to LL grammar. I certainly see one of the directions,
i.e.  if transformation is successful, then the original grammar is not
ambiguous. How does the converse follow, i.e. if there is does not exist a
transformation, how can you conclude that CFG is ambiguous?

On a separate note, your conjecture when limited to unambiguous CFGs to LL
seem to be false, given the following exercise from the book on theory of
parsing by Aho and Ullman (exercise 5.2.13, pp. 397):

"Show that it is undecidable whether an LR(k) grammar is an LL grammar."

Ramki Thurimella
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb  3 18:31:31 EST 1993
Xref: iecc comp.parallel:5046 comp.lang.misc:9299 comp.compilers:4208
Newsgroups: comp.parallel,comp.lang.misc,comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Steve Tuecke)
Subject: PCN v2.0 now available
Message-ID: <[e-mail]>
Keywords: tools, parallel, available, FTP
Sender: [e-mail]
Reply-To: [e-mail] (Steve Tuecke)
Organization: Argonne National Laboratory, Chicago, Illinois
Date: Wed, 3 Feb 1993 23:02:16 GMT
Approved: [e-mail]

We are pleased to announce the release of PCN version 2.0.

PCN is a parallel programming system designed to improve the productivity
of scientists and engineers using parallel computers.  It provides a
simple language for specifying concurrent algorithms, interfaces to
Fortran and C, a portable toolkit that allows applications to be developed
on a workstation or small parallel computer and run unchanged on
supercomputers, and integrated debugging and performance analysis tools.
PCN was developed at Argonne National Laboratory and the California
Institute of Technology.  It has been used to develop a wide variety of
applications, in areas such as climate modeling, fluid dynamics,
computational biology, chemistry, and circuit simulation.

PCN can be used to program workstation networks, advanced parallel
supercomputers like the Intel Touchstone DELTA, and shared-memory
multiprocessors.  Currently we supply configurations for the following
machines:

        Workstation Networks:   Sun 4, NeXT, IBM RS/6000, SGI Iris
        Multicomputers:         Intel iPSC/860, Intel Touchstone DELTA
        Shared Memory Machines: Sequent Symmetry running Dynix (not PTX)

However, PCN is not difficult to port, and we will supply configurations
for other machines in the future.

  System components
  -----------------

The PCN system consists of several components:

  * Runtime system: There is a highly portable runtime system that is
implemented in C.

  * PCN compiler: The compiler translates PCN programs to a
machine-independent, low-level form (PCN object code).  An interface to
the C preprocessor allows macros, conditional compilation constructs, and
the like to be used in PCN programs.

  * PCN linker: The PCN linker combines PCN object code (i.e., PCN
compiler output), foreign object code that is called from PCN (i.e., C or
Fortran compiler output), libraries, and the PCN run-time system into a
single executable program.  This permits C and Fortran procedures to be
integrated seamlessly into PCN programs, and PCN programs to be executed
similar to programs written in other languages.

  * Standard libraries: A set of standard libraries provides access to
Unix facilities (e.g., I/O) and other capabilities.

  * Virtual Topology tools: These support process mapping on a variety of
virtual machines, and templates for writing reusable parallel code.

  * PDB: PDB is the PCN symbolic debugger.  It includes specialized
support for debugging of concurrent programs.

  * Gauge: Gauge is an execution profiler for programs written in PCN and
other languages.  It includes run-time system support for collecting and
saving profiles, and an X windows based graphical tool for interactive
exploration of profile data.  It is particularly useful for finding and
correcting load imbalances and bottlenecks in parallel programs.

  * Upshot: Upshot is a trace analysis tool for programs written in PCN
and other languages.  It includes run-time system support for collecting
and saving traces, and an X windows based graphical tool for interactive
exploration of trace data.

  Features
  --------

Several features of PCN make it particularly useful for a wide variety of
parallel programming tasks:

  * Portability: Because PCN is portable, parallel programs can be
developed under a friendly (and inexpensive) environment such as a
workstation.  Once the program is working properly, it can moved with
little difficulty to different parallel computer targets, such as large
parallel computers and networks of workstations.

  * Flexibility: PCN is particularly well suited for the development of
complex parallel programs involving irregular communication patterns or
dynamic load balancing.

  * Rapid prototyping: PCN is an excellent system for the rapid
prototyping of parallel algorithms.  The combination of high-level
language and integrated profiling tools make it easy to explore and
evaluate alternative algorithms and implementation strategies.

  * Multilingual: PCN programs can call Fortran and C procedures.  This
allows existing code to be reused within parallel PCN programs.  It also
allows users to easily expoit advanced Fortran and C compiler technology
in critical sections of parallel programs.

  Availability
  ------------

PCN is in the public domain.  You can obtain the complete distribution by
anonymous ftp from:

    info.mcs.anl.gov
    /pub/pcn/pcn_v2.0.tar.Z

The README file in that directory contains a description of exactly what
is available, including the software distribution, documentation, and
related papers.

The PCN distribution contains all source code, installation instructions,
a users guide in both LateX and Postscript formats, and examples.

  Documentation
  -------------

  * There is a PCN users guide which contains both tutorial and reference
material:

    "Parallel Programming with PCN"
    Ian Foster and Steven Tuecke
    Argonne National Laboratory Technical Report ANL-91/32 Rev. 2

This users manual is included in the PCN distribution, and is also
available separately at the anonymous ftp site mentioned above.  Bound,
soft-cover copies of this users guide will be available shortly -- send us
email if you would like a copy.

  * The following paper provides a good overview of the PCN system and
examples of how it has been used:

    "Productive Parallel Programming: The PCN Approach"
    Ian Foster, Robert Olson, and Steven Tuecke
    Scientific Programming , 1(1), pp. 51--66.

A preprint of this paper is available in Postscript form both in the PCN
distribution and at the anonymous ftp site mentioned above.

  * The following book is an introductory parallel programming text book
with all of its examples written in PCN.  It has been used at several
universities, in conjuction with the PCN system and users manual, to teach
parallel programming.

    "An Introduction to Parallel Programming"
    K. Mani Chandy and Stephen Taylor
    Jones and Bartlett Publishers
    ISBN: 0-86720-208-4

  * Additional references can be found in the PCN users guide.

  Further Information
  -------------------

For further information on PCN, please send email to:

    [e-mail]

Or contact:

    Ian Foster         or    Steve Tuecke
    [e-mail]        [e-mail]
    (708)-252-4619            (708)-252-8711
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb  3 18:34:20 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (workshop)
Subject: CFP: Associative Processing and Applications Workshop
Message-ID: <[e-mail]>
Keywords: conference, CFP, parallel
Sender: [e-mail]
Reply-To: [e-mail] (workshop)
Organization: Syracuse University
Date: Wed, 3 Feb 1993 23:23:04 GMT
Approved: [e-mail]

                        CALL FOR PARTICIPATION

            2ND ASSOCIATIVE PROCESSING AND APPLICATIONS WORKSHOP
                          Syracuse, New York
                           July 21-23, 1993



                             sponsored by
                 The CASE Center, Syracuse University
                                 and
                 Massachusetts Institute of Technology



Following the success of last year's Associative Processing and
Applications Workshop, we are pleased to announce the 2nd Workshop which
will be held at Syracuse University on Wednesday, 21st to Friday, 23rd of
July 1993.

This Workshop is intended to bring together researchers in academia and
industry working on the design, analysis, development, and application of
massively-parallel associative processing.  The goal of the workshop is to
promote interaction between researchers interested in the most recent
technological advances relevant to associative processing.  In addition,
the format of the workshop will be kept very informal to encourage authors
to report on work in progress.  Please note that only extended abstracts
will be required.

The design of associative processors, due to their highly specialized
nature, requires an in-depth understanding of the computational
requirements of the applications of interest in order to create cost
effective processor architectures.  It is the identification of the
relationships between applications and associative processor architecture
that has and will continue to determine how new or improved technologies
will influence and be used in further processor developments.
Consequently, papers that deal with large applications, programming
paradigms, machine prototypes, and modeling techniques are of particular
interest.

Areas of interest include, but are not limited to:

* applications - either implemented, or under development
* software models of associative processors - functional, stochastic, etc.
* architectures - simulated or experimental results from chips to
                  entire systems, tradeoff studies
* physical design - CAM cell design, CAM chip design, silicon compilation
* interfaces - von Neumann/associative, special controllers, etc.
* algorithm analysis - time complexity, hardware requirements
* programming paradigms - software development environments, tools, and
                          languages
* program mapping - techniques for compiling high level languages
                    to associative machines


Attendance will be limited to approximately fifty (50) people to insure
time for excellent interaction between workshop participants.

SUBMISSIONS:

Authors are invited to send six (6) copies of an extended abstract by May
8, 1993.  Abstracts are restricted to no more than 5 double-spaced pages
(1500 words), not including bibliography or figures.  Abstracts must
include a cover letter with the following information: title of paper,
full names of authors, postal addresses and email-addresses of the
authors, and keywords indicative of the theme of the paper.  The abstracts
will be refereed, and the authors will be notified of acceptance by June
5, 1993.  As the format of this workshop will be informal, full length
papers, although encouraged, are not required.  Accepted abstracts will be
duplicated and distributed to all participants at the workshop.

All submissions and inquiries for further information should be directed
to:

         Kirk Twardowski
         CASE Center, Syracuse University
         2-212 Center for Science and Technology
         Syracuse, NY 13244-4100
         315/443-4122
         [e-mail]

                   WORKSHOP LOCATION and FEE

The workshop will be held at the CASE center, which is located in the
Center for Science and Technology on the Syracuse University campus.  The
cost will be $85 per attendee, and includes:

* "Get-Acquainted" reception on July 21st
* Luncheon on July 22nd
* Refreshments
* Copy of abstracts


                   PROGRAM COMMITTEE

Bruce Berra, CASE Center/SU
Dave Bezek, IBM/Owego
Geoffrey Fox, NPAC/SU
Eby Friedman, University of Rochester
J. Storrs Hall, Rutgers University
John Oldfield, Syracuse University
Behrooz Parhami, University of California
Jerry Potter, Kent State University
Charles Sodini, MIT
Chuck Stormon, Coherent Research Inc.
Klaus Waldschmidt, Johann Wolfgang Goethe Universitaet
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb  4 08:51:31 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Mark W Modrall)
Subject: optimization/code quality
Message-ID: <[e-mail]>
Keywords: architecture, optimize
Sender: [e-mail]
Reply-To: [e-mail] (Mark W Modrall)
Organization: Compilers Central
References: <[e-mail]> <[e-mail]>
Date: Wed, 3 Feb 1993 14:53:21 GMT
Approved: [e-mail]

>There's a rather large switch inside, and the compiler manages to mess up
>its table, and generate eronous code, or backend failures. Which get fixed
>once in a while by using level 3 optimisation. (Hence I knew the time.)
>Supposedly GCC has some of the same features, most compilers are not very
>often exersized at the nopt. level and have relatively more bugs in that
>part.

One of my favorite compiler experiences was with the compiler on a
Concurrent system... when you turned on level 3 optimization, you would
occasionally see a diagnostic message pop up during compilation "I-Overuse
of registers, see manual for more information"

Well, none of the resultant code worked... i saw that message, and said
"it's informational, that can't be it."  finally, at the end of my rope, I
looked at the manual for more information, and the note said, basically,
"We didn't get this level of optimization right.  It generates bad code."

I called up Concurrent and filed a bug report that read "User is appalled
by the classification of this error message."

-mark
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb  4 08:54:51 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Vern Paxson)
Subject: Re: justify use of flex vs. lex - summary
Message-ID: <[e-mail]>
Keywords: lex, comment
Sender: [e-mail]
Reply-To: [e-mail] (Vern Paxson)
Organization: Lawrence Berkeley Laboratory, Berkeley CA
References: <[e-mail]>
Date: Thu, 4 Feb 1993 03:44:22 GMT
Approved: [e-mail]

[e-mail] (Steve Layten x3451) writes:
> one person ... suggested that I look at PCCTS:
> ... you can use it for commercial products without violating its notice,
> which explicitly permit use for commerical or proprietary software (both
> prohibited by bison&flex's copyright).

Just to keep the record straight (as this point often gets confused),
while bison is covered by the GPL, flex is not; it's covered by the BSD
copyright, which freely permits use in commerical and proprietary software
(so does the GPL, actually, as long as source code is made available).
Furthermore, scanners *generated* by flex are not covered by any sort of
copyright (again, unlike bison-generated parsers).  You can do whatever
you like with them.  So Basile's final point above is incorrect.

        Vern

    Vern Paxson                [e-mail]
    Systems Engineering                ucbvax!ee.lbl.gov!vern
    Lawrence Berkeley Laboratory        [phone]
[For yacc users for whom the GPL is a problem, Berkeley yacc is in the
public domain, meaning you can do anything with it you want. -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb  4 08:55:55 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: Michael John Haertel <[e-mail]>
Subject: Re: Thompson's 2c vs. gcc
Message-ID: <[e-mail]>
Keywords: architecture, GCC
Sender: [e-mail]
Reply-To: Michael John Haertel <[e-mail]>
Organization: Compilers Central
References: <[e-mail]> <[e-mail]>
Date: Thu, 4 Feb 1993 04:02:03 GMT
Approved: [e-mail]

In a moment of wonderful insight that may have cleared this whole matter
up, Preston Briggs wrote:

>Is 2c the same compiler that Thompson writes about in his paper "A New C
>Compiler"?  Very well.
> [ ... ]
>Thompson's comparisons with lcc were conducted on the MIPS.  It seems
>reasonable that his remarks about gcc reflect the (at the time) poor
>implementation of gcc on the MIPS.

Yes, 2c is the *68020* version of Thompson's compiler.  The MIPS version
is called vc.  The informal comparisons I conducted were 2c compared with
gcc on a 68020.

I hadn't realized, or had forgotten, that Thompson had conducted his
comparisons on the MIPS.  The MIPS port of gcc version 1.x was certainly
not well tuned.

I think this explains everything.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb  4 08:57:00 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Charles Manning)
Subject: PIC 16Cxx Compilers
Message-ID: <[e-mail]>
Keywords: tools
Sender: [e-mail]
Reply-To: [e-mail] (Charles Manning)
Organization: Compilers Central
References: <[e-mail]>
Date: Thu, 4 Feb 1993 16:48:02 GMT
Approved: [e-mail]

>I'm looking for a compiler for the PIC 16C5x series of microprocessors.

I've had a bit of experience with PICs and HLL's on other
microcontrollers.  Sorry, but I don't think HLL's are feasible for PIC
16Cxx family.

Even shoehorning C into a 8051 has taken the industry quite a while to get
anywhere near to useful.  In case you don't know it, it has 64kbyte
external RAM 64kbyte ROM 128bytes RAM etc.

If you can't abide the PIC assembler (I hated it at first, but I quite
like it now) there is always the Parallax development kit for PIC16C5x.

The Parallax assembler is easier for most people to read but the parallax
"instructions" may generate more than one PIC instruction.

Apparently the Parallax stuff is available on their BBS [phone].

Regards
Charles Manning

[e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb  4 08:59:26 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Joachim Schrod)
Subject: Re: yytext in POSIX lex
Message-ID: <[e-mail]>
Keywords: lex, comment
Sender: [e-mail]
Reply-To: [e-mail] (Joachim Schrod)
Organization: TH Darmstadt, FG Systemprogrammierung
References:  <[e-mail]>
Date: Thu, 4 Feb 1993 11:32:23 GMT
Approved: [e-mail]

The moderator writes:
> [Of the two major implementations of lex, AT&T lex makes yytext an array
> and flex makes it a pointer.  Some poorly written lexers depend on it
> being one or the other, and %array and %pointer make it easier to port
> such code.  You have to try fairly hard to tell the difference, e.g. use
> sizeof(yytext). -John]

Hmm, I see this a bit different.

If the element type of yytext is "unsigned char" and your default char
attribute is "signed char", an ANSI C compiler will complain if you call
strcpy (even worse, a C++ compiler will signal an error).  So, a common
technique is to define a variable s_yytext (here `s' stands for `string',
not for `signed') which happens to have the same value as yytext but with
an element type of "char" (ie, it's "char *").
    If yytext is an array, this variable may be initialized once (may even
be "const"), if yytext is a pointer, it must be initialized anew before
each action. (In the latter case one needs something like the
YY_USER_ACTION of flex.)

I want to emphasize that (for me) this has nothing to do with %array and
%pointer in the first place -- it's a note concerning the opinion from
above that the difference between array and pointer implementations is
only noticable in ``bad'' lexers. It's visible in lexers which have C++
actions.

Btw, I've checked POSIX.2 about the `official element type' of yytext. The
phrase ``yytext is either an external character array or a pointer to a
character string'' might be open to interpretation. :-(
    When I'm about it, I want to mention another problem with lex for
POSIX.1 based software (since this belongs more to the subject of this
thread :) Many systems (eg, AIX and HP-UX) support more than one
`standard', and select the appropriate system by some cpp macros when the
first system include file is read in. Now POSIX demands that I shall add a
"#define _POSIX_SOURCE" to my source (at the very front, of course), and
promises me that I will receive a POSIX.1 environment then. Nice -- but
this does not happen in lex sources. Here I have to give -D_POSIX_SOURCE
(or -D_XOPEN_SOURCE or whatever I want) on the command line of the C
compiler. (Which is normally never called by me, but by some
make/imake/or-similar tool...) If I forget this I will have a plain ANSI C
environemnt -- without any further function or type declarations.
<Grmpfh>.

--
Joachim Schrod            Email: [e-mail]
Computer Science Department
Technical University of Darmstadt, Germany
[I'd #define s_yytext as ((char *) yytext) if that were a problem. -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb  4 23:56:14 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail]
Subject: CFP:  IEEE Int'l Conf. on Requirement Engineering
Message-ID: <[e-mail]>
Keywords: CFP
Sender: [e-mail]
Reply-To: [e-mail]
Organization: University of Illinois at Chicago
Date: Thu, 4 Feb 1993 17:03:44 GMT
Approved: [e-mail]

 IEEE INTERNATIONAL CONFERENCE ON REQUIREMENTS ENGINEERING
An IEEE Software Technology Transfer Conference

April 18-22, 1994

Colorado Springs, Colorado, USA -- and -- Taipei, Taiwan, ROC

Sponsored by IEEE Computer Society
Association Pending with AIAA, MCI, CITTI, and Taiwan Minister of
Telecommunications

C  A  L  L    F  O  R    P  A  P  E  R  S

ICRE '94 is a new international conference designed to offer an
opportunity for requirements engineering practitioners and researchers to
exchange experiences and new technology.  The conference offers high
quality paper and panel sessions, tutorials, keynote speakers, and a
practical workshop.  The conference will have three areas of focus:

o    Experiences, problems and recommendations of and for practitioners
o    Research results ripe for exploitation (i.e., "ripe fruits" of
    technology)
o    Research with long term goals

Topics within requirements engineering include, but are not limited to:

o    Case Studies
o    Requirements Capture and/or Analysis
o    Requirements Reuse
o    Principles, Appoaches and Standards
o    Animation and Prototyping
o    Req'ts Specification and/or Validation
o    Taxonomies of Requirements
o    Philosophical and Social Underpinnings
o    Multiple Views of Requirements
o    Requirements Engineering Environments
o    Requirements Process Models
o    Representations, Languages and Notations
o    Issues, Problem Areas and Recommendations by Practitioners

Send seven copies of papers (4000 to 6000 words including a 150 word
abstract) or panel proposals (1 to 2 page discussion plus panel member
names) to:

>From North and South America, and Europe:    From Asia, Africa, Australia, and
Pacific:
Dr. Pei Hsia                     Dr. Chyan-Goei Chung
ICRE Program Co-Chair                 ICRE Program Co-Chair
University of Texas at Arlington         National Chiao Tung University
Computer Science and Engineering Dept         Computer Science and
                         Info. Eng'g Dept
Box 19015                     1001 Ta Hsueh Rd
Arlington, TX 76019-0015 USA             Hsin-chu, Taiwan 30050 ROC
phone:  [phone]
email:  [e-mail]


Key Dates:

Paper Submissions and Panel Proposals Due        August 6, 1993
Authors Notified of Acceptance                October 18, 1993
Final Camera-Ready Manuscripts Due            December 15, 1993

This conference will be held simultaneously in Taipei and Colorado
Springs, with live satellite broadcasts in both directions.  Please
indicate with your submission: (1) principal author's affiliation,
address, telephone, FAX, and email, (2) preferred presentation location
(U.S. or Taiwan), and (3) the conference focus most appropriate for your
submission (current experience, ripe fruit, or long-term research).
**************************
The best papers of the conference will receive special recognition and
will be recommended for publication in a major software journal.


Steering Committee:

H. Black        I. Ho
C. Chang        P. Hsia
A. Davis        J. Siddiqi
M. Dorfman


Conference Co-Chairs:

Alan M. Davis
University of Colorado
Colorado Springs, CO
80933-7150
phone: [phone]
email:  [e-mail]

General Yun Kuo
Institute for Information Technology
116 Nanking E. Rd.; Sec 2; 12 Floor
Taipei, Taiwan
phone: [phone]


Workshop Chair:

Jawed Siddiqi
Sheffield City Polytechnic
Napier St.
Sheffield, SI IWB, UK
email:  [e-mail]


Registration Chair:

Kerry Baugh
University of Colorado
Colorado Springs, CO
80933-7150


Program Co-Chairs:

Pei Hsia
Chyan-Goei Chung


Program Committee:

S. Andriole        I. P. Lin
E. Bersoff        Luqi
H. Black        T. Nakajima
J. Brackett        C. Potts
C. Chang        C. Ramamoorthy
J. Y. Chen        W. Royce
P. Coad            C. Shekaran
M. Dorfman        J. Siddiqi
S. Fickas        C. Singer
A. Finkelstein        R. Thayer
S. Gerhart        J. Tsai
I. Ho            G. Wittenstein
S. Isoda        J. Wood
K. Jordan        R. Yeh
D. Kung            G. Zelesnik
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb  4 23:57:38 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail]
Subject: Review and Registration: Petri Nets '93 /Chicago
Message-ID: <[e-mail]>
Keywords: conference
Sender: [e-mail]
Reply-To: [e-mail]
Organization: University of Illinois at Chicago
Date: Thu, 4 Feb 1993 17:23:09 GMT
Approved: [e-mail]

**************************************************
        PREVIEW AND REGISTRATION
        PETRI NETS 1993  / Chicago

    14th International Conference on Application and Theory
    of Petri Nets, June 21-25, 1993, Bismark Hotel, Chicago

        MONDAY, JUNE 21, 1993
        The following three parallel sessions:

1. Introductory Tutorial I:
    Informal Intro. to Petri Nets (W. Reisig),
    Elementary Net Systems I (G. Rozenberg),
    Place /Transition Nets I (W. Reisig),
    High-Level Nets I (K. Jensen),
    Timed & Stochastic nets I (M. Ajmone Marsan)

2. Advanced Practical Tutorial:
    Petri Nets, Artificial Intelligence and their Application
    to Computer Integrated Manufacturing (R. Valette)

3.  Oral presentation of the tools that will be exhibited
    throughout the conference: (open to all participants)

        TUESDAY, JUNE 22, 1993
        The following four parallel sessions:

1. Introductory Tutorial II:
    Elementary Net Systems II (G.Rozenberg),
    Place /Transition Nets II (M. Silva),
    High-Level Nets II (K. Jensen),
    Intro. to GSPNs (M. Ajmone Marsan),
    Levels of Petri Nets (H. J. Genrich)

2. Advanced Theoretical Tutorial:
    The Relationships between different Models of Concurrency
    (M. Nielsen)

3.  Case Studies Tutorials:
    Asynchronous Circuit Design
    (R. Shapiro, Meta Software)
    Simulation of Communication Protocols
    (M. Ajmone Marsan, Politecnico di Torino)
    Work Flow Analysis of Business Processes
    (V. Pinci, Meta Software)
    Reliability Modelling of a Heterogeneous
    Multiprocessor (K. Trivedi, Duke University)

4. One-Day (Tuesday, June 22) Workshop on Computer
    Supported Cooperative Work: Petri Nets and Related
    Formalisms. To register for this workshop, circle YES in the
    conference registration form.) For details, contact De Michelis
    ([e-mail]) or  Ellis ([e-mail]).

    WEDNESDAY, JUNE 23 TO FRIDAY, JUNE 25
    A single session of presentation of regular papers as well
    as the following three invited talks:

1. Groupware and Concurrency Modeling
    (Clarence Ellis, University of Colorado )

2. Applications of Qualitative and Quantitative Structural
    Analysis of Net Models ( Manuel Silva, Univ. of Zaragoza)

3. Petri Nets with Continuous-State Marking Processes
    (Kishor S. Trivedi, Duke University)

        Social Programs
    Informal gathering, 6-7 pm on Tuesday, June 22
    Conference Reception & Banquet on Thursday, June 24
    (Optional Informal Dinner-Excursion on Friday Evening,
    June 25, if there is enough interest.)

    For the complete tutorial and conference program, contact Murata
    or Shatz via fax [phone] or via e-mail: [e-mail].

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
REGISTRATION FORM

To register, return this form to

    PETRI NETS 1993 Registrar
    UIC Conferences and Institutes (M/C 607)
    1033 W. Van Buren St., Suite 700N, 7th Floor
    Chicago, IL, 60607 USA

With credit card payment, you can register by
Phone [phone] or FAX [phone],
but not via e-mail.

Please type or print
Last Name ___________________ First Name _______________
Organization _________________________________________
Address _____________________________________________
___________________________________________________
___________________________________________________
Phone: _____________________ Fax: ____________________
E-mail: _____________________________________________
(If you don't want your phone #, etc. to appear on
the participant list, please so indicate.)

Please circle membership information, as appropriate.
I am a member of: ACM AFCET AICA  BCS  EATCS  GI  IEEE.

I wish to register for the following:

___ Two-Day Tutorial, June 21-22   Fees (Check one):
Member (by May 24) ___$300, (after May 24) ____$350;
Non-Members (by May 24) ___$320, (after May 24) ___$370

    Check which session you plan to attend each day
        Monday, June 21 (check one)
        _____ Introductory I
        _____ Advanced Practical

        Tuesday June 22 (check one)
        _____ Introductory II
        _____ Advanced Theory
        _____ Case Studies

___ Three-Day Conference (June 23-25)  Fees (Check one):
Member (by May 24) ___$395, (after May 24) ___$445;
Non-Members (by May 24) ___$415, (after May 24) ___$465

Do you wish to register for the workshop, "Computer Supported
Cooperative Work: Petri Nets and Related Formalisms", on June 22?
(Circle one)  YES   NO
(Note: To register for this workshop, you must
also be registered for the conference.)

__ Additional/guest banquet tickets  Number __@ $45 each = $____

Total Payment Enclosed $______________________________

PAYMENT METHOD:___ Check or money order, payable to
        the University of Illinois - PETRI NETS 1993.
U.S. currency only. Funds must be drawn on a U.S. bank; or

__ Discover   __ MasterCard   __ Visa Exp. Date ____/______
Credit Card Number ___________________________________
Cardholder's Signature _________________________________

Refunds, less $25 processing fee, available for requests received
in writing by June 5, 1993.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    MAKE YOUR OWN ROOM RESERVATIONS
by June 5, 1993 at

     The Bismark Hotel,
     171 W. Randolph Street
     Chicago  Illinois 60601, U.S.A.

     FAX [phone]
     Phone [phone],
     Outside Chicago, but within Continental U.S. 1-800-643-1500

Ask for special Petri Nets '93 rates:
$65 Single, $75 Double, $85 Triple, $95 Quad.
Identify yourself as a participant in Petri Nets' 93.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb  4 23:58:53 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Frank Tip)
Subject: program slicing?
Message-ID: <[e-mail]>
Keywords: question
Sender: [e-mail]
Organization: CWI, Amsterdam
Date: Thu, 4 Feb 1993 17:38:07 GMT
Approved: [e-mail]

Hello,

I am interested in static and dynamic program slicing techniques.  If
you know of any references, please let me know (by E-mail).

I'll post a summary of these responses later.

                                Frank Tip.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb  5 00:00:37 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Cliff Click)
Subject: Re: Compiler construction in C++ and OOD
Message-ID: <[e-mail]>
Keywords: C++, OOP
Sender: [e-mail]
Organization: Center for Research on Parallel Computations
References: <[e-mail]>
Date: Thu, 4 Feb 1993 18:49:10 GMT
Approved: [e-mail]

[e-mail] (Vivek Buzruk) writes:

> Till now I thought a compiler is not a good application for O-O design.

> I will be happy if any one tells whether any complete compiler is written
> in C++ either. Also in what way C++ is used, only as a better C or flavor
> of OOD.

My research compiler is written entirely in C++ (except for the front-end
parsing stuff).  I find the O-O issues immensely helpful.  I have class
definitions for all the interesting internal data structures: hash tables,
symbol tables, instructions, etc.  The complexity control C++ gives me is
a BIG win.

Of course, I'm in the minority here at Rice.  Most of the previous work
has been done in C.  A newer project (1 yr old or so) has been started in
C, but with design decisions that strongly mirror O-O design.

> Obviously one can not go away from traditional phase structured design
> to define the functionality of a compiler.

Hummm... I would disagree with this statement - and don't see what it has
to do with O-O design of a compiler.

>   -- Vivek -> [e-mail]

Cliff Click                                            [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb  5 00:05:30 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Joe Buck)
Subject: Re: Thompson's 2c vs. gcc
Message-ID: <[e-mail]>
Keywords: architecture, GCC
Sender: [e-mail]
Organization: U. C. Berkeley
References: <[e-mail]> <[e-mail]>
Date: Thu, 4 Feb 1993 18:57:31 GMT
Approved: [e-mail]

Michael John Haertel <[e-mail]> writes:
>I hadn't realized, or had forgotten, that Thompson had conducted his
>comparisons on the MIPS.  The MIPS port of gcc version 1.x was certainly
>not well tuned.

It wasn't just that it was not well tuned.  gcc-1 did not have an
instruction scheduler and could not fill delayed branch slots.  gcc-2 does
both.  I understand that this makes a difference of about 30% on the
Sparc; the number is probably similar on the MIPS.  gcc-1 did a good job
on the CISC architectures (Vax and 680x0) it was initially designed for.
--
Joe Buck    [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb  5 00:16:58 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Richard Stallman)]
Subject: Adding other languages to GCC (was, using GCC for back-end)
Message-ID: <[e-mail]>
Posted-By: [e-mail] (David Petrie Stoutamire)
Keywords: GCC
Sender: [e-mail]
Organization: International Computer Science Institute, Berkeley, CA, U.S.A.
References: <[e-mail]>
Date: Thu, 4 Feb 1993 21:25:56 GMT
Approved: [e-mail]

The right way to add a new language front end to GCC is to make it
generate the not-quite-syntax-tree data structure defined in tree.h.  That
is the input to the language-independent part of GCC.  You should not try
to make RTL directly.

To do this, you must understand that part of GCC.  But if you can write a
compiler, you can do that.

For a front end to generate RTL is undesirable because it is unmodular.
How to generate RTL depends on the target machine in complex ways.  You
should leave that to the code which already does it.  The tree data
structure is machine-independent aside from a few storage layout
parameters.

The idea of reading this RTL from a file is even worse.  First, the RTL
chain is not the only information that the compiler needs.  So this is far
from the simple task you might imagine.  But even if you did make it work,
reading the RTL woulkd be very slow.  It is just dumb to make the parser
communicate with the rest of the compiler by passing text through a file.

The right solution is to put the parser in the same process as the rest of
the compiler, and make it generate trees.  This is what the front ends for
Pascal, Fortran, and Ada do.

There is no good documentation for the tree data structure.  If someone
wants to write documentation and give it to the FSF, that would be useful.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb  5 00:18:52 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: Anthony Naggs <[e-mail]>
Subject: Re: Compilers for Microchip PIC16C5x
Message-ID: <[e-mail]>
Keywords: tools
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]>
Date: Fri, 5 Feb 1993 01:25:00 GMT
Approved: [e-mail]

Foster Schucker, <[e-mail]>, writes:
> I'm looking for a compiler for the PIC 16C5x series of microprocessors.
>
> I'd prefer C or Pascal, hosted on MS-DOS but beggars can't be choosers.

I was interested in this last September, so I contacted Arizona Microchip
in the UK.  They directed me to a company, (only five miles up the road
from me!), who are UK agents for:

    CC5X Small C Cross Compiler for the Microchip PIC16C5x Family

    From: B. Knudsen Data       Fax: [phone]
          Stubbanv. 33B
          7037 Trondheim
          NORWAY

Well, I managed to find the information sheet, but I have mislaid the demo
disk & pricing details.

I considered the 'Small C' to be too small and expensive, also (IMHO) the
code generator seemed to be rather poor.

The [Arizona] Microchip distributor in your area should be upto date on
the available tools.

> The Microchip PIC 16C5x series of microprocessors is a small (18-28 pin)
> chip with 33 instructions, a 12 bit word, with 2K of EPROM.  ...

They are very neat, I have used them in several projects.  Also parts
introduced around last October include E^2 data retention and on-chip
ADCs.  Motorola apparently introduced their 'insect' series of small
microcontrollers to compete about six months ago, but I don't have their
literature to compare architectures.

Why am I posting straight to comp.compilers?

I have been playing with my own version of the assembler, as Microchip
charge for their development tools.  I have added features found in other
assemblers, such as include files, linking of intermediate object modules,
... but this is still somewhat short of my ideal.

Having seen the other C compilers' efforts I would like to write my own,
but the very restricted architecture looks like making efficient
optimisation difficult.  So my first question, is there any literature on
optimising for strange architectures, (PICs have one register used for all
data transfers, several -bytes- of RAM, no stack space for data) ?

My second is related, what is a reasonable subset of C to support for such
a small processor?


I have also found that most people wanting to use PICs are electronics
engineers or hobbyists with little or no programming experience.  So they
would like a simple language that is easy to learn (an hour or two for
basic use, :-), clear to read, with support for both tight and loose
coupling to the hardware features.  Before I write a compiler for my own
language, I thought I should ask here for suggestions!

(As a guide: lack of a hardware stack rules out Forth and other threaded
languages, C & Pascal have too much syntax to learn).

Tempting fate, I anticipate that I would like to partition programs so
that they are spread between co-operating PIC processors.  So a 'small'
OCCAM might be a good base, allowing simple addition of the parallel
processing syntax at a later date.  Anybody have useful experience in
porting OCCAM?

As usual, if you email suggestions to me I'll summarise in a week or two.
Or you can just write and chat about PIC processors!

Hope this is of interest,
Anthony Naggs
Software/Electronics Engineer                   P O Box 1080, Peacehaven
                                                East Sussex  BN10 8PZ
Phone: [phone]                           Great Britain
Email: (c/o Univ of Brighton) [e-mail]  or  [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sat Feb  6 17:08:04 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Eliot Moss)
Subject: Re: Adding other languages to GCC (was, using GCC for back-end)
Message-ID: <[e-mail]>
Keywords: modula, GCC
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
References: <[e-mail]> <[e-mail]>
Date: Fri, 5 Feb 1993 16:38:53 GMT
Approved: [e-mail]

The Modula-3 front end also generates trees. Because M3 allows arbitrary
use before definition, the front end is actually two pass, to resolve
identifier bindings properly. If other languages would benefit from such
two pass processing in the front end, they can use our code as a model
(once we release it :-) ....                Eliot
--
J. Eliot B. Moss, Associate Professor    Visiting Associate Professor
Department of Computer Science        School of Computer Science
Lederle Graduate Research Center    Carnegie Mellon University
University of Massachusetts        5000 Forbes Avenue
Amherst, MA  01003            Pittsburgh, PA  15213-3891
[phone], 545-1249 (fax)        [phone], 681-5739 (fax)
[e-mail]            [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sat Feb  6 17:10:25 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Paul B Hill)
Subject: Looking for ASN.1 compiler for MSDOS / MS Windows
Message-ID: <[e-mail]>
Keywords: question
Sender: [e-mail]
Organization: Massachusetts Institute of Technology
Date: Fri, 5 Feb 1993 17:03:54 GMT
Approved: [e-mail]

What products, (commercial, shareware. pd), are available to compile ASN.1
code for the PC environment?

A Novell marketing type told me that they were using an ASN compiler from
Watcom.  Watcom claims never to heard of the product. If you will mail me
a reply I will post a summary. If you know of a more appropriate place to
ask this question please advise me.

[e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sat Feb  6 17:12:09 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (David Chase)
Subject: re: Adding other languages to GCC
Message-ID: <[e-mail]>
Keywords: GCC
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]> <[e-mail]>
Date: Fri, 5 Feb 1993 19:17:43 GMT
Approved: [e-mail]

I studied this once, around about gcc 1.2x.  One caveat that RMS did not
provide is that if your language has substantially different features from
C -- for instance, nested functions, or garbage collection, or closures,
or continuations -- then the rest of the back-end may not "correctly"
generate the code that you want.  That is, it was designed (and so far,
tested) for languages like C.  Fortran shouldn't be hard to compile (once
you parse it, and never mind the IO libraries), and with a little hackery
Pascal and Modula-2 should also fall out.  However, using GCC as a backend
for Scheme might be a tall order, and it is my understanding that it has
taken a lot of work to make the optimizer in GCC GC-aware for Modula-3.

I once tried to write some documentation for the tree data structures.  It
is almost certainly obsolete now.  The trees were pretty easy to figure
out, but (another warning) watch out for those places where trees are NOT
used as the intermediate data structure (I recall that 1.x would generate
the function prologue and epilogue more or less directly without going
through the trees).  Perhaps this has been cleaned up in 2.x.

David
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sat Feb  6 17:13:02 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Bill Kalsow)
Subject: Re: Compiler construction in ... and OOD
Message-ID: <[e-mail]>
Keywords: OOP, modula
Sender: [e-mail]
Organization: DEC Systems Research Center
References:  <[e-mail]>
Date: Thu, 4 Feb 1993 16:46:46 GMT
Approved: [e-mail]

[e-mail] (Vivek Buzruk) writes:
> But the same article gave me some thoughts about considering object
> oriented design of a compiler.  Does anyone know about research done on
> this topic?  OR any practical compilers using this methodology, and how
> they do it?

The SRC Modula-3 compiler uses objects throughout the front-end.  Several
years ago I observed that the internals of most compilers are a mess and
wondered why.  My conjecture is that two factors contribute:

  1) Serious compilers have a long life-time.  Several programmers
     hack on the source.  The original authors are gone and their
     inspirations get muddled over time.  Of course, any long-lived
     program will suffer these problems -- not just compilers.

  2) Most compilers expose a large complicated data structure, usually a
     decorated syntax tree, with little or no access control or abstraction
     (e.g. GCC's tree.{def,h,c}).

I decided to attack the second problem.  I started building a compiler
where the front-end data structures were hidden whenever possible.  The
scanner is a single hand written module.  The parser is a simple recursive
descent parser that's distributed across many modules.  There's a separate
module for each language construct: ARRAY type, FOR statement, +
expression, ...  Each module is responsible for parsing, type checking,
answering queries, and emitting code for its construct.  Of course, the
glue that makes it possible is that each parser yields a tree node that's
a subtype of one of the four general classes: Stmt, Type, Expr, Value.
Every statement has a "type-check" and a "compile" method, but only
ForStmt knows that its node has "index-var", "from", "to", "step" and
"body" components.

I would say the results are mixed.  Instead of a few large modules, there
are about a hundred little ones.  What might be implemented as a CASE
statement with several labels sharing code turns into a method call with
less shared code.  On the plus side, clients almost always report bugs in
terms of a language construct (e.g "this IF statement doesn't work") not
in terms of a traditional compiler organization (e.g. "I think the type
checker is broken").  The most telling advantage remains to be seen.  How
well will the compiler survive its hackers over time?

If you're interested, the SRC Modula-3 compiler and its sources are
available for public FTP in /pub/DEC/Modula-3/release/* on
gatekeeper.dec.com.

  - Bill Kalsow
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sat Feb  6 17:20:40 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: Todd Jonker <[e-mail]>
Subject: Re: Compiler construction...
Message-ID: <[e-mail]>
Keywords: C++, OOP
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]> <[e-mail]>
Date: Fri, 5 Feb 1993 20:27:46 GMT
Approved: [e-mail]

[e-mail] (Vivek Buzruk) writes:
> [Is a] compiler..  a good application for O-O design?

Cliff Click writes:
> My research compiler is written entirely in C++ (except for the front-end
> parsing stuff).  I find the O-O issues immensely helpful.  I have class
> definitions for all the interesting internal data structures: hash tables,
> symbol tables, instructions, etc.  The complexity control C++ gives me is
> a BIG win.

I too am writing a compiler in C++, including the frontend.  Each AST node
is a class, with two main methods: Analyze and Emit.  These correspond to
two `passes' of a traditional compiler architecture.  I am often amazed at
how easily I can incrementally extend the language with new
syntax/semantics.  Just define a new class and write a couple routines.
Once the framework is in place, adding constructs is a piece of cake.

I am using my own parser-generator which constructs an AST node when a
production is matched.  Thus, the C-code that usually sits in the YACC
file is instead part of the class constructor methods.  This in turn keeps
my grammar description code very clean, and MUCH easier to create and
maintain that LEX/YACC.  Another big win.

[vivek:]
> Obviously one can not go away from traditional phase structured design
> to define the functionality of a compiler.

As I indicated above, in my design the various phases are replaced with
tree-walks performed via virtual function calls.

. . . Todd V. Jonker . . . . . Carnegie Mellon University . . .
. . . [e-mail] . . . Information Technology Center . . .
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sat Feb  6 17:44:11 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (David Keppel)
Subject: Re: Thompson's 2c vs. gcc
Message-ID: <[e-mail]>
Keywords: architecture, GCC
Sender: [e-mail]
Organization: Computer Science & Engineering, U. of Washington, Seattle
References: <[e-mail]> <[e-mail]>
Date: Fri, 5 Feb 1993 20:53:40 GMT
Approved: [e-mail]

>>>[Comparison of output code from GCC, lcc, and Plan 9 C compilers.]

Preston Briggs writes:
>>[GCC 1.35 didn't generate very good MIPS code.  It's better now.]

[e-mail] (Joe Buck):
>[Gcc did not have an instruction scheduler and did not fill delayed
> branch slots.  Adding them makes about a 30% difference on SPARCs.]

I believe that GCC ports rely on the MIPS assembler.  The MIPS assembler
by default provides a virtual machine without delay slots then rearranges
instructions to fill the real delay slots.  The assembler can be told to
reveal the underlying machine to allow explicit delay slot filling.

The current GCC produces code both ways.  It is thus better able to take
advantage of delay slot filling.  But even the older ports did some just
by virtue of the assembler.

I do agree that GCC produces better quality MIPS code than it did a few
years ago.

    ;-D on  ( Quality time with your compiler )  Pardo
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sat Feb  6 17:45:09 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Vern Paxson)
Subject: Re: yytext in POSIX lex
Message-ID: <[e-mail]>
Keywords: lex, design
Sender: [e-mail]
Organization: Lawrence Berkeley Laboratory, Berkeley CA
References: <[e-mail]>
Date: Fri, 5 Feb 1993 21:26:32 GMT
Approved: [e-mail]

> [Of the two major implementations of lex, AT&T lex makes yytext an array
> and flex makes it a pointer ....  You have to try fairly hard to tell
> the difference, e.g. use sizeof(yytext). -John]

One major problem is that if another source file declares yytext as

    extern char yytext[];

and the lex-generated code declares it as

    extern char *yytext;

(or vice versa), then on systems without type-safe linkage the program may
link without any warning or error, but crash at run-time when yytext is
accessed.  It was this argument that led to the (crufty) adoption of
%pointer and %array.

        Vern

    Vern Paxson                [e-mail]
    Systems Engineering                ucbvax!ee.lbl.gov!vern
    Lawrence Berkeley Laboratory        [phone]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sat Feb  6 17:47:49 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail]
Subject: Re: Thompson's 2c vs. gcc
Message-ID: <[e-mail]>
Keywords: architecture, GCC
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]> <[e-mail]>
Date: Fri, 5 Feb 1993 23:39:31 GMT
Approved: [e-mail]


Joe Buck writes:
| It wasn't just that [MIPS gcc 1.x] was not well tuned.  It did not have an
| instruction scheduler and could not fill delayed branch slots.  gcc-2 does
| both.  I understand that this makes a difference of about 30% on the
| Sparc; the number is probably similar on the MIPS.  gcc-1 did a good job
| on the CISC architectures (Vax and 680x0) it was initially designed for.

Actually the number is not similar on the MIPS.  The reason is that the
MIPS assembler does low level instruction scheduling (though I don't
recall whether gcc 1.35 and such passed -O to the assembler, but I think
it did).  I did put in scheduling and branch delay slot filling support in
Gcc 2.x for the MIPS (because for the OSF/1 Pmax reference platform, we
used GAS as the assembler, and it doesn't do instruction scheduling).

One big win that Gcc 2.xx has (and later versions of gcc-osf-1.39 if you
used -O2) is that it uses a constant frame (providing you don't use
alloca), rather than continually pushing and popping items from the stack
pointer, and eliminating the frame pointer in most cases, freeing up
another saved register.  There were other places where it definately
needed a tuneup, and hopefully it is reasonably tuned now.
--
Michael Meissner    email: [e-mail]        phone: [phone]
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sat Feb  6 17:50:38 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Ozan Yigit)
Subject: fast compilers [Re: Thompson's 2c vs. gcc]
Message-ID: <[e-mail]>
Keywords: performance, comment
Sender: [e-mail]
Organization: York U. Student Information Systems Project
References: <[e-mail]> <[e-mail]>
Date: Sat, 6 Feb 1993 05:56:08 GMT
Approved: [e-mail]


Michael John Haertel writes:
                ...
   Thompson's claim that 2c typically compiles in 50% of the time gcc takes
   is probably an understatement, in fact.  2c is the most nearly I/O-bound
   compiler I've ever used.

I have not used 2c, but I have used Redelmeier's RCC, which is a very
fast non-optimizing ansi-c compiler. Last time I tested its speed, it
was able to compile [on a 68020 sun] gcc at around 30% of the time it
would take gcc to compile itself without -O.

Is there any interest in very fast compilers that sacrifice some code
compactness and speed [rcc-compiled gcc is ~30% slower than the usual
gcc compiled with gcc -O] for sheer compilation speed? Does the speed
of compilation have any impact on large-scale code development? [I do
think so, but I am biased. ;-)]

oz
[Microsoft makes a fair amount of money selling Quick C, which compiles a
lot faster than regular MS C and produces worse code.  Turbo C also leapt
into the market because it compiles so fast, using simple techniques like
buffering include files in RAM. -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sun Feb  7 17:27:45 EST 1993
Xref: iecc comp.lang.lisp:6708 comp.lang.scheme:4952 comp.compilers:4231
Newsgroups: comp.lang.lisp,comp.lang.scheme,comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Tanel Tammet)
Subject: A new Scheme->C compiler HOBBIT for SCM
Message-ID: <[e-mail]>
Keywords: Scheme, FTP
Sender: [e-mail]
Organization: Dept. of CS, Chalmers, Sweden
Date: Sun, 7 Feb 1993 10:43:19 GMT
Approved: [e-mail]


This message announces the availability of a new Scheme->C compiler hobbit
release 1.

Hobbit works together with the Scheme interpreter scm developed by
A.Jaffer, treating scm as a C library and providing integration of
compiled functions into scm as new primitives. Hobbit release 1 works
together with the scm release scm4b3. Future releases of scm and hobbit
will be coordinated. A. Jaffer has helped with suggestions for better
integration of hobbit-compiled functions into scm and coordinating scm and
hobbit releases.

Hobbit release 1 imposes strong restrictions on the higher-order features
of Scheme. For example, it does not support continuations.

The main aim of hobbit is to produce maximally fast C programs which would
retain most of the original Scheme program structure, making the output C
program readable and modifiable. Hobbit is written in Scheme and is able
to self-compile.

Hobbit release 1 consists of three files, approximately 160K altogether:

hobbit.scm   -  the compiler
hobbit.doc   -  documentation
hobbit.tms   -  terms of usage, copying, redistribution

Hobbit can be obtained via FTP from the following servers:

altdorf.ai.mit.edu:archive/scm/hobbit1.tar.Z
prep.ai.mit.edu:pub/gnu/jacal/hobbit1.tar.Z
nexus.yorku.ca:pub/scheme/new/hobbit1.tar.Z

Remember to use binary mode when transferring the files.  A sample ftp
session:

  ftp altdorf.ai.mit.edu [18.43.0.246] (anonymous)
  bin
  cd archive/scm
  get hobbit1.tar.Z

The author can be reached by email as [e-mail] and by
snail-mail as

Tanel Tammet, Department of Computer Sciences,
Chalmers University of Technology, S-41296 Go"teborg, Sweden.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sun Feb  7 17:29:09 EST 1993
Xref: iecc comp.compilers:4232 misc.jobs.offered:23470
Newsgroups: comp.compilers,misc.jobs.offered
Path: iecc!compilers-sender
From: [e-mail]
Subject: Compiler positions available for week ending February 7
Message-ID: <[e-mail]>
Keywords: jobs
Sender: [e-mail]
Organization: Compilers Central
Date: Sun, 7 Feb 1993 13:00:03 GMT
Approved: [e-mail]

This is a digest of ``help wanted'' and ``position available'' messages
received at comp.compilers during the preceding week.  Messages must
advertise a position having something to do with compilers and must also
conform to the guidelines periodically posted in misc.jobs.offered.  To
respond to a job offer, send mail to the author of the message.  To submit
a message, mail it to [e-mail].


-------------------------------

From: [e-mail] (Mike Ross)
Subject: Compiler Developer Opening
Organization: Metaware Incorporated, Santa Cruz, CA
Date: Tue, 2 Feb 93 18:00:03 GMT

Software Engineers
To build compilers, libraries, linkers, debuggers, programming
environments, and other development tools.  Requires C/C++, DOS, and UNIX
background. MS/Windows experience preferred. Strong programming skills,
knowledge of RISC and CISC architectures required. Prefer some experience
with Intel i860 code generator. Must be able to work on compiler
front-ends, optimizer, or code generators.  This is not an entry level
position. MS Computer Science or equivalent experience required.

Reply by e-mail to [e-mail], or
fax to [phone], Attn Personnel

-------------------------------

Organization: Scientific Placement, Inc.
From: [e-mail] (BGE)
Date: Wed, 3 Feb 1993 16:13:59 CST
Subject: CA-Compiler Engrs

Job Title & Location

CA-Compiler Engrs
Software engineers needed by Northern California in the compiler and
tools/libraries area. Skills desired include:
* Experience with compilers, including front ends, optimizers and code
generators
* Strong programming skills and knowledge of RISC and CISC architecture
* C, C++, DOS Unix and Windows
* Experience building development tools.

A similar position is also open in Texas.

Please send resume with salary info to:

Beth Evancheck
Scientific Placement, Inc., Box 71, San Ramon, CA 94583
510-733-6168  Fax: [phone]
Internet: [e-mail]; Compuserve: 71250,3001; AppleLink: Scientific;
Genie: D.SMALL6; AOL: DaveSmall; BIX: Scientific

Formats: Ascii text via Email preferred. Macintosh or PC Word processor
formats are OK via Email (binhex). Please do not send LaTex or Postscript.
Fax is discouraged unless Fine Setting on your fax machine is used (to
enable OCR scanning). US Mail on 3.5 inch diskette is OK too.

Immigration status: You must be a U.S. or Canadian Citizen or have a
Permanent Residence Visa.

New graduates: Employers utilize the college placement offices to hire new
graduates. They do not employ recruiting firms for this purpose. We are
unable to assist recent graduates.


Beth Evancheck
Scientific Placement, Inc., P.O. Box 71, San Ramon, CA 94583
510-733-6168
[e-mail] -or- [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sun Feb  7 17:37:21 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Peter Su)
Subject: Re: fast compilers [Re: Thompson's 2c vs. gcc]
Message-ID: <[e-mail]>
Keywords: performance
Sender: [e-mail]
Organization: Duke University CS Dept., Durham, NC
References: <[e-mail]> <[e-mail]>
Date: Sun, 7 Feb 1993 17:16:31 GMT
Approved: [e-mail]

[e-mail] (Ozan Yigit) writes:

   Is there any interest in very fast compilers that sacrifice some code
   compactness and speed ... for sheer compilation speed?
   [Microsoft makes a fair amount of money selling Quick C, which compiles a
   lot faster than regular MS C and produces worse code. ... . -John]

These systems, and others like Think C on the Mac also depend on a very
fast link phase for their quick turnaround. I think they link mostly in
memory and with indirect jump tables and whatnot.

There was an SP&E paper on an incremental linker a while back that said it
increased UNIX compile cycles by huge factors.

Pete
--
Department of Computer Science, Duke University, Durham, NC 27706
Internet:    [e-mail]
UUCP:        mcnc!duke!psu
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sun Feb  7 17:38:35 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Eliot Moss)
Subject: Re: Adding other languages to GCC
Message-ID: <[e-mail]>
Keywords: GCC, design
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
References: <[e-mail]> <[e-mail]>
Date: Sun, 7 Feb 1993 17:55:38 GMT
Approved: [e-mail]

[e-mail] (David Chase) said:
> I studied this once, around about gcc 1.2x.  One caveat that RMS did
> not provide is that if your language has substantially different
> features from C -- for instance, nested functions, or garbage
> collection, or closures, or continuations -- then the rest of the
> back-end may not "correctly" generate the code that you want.  That is,
> it was designed (and so far, tested) for languages like C.

[ etc. ]

While David is basically right, nested function support (static chains)
came with gcc 2.0 and higher (it's in gcc's extensions to C). Also, our
Modula-3 work addresses the issue of garbage collection. Full closures and
continuations would still be a problem, and the orientation is towards
static typing rather than dynamic/tagged languages such as LISP, Scheme,
ML, etc.

Adding support for exception handling and gc did involve some subtleties,
but my take on it is that the coding was not that hard. What was hard was
coming to the proper understand of what needed to be done. The incremental
change to the back end is not all that large. Amer Diwan, who did the
work, can expand on this point I'm sure. There is a group of us trying to
work out language independent expcetion handling support from the tree
stage on, and the main challenges are doing it across language,
architectures, and operating systems, but I think we've basically got it
in hand.
--
J. Eliot B. Moss, Associate Professor    Visiting Associate Professor
Department of Computer Science        School of Computer Science
Lederle Graduate Research Center    Carnegie Mellon University
University of Massachusetts        5000 Forbes Avenue
Amherst, MA  01003            Pittsburgh, PA  15213-3891
[phone], 545-1249 (fax)        [phone], 681-5739 (fax)
[e-mail]            [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  8 14:05:29 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: josef <[e-mail]>
Subject: lcc backend
Message-ID: <[e-mail]>
Keywords: tools, question, C
Sender: [e-mail]
Organization: Compilers Central
Date: Mon, 8 Feb 1993 09:18:32 GMT
Approved: [e-mail]

Hi,

I just fetched lcc from princeton. I'd like to use it to generate code for
a 68010 and was wondering if anyone has a backend to do so.  Altough I'm
only a private user (I have a Torch XXX with a 68010 and 1MB at home), I
don't think I'd qualify for a free backend B-{(

Gcc probably won't run on my system (UNIX only leaves some 600K for user
programs).

Josef
---
Josef Moellers        | c/o Siemens Nixdorf Informationssysteme AG
USA: [e-mail]    | Abt. STO-XS 113       | Riemekestrasse
!USA: [e-mail]    | Phone: [phone] | D-4790 Paderborn
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  8 14:07:42 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Clyde Smith-Stubbs)
Subject: Re: PIC 16Cxx Compilers
Message-ID: <[e-mail]>
Keywords: tools
Sender: [e-mail]
Organization: HI-TECH Software, Brisbane, QLD, Australia.
References: <[e-mail]> <[e-mail]>
Date: Mon, 8 Feb 1993 00:50:05 GMT
Approved: [e-mail]

[e-mail] (Charles Manning) writes:

>I've had a bit of experience with PICs and HLL's on other
>microcontrollers.  Sorry, but I don't think HLL's are feasible for PIC
>16Cxx family.

I don't agree - I have looked briefly at the PIC and believe that it is
just as suitable as the 6805 as the target of a C compiler.  We recently
completed a C compiler for the 6805 that implements full ISO Standard C,
with the only restrictions being on recursion and re-entrancy, forced by
the non-addressability and small size of the stack.

This limitation is not important for embedded applications, and in all
other respects the compiler implements Standard C (non-hosted), including
longs, floats and printf. Code quality (== density) is quite close to hand
written assembler, with the advantage that on the odd occasion that
something like floating point is needed, it is available in the library.

At the present time I don't believe a compiler for the PIC chips exists,
but we are considering doing one. There is an astonishly high level of
demand for the 6805 compiler, but I am not sure how widely the PIC chips
are used.

>Even shoehorning C into a 8051 has taken the industry quite a while to get
>anywhere near to useful.

Yes, it took a while, but current 8051 compilers are very useful. The 8051
is complicated by having no less than seven (7!) distinct address spaces.

By way of example of the practicality of C on an 8051, one of our
customers recently completed a GPS receiver using an 8051, with 99% of the
code written in C. It uses trig functions intensively, and is claimed to
outperform a competitive GPS receiver using an 8086 processor.

Using a high level language on a low-level embedded processor makes a lot
of sense, especially when the code will need to be modified later, or the
number of units to be produced is small. There also seems to be a tendency
for engineers to want to use C because they know it, and don't want or
can't afford the time to learn to program a new chip at assembler level.

Given the quality of compilers now available for these chips, this is a
very realistic approach.
--
 Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: [phone]
 [e-mail]      | P.O. Box 103, Alderley, | Fax:   [phone]
 ...!nwnexus!hitech!clyde | QLD, 4051, AUSTRALIA.   | BBS:   [phone]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  8 14:08:37 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: Mirek Benes <[e-mail]>
Subject: P-code
Message-ID: <[e-mail]>
Keywords: question, Pascal
Sender: [e-mail]
Organization: Compilers Central
Date: Mon, 8 Feb 1993 14:49:39 GMT
Approved: [e-mail]

Is there any ftp-accessible site with the P-code description?

      Mirek Benes
--
Technical University of Brno           E-mail: [e-mail]
Faculty of Electrical Engineering      Phone: [phone] / 238
Department of Computer Science & Engineering
Bozetechova 2, 612 66 Brno, Czech rep. FAX:   [phone]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  8 15:55:25 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Craig Burley)
Subject: Re: Adding other languages to GCC (was, using GCC for back-end)
Message-ID: <[e-mail]>
Keywords: GCC, Fortran
Sender: [e-mail]
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
References: <[e-mail]> <[e-mail]>
Date: Mon, 8 Feb 1993 18:44:31 GMT
Approved: [e-mail]

[e-mail] (Eliot Moss) writes:

   The Modula-3 front end also generates trees. Because M3 allows arbitrary
   use before definition, the front end is actually two pass, to resolve
   identifier bindings properly. If other languages would benefit from such
   two pass processing in the front end, they can use our code as a model
   (once we release it :-) ....                Eliot

The GNU Fortran (g77) front end isn't really designed as a two-pass front
end, because a model whereby compilation of FORTRAN 77 to assembler code
is possible in one pass is easy to design.

However, enter the gcc back end and the procedure calling interface, and
it made sense to add what amounts to a second pass to the g77 front end to
reduce the amount of redevelopment needed in the back end, so I did this.

What now happens is that while g77 is recognizing statements and building
its own internal trees describing the expressions in the statements,
instead of directly calling on the back end to emit the statements, it
saves the statements until it reaches the end of the program unit.  At
that point, the end-transition action happens, which makes the "final
decisions" about what all the symbols actually are, and _then_ the list of
saved statements (and info on all the symbols) is revisited to call the
back end.  In other words, the back end is unaware that anything is going
on until after the front end sees the END statement.  This isn't ideal or
even strictly necessary, especially given that the back end currently
saves up all the RTL anyway, but it sure made it easier to get g77 up and
running without my needing to become an expert on the back end.

Before the change to two passes, made partway through the process of
integrating the front end with the back end (85% of the front end having
been coded by the time integration started, don't ask why :-), I'd already
written some code to revise the RTL in cases like this:

    ASSIGN 10 TO I
    ...
10    FORMAT(...)

Most ASSIGN statements refer to labels for executable statements, but they
may refer to FORMAT statements instead, and it's the label definition that
chooses.  The implementation at the assembler level can be made
independent of the label type, but with layers of back end code (where
info on whether a reference is to a procedure label or a variable is kept)
on top of the conceptual assembler level, g77 had to make a choice.  When
g77 saw the ASSIGN statement above, it assumed that label 10 was
executable (as far as back-end stuff goes) and acted accordingly.  Then,
when it saw the FORMAT, g77 had special code to revisit the RTL, search
for references to the label, and change them so they'd work for a FORMAT
label.  (Needless to say, it annoyed me that front-end code had to muck
with the RTL, so I was happy to delete this code when changing g77 to call
on the back end only after a complete pass over the source program unit.)

If you're curious about what made 2-pass a necessity, here's a
straightforward example.  g77 is designed (for now, anyway) to make object
files compatible with f2c+gcc.  The procedure calling interface defined by
f2c passes CHARACTER variables by appending pass-by-value lengths to the
list of arguments for each CHARACTER variable in the calling sequence.

For example, given

    CHARACTER A*5, B*10, C*15
    INTEGER I(10)
    CALL FOO (A, I, B, C)

FOO is called like this (in C):

    FOO (&A, &I, &B, &C, 5, 10, 15);

That is, the lengths for A, B, and C are passed to FOO.  Now, let's look
at the first several lines of a sample subroutine:

    SUBROUTINE BAR (A, I, B, C)
    CHARACTE A*(*), B*10, C*(*)
    INTEGER I(10)
C
    I(1) = 5

At this point, if g77 was 1-pass, it'd need to tell the back end about
function BAR so it could start emitting executable code (for the I(1) = 5
line), but what calling sequence would it give for BAR?  Answer: it
couldn't give a definitive calling sequence, because if, say, the next
executable line is

    C = A // B

then the calling sequence for BAR would be the same as for FOO in the
previous example (though B's length argument would be ignored, since BAR
declares its own length for B), whereas if the next executable line is

    C = A // B()

then B is a CHARACTER _function_, not _variable_, and therefore no length
parameter for B is passed, meaning BAR has, in C terms, six arguments
instead of seven.  (Of course, the caller has to know this too, but that's
not important here.)

There are other examples like this, some real hairy (how to handle
alternate ENTRY points in one pass, especially given the facts that
discovery of alternate entries can happen long into executable code and
that the back end doesn't understand alternate entries yet) and some just
annoying to handle properly in the back end (like how variable/ array
"static" initialization can be the last thing prior to an END statement,
and after lots of uses of the variable/array).

So while most of the g77 front end still is designed for one-pass use, the
parts that interface to the back end are build-time switchable between
one/two pass, and for building g77 itself, two passes always are used.
(The front end is designed to be fairly independent of the back end used,
or even of whether it is part of a compiler vs., say, part of a
source-code checker or transformer.  It doesn't save whitespace info in
its internal trees, so it's not completely flexible. :-)

A truly language-independent back end would not have these problems, I
guess, and the gcc back end definitely was designed from C's point of
view.  But it was nowhere near as hard to interface and otherwise deal
with as I expected, based on my other experiences with compiler internals,
and certainly the source code didn't cost me anything (plug, plug :-).
--
James Craig Burley, Software Craftsperson    [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb  8 16:23:58 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Stefan Vaillant)
Subject: Re: Compiler construction in C++ and OOD
Message-ID: <[e-mail]>
Keywords: OOP, C++
Sender: [e-mail]
Organization: Rechnerbetrieb Informatik - RWTH Aachen
References: <[e-mail]>
Date: Mon, 8 Feb 1993 18:22:36 GMT
Approved: [e-mail]

[e-mail] (Vivek Buzruk) writes:
>I will be happy if any one tells whether any complete compiler is written
>in C++ either. Also in what way C++ is used, only as a better C or flavor
>of OOD.

Sather, an Eiffel dialect, is implemented with object-orientation in mind.
The compiler is written in Sather (of course), but IMHO it is worth having
a look at it, even if you are interesseted in C++.

The compiler has the following structure: The front-end is written in
yacc. The action-parts construct an abstract syntax tree. Each node of
this tree is an object and has an individual interface.  For example, the
node which represents the IF-statement has the following attributes:

class COND_STMTOB is
   test:      EXPREOB;   -- reference to expression node
   then_part: LST_STMTOB; -- List of statements
   elsif_part:LST_STMTOB;
   else_part: LST_STMTOB;
   ...
end;

Every node (or object) has some methods for doing a semantic check and for
generating code.  (This is not quite correct. I had only a quick look at
the source
 one year ago.)

You can obtain sather (incl. source code of the compiler) from
icsi-ftp.berkeley.edu.

IMHO this is not totally new, but clean and easy to understand.

You might also have a look at
  - the book of Rumbaugh et. all. "Object Oriented Modeling and Design".
    They have some examples with syntax trees representing
    expressions.
  - the Eiffel scanner/parser library.

---------------
Stefan Vaillant
[e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 11 15:39:47 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail]
Subject: Iburg now available
Message-ID: <[e-mail]>
Keywords: tools, parse, FTP
Sender: [e-mail]
Organization: Compilers Central
Date: Wed, 10 Feb 1993 04:42:23 GMT
Approved: [e-mail]

Iburg, a program that generates a fast tree parser, is now available.  It
is compatible with Burg. Both programs accept a cost-augmented tree
grammar and emit a C program that discovers an optimal parse of trees in
the language described by the grammar. They have been used to construct
fast optimal instruction selectors for use in code generation.

Burg uses BURS; Iburg's matchers do dynamic programming at compile time.
Its matchers are slower but can be useful during development and for
teaching. The generated code is easy to read and to debug. It mirrors the
BURS specification in the same way that the code for a recursive-descent
parser mirrors its LL(1) grammar. Iburg has been used in compiler courses
and is described in the forthcoming LOPLAS paper "Engineering a simple,
efficient code generator generator."

Iburg and its documentation are available via anonymous ftp from
ftp.cs.princeton.edu (128.112.152.13) in pub/iburg.tar.Z.

Christopher W. Fraser, AT&T Bell Laboratories, [e-mail]
David R. Hanson, Princeton University, [e-mail]
Todd A. Proebsting, University of Arizona, [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 11 15:40:40 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail]
Subject: TMS7000 C compiler wanted
Message-ID: <[e-mail]>
Keywords: C, question
Sender: [e-mail]
Organization: North Dakota Higher Education Computer Network
Date: Wed, 10 Feb 1993 16:27:38 GMT
Approved: [e-mail]

I'm looking or a compiler for the IBM PC that will compile a C program to a
TMS7000 format....  Does anyone have something like this?  Does it even
exist?? Where can I get it./...  Thanks
                          Respond be e-mail  Thank YOU!

[e-mail]
[e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 11 15:41:44 EST 1993
Xref: iecc comp.arch:26023 comp.parallel:5143 comp.compilers:4242
Newsgroups: comp.arch,comp.parallel,comp.compilers
Path: iecc!compilers-sender
From: Lori Lynn Avirett-Mackenzie <[e-mail]>
Subject: MIT Summer Course Announcement
Message-ID: <[e-mail]>
Keywords: dataflow, courses
Sender: [e-mail]
Organization: MIT Lab for Computer Science, Cambridge, Mass.
Date: Wed, 10 Feb 1993 18:55:02 GMT
Approved: [e-mail]

---------------- COURSE ANNOUNCEMENT: PLEASE POST  ----------------

Parallel Computing: Dataflow Architectures and Languages
  (with Programming Laboratory on Monsoon Dataflow Machines)

Monday, August 2 through Friday, August 6, 1993

Massachusetts Institute of Technology
Summer Session Program 6.83s
                 ----------------
                  Course Abstract

The only thing holding back the widespread use of parallel computers is
software. Most of the difficulty of parallel programming is attributable
to our von Neumann legacy - imperative languages and sequential processor
architectures.  By switching to functional languages, one may start
writing parallel programs without even realizing it.  Dataflow
architectures further simplify the compilation problem by providing cheap
synchronization.

A central theme of the course is Id, an implicit parallel language.  The
participant will get a chance to evaluate via laboratory experience
whether Id is a fad or a real alternative to standard imperative languages
extended for parallelism, such as C with threads, Multi-Lisp, and Fortran
9X.  The participant will also get an opportunity to compare Id to purely
functional languages.  Compilation of Id for both dataflow and von Neumann
machines will be discussed at length.

The other theme of the course is dataflow architectures. We will discuss
why these architectures are better building blocks for parallel computers
than modern RISC architectures. Today's dataflow architectures borrow much
from traditional architectures; however, they take the most aggressive
approach to multi-threading, that is, rapid context switching to tolerate
long memory latencies and frequent synchronization waits.  The participant
will get hands-on experience on Monsoon dataflow machines produced by
Motorola, and a chance to conduct experiments on emulators of other
dataflow machines.  We will also discuss several supercomputer-class
dataflow machines that are currently under construction.

               ----------------
               Course Outline:

Implicit Parallel Programming:
  Programming with higher-order functions and non-strict data structures;
  Rewrite rules and reduction; Algebraic and abstract data types; Arrays
  and I-structures; M-structures and non-determinism.

Architectures:
  Fundamental issues in high-performance parallel architectures; Static and
  dynamic dataflow machines; Split phase memory references; I-structure
  memory; Multi-threaded architectures; Hybrid von Neumann-dataflow
  architectures.

Compilation:
  Dataflow program graphs; Translation to dataflow graphs; Lambda- lifting
  and supercombinators; Loop, array and procedure call optimization.

Resource management and performance:
  Resource managers; Experimental results on MIT dataflow machines.

               ----------------
Laboratory:
  Morning and afternoon lecture sessions will be followed by late-
  afternoon laboratory sessions in writing, debugging, running and
  analyzing the performance of Id programs on a Monsoon dataflow machine
  and on software emulators.  Experienced assistants will be available in
  the laboratory.
               ----------------
The Target Audience:
  Understanding dataflow principles can benefit users and designers of all
  parallel systems, i.e., parallel languages, architectures, compilers and
  resource managers.  In addition to computer scientists and electrical
  engineers, the course is also useful for people working in scientific
  programming, signal processing, real-time computing and artificial
  intelligence.

Staff:
  The program will be taught by professor Arvind of the MIT Department of
  Electrical Engineering and Computer Science.

----------------
FOR MORE INFORMATION:

For a more detailed brochure (including application forms and
information about housing and fees), please contact:

    Lori Avirett-Mackenzie
    Rm 209
    MIT Laboratory for Computer Science
    545 Technology Square, Cambridge, MA 02139, USA

    [e-mail]              Tel: [phone]
                                      Fax: [phone]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 11 15:43:33 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Sandeep Kumar)
Subject: Data flow analysis tool wanted
Message-ID: <[e-mail]>
Keywords: dataflow, question
Sender: [e-mail]
Organization: NCSU, Raleigh
Date: Wed, 10 Feb 1993 23:19:39 GMT
Approved: [e-mail]

Hello,

I am looking for a commercial/educational/research Tool for doing
Data Flow Analysis for a given Abstract Syntax tree. More
specifically for languages like C/C++.  I would appreciate any such
info. mailed to me.  Any pointers in this direction are most welcome.

Thanks in advance.
Sandeep.
-----
Email: [e-mail]

Sandeep Kumar
Dept of ECE, Box 7911,
NCSU, Raleigh, NC-27606
(O) 919 515 3861  (R) 919 859 4178
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 11 15:44:55 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Joachim Schrod)
Subject: Re: fast compilers [Re: Thompson's 2c vs. gcc]
Message-ID: <[e-mail]>
Keywords: performance, linker, comment
Sender: [e-mail]
Organization: TH Darmstadt, FG Systemprogrammierung
References: <[e-mail]> <[e-mail]>
Date: Thu, 11 Feb 1993 09:40:22 GMT
Approved: [e-mail]

[e-mail] (Peter Su) writes:
> There was an SP&E paper on an incremental linker a while back that said it
> increased UNIX compile cycles by huge factors.

I think you meant the following TOPLAS article. (I just had the reference
handy :)

@article{comp:quong:incremental-linking,
 author = {Russel W. Quong and Mark A. Linton},
 title = {Linking Programs Incrementally},
 journal = toplas,
 volume = 13,
 number = 1,
 month = jan,
 year = 1991,
 pages = {1-20},
 annote = {Describes an in-place incremental linking done by a
    daemon in the background. Needs {\it lots\/} of main memory. Linking
    times are proportional to the size of the changed modules, not to the
    size of the executable (as usual).}
}

Joachim
--
Joachim Schrod            Email: [e-mail]
Computer Science Department
Technical University of Darmstadt, Germany
[This came up in compilers a few years ago.  Apparently it works great but
never made it into the Unix mainstream. -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 11 15:45:48 EST 1993
Xref: iecc comp.compilers:4245 comp.lang.c:40803 comp.unix.questions:33147
Newsgroups: comp.compilers,comp.lang.c,comp.unix.questions
Path: iecc!compilers-sender
From: [e-mail] (Curtis Ide)
Subject: Third Party ANSI C Compiler for Amdahl UTS
Message-ID: <[e-mail]>
Summary: Looking for third party ANSI C compiler, debugger for Amdahl UTS
Keywords: C, debug, question
Sender: [e-mail]
Organization: AC Nielsen Co., Bannockburn IL
Date: Thu, 11 Feb 1993 15:45:02 GMT
Approved: [e-mail]

Does any one know of any third-party or aftermarket ANSI C Language
compilers and symbolic debuggers which support Amdahl UTS?  Evidently the
latests versions of gcc have dropped support for UTS.

Please respond via e-mail to:    (I do not read this news group regularly)
    [e-mail]

Thanks in advance,
Curtis Ide
Lead Engineer
AC Nielsen
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 16 11:12:19 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail]
Subject: HELP: filters for word processor
Message-ID: <[e-mail]>
Keywords: tools, question
Sender: [e-mail]
Organization: Compilers Central
Date: Thu, 11 Feb 1993 22:40:08 GMT
Approved: [e-mail]

I wrote a filter program translating documents from FrameMaker to
BBN/Slate in the language Perl. The program works fine and can translate
most media types (include graphics) now. I am very interested to know if
there is someone else working in translating document and data formats.
What language and technique are they using? Are there any articles or
technical reports available?

I am very appreciative of any help.

Amy
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 16 11:16:25 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Sriram Srinivasah)
Subject: Info on Unix based interactive profilers
Message-ID: <[e-mail]>
Keywords: tools, question, performance
Sender: [e-mail]
Organization: Teknekron Communications, Inc
Date: Fri, 12 Feb 1993 01:50:57 GMT
Approved: [e-mail]

I posted this on comp.unix.wizards but got no response.

For some time I have toyed with the idea of writing an interactive
profiler for Unix. That is, instead of running gprof after the program has
finished running, I'd like to set breakpoints and analyze hotspots
interactively.

1. Does such a beast exist already ?

2. If not, why not? Am I missing something that makes it technically
   infeasible on Unix ?

3. Can you point out some references on profilers, and if possible, those
   that specifically talk about Unix?

Thanx a lot.

Sriram
([e-mail])
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 16 11:17:48 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Terence J Parr)
Subject: To the users of PCCTS
Message-ID: <[e-mail]>
Keywords: tools, question, parse
Sender: [e-mail]
Organization: Compilers Central
Date: Fri, 12 Feb 1993 02:35:06 GMT
Approved: [e-mail]

In order to help us improve PCCTS, we would like to obtain working sample
grammars from as many users as possible.  We are not interested in seeing
your proprietary PCCTS grammars, but just the structural properties of
real PCCTS grammars.  We have included a simple C program that will
extract this information from your PCCTS grammars.

For each grammar, please send email to [e-mail] with the
Subject line:

Subject: sample

The email should contain:

[1]    A phrase describing what the grammar is used for, e.g.,
    "Database query language", "Fortran cross referencer", etc.

[2]    Your name, as you would like it to appear in acknowledgements
    in papers using statistics partly derived from you grammar.
    If you would prefer not to be listed as a contributor (i.e.,
    to avoid any implication that you endorse our research),
    please indicate this by saying "No acknowledgement".

[3]    Your stripped grammar.  The stripped grammar is produced by
    first using "antlr -p" to generate a version of your grammar
    without actions.  That output is then filtered by the
    following C program, which will convert all terminal and
    nonterminal names into generic names.  Although we would
    accept your original grammar, these two simple transformations
    allow you to send us the information we want without
    compromising the privacy of your work.

---- C program to rename grammar terminals and nonterminals ----
/* Input:  a grammar processed by "antlr -p"
 * Output: grammar with all symbols renamed generically
 */
#include <stdio.h>
#include <ctype.h>

#define MAX_ATOM_SIZE    1025
#define MAX_NEWID_SIZE    16

#define TOKEN    1
#define RULE    2
#define Eof        3

#define RETURN(_t)    {token = _t; return;}

typedef struct _map {
            char *id;
            char newid[MAX_NEWID_SIZE];
            struct _map *next;
        } map;

static map *mapping = NULL;
static int c;
static int token;
static char lexbuf[MAX_ATOM_SIZE];

/* say malloc is 'char *' as some C compilers don't do 'void *' */
extern char *malloc();

static char *mapid();
static map *new_mapping_entry();
static char *newid();
static void lex();

main(argc, argv)
int argc;
char **argv;
{
    if (argc != 1) {
        fprintf(stderr,
            "Usage: %s <action_free_grammar >renamed_grammar\n",
            argv[0]);
        exit(1);
    }

    c = getchar();
    lex();

    while ( token != Eof )
    {
        printf(" %s\n", mapid(&(lexbuf[0])));
        lex();
    }
    putchar('\n');
    return(0);
}

static void
lex()
{
    char *p;

try_again:

    while ( isspace(c) ) { c = getchar(); }

    lexbuf[0] = '\0';
    if ( c == EOF ) RETURN(Eof);

    if ( c=='"' )
    {
        p = &(lexbuf[0]);
        *p++ = c;
        c = getchar();
        while ( p<&lexbuf[MAX_ATOM_SIZE-2] )
        {
            if ( c=='"' ) {*p++ = '"'; c = getchar(); break;}
            if ( c=='\\' )
            {
                *p++ = c;
                c = getchar();
            }
            *p++ = c;
            c = getchar();
        }
        *p = '\0';
        RETURN(TOKEN);
    }
    else if ( islower(c) || isupper(c) || c=='_' )
    {
        for (p=&(lexbuf[0]); !isspace(c); c=getchar())
        {
            *p++ = c;
        }
        *p = '\0';
        if ( islower(lexbuf[0]) ) {RETURN(RULE);}
        else RETURN(TOKEN);
    }
    else
    {
        printf(" %c", c);
        c = getchar();
        goto try_again;
    }
}

/* if id is not already defined, create a new id for it and store in
 * 'mapping' return newid field of (possibly new) entry for id
 */
static char *
mapid(id)
char *id;
{
    map *p;
    char *prefix;

    /* is 'id' in 'mapping' already? */
    for (p=mapping; p!=NULL && strcmp(p->id, id)!=0; p=p->next)
    {
        ;
    }
    if ( p == NULL )    /* new mapping? */
    {
        p = new_mapping_entry(id);
        p->next = mapping;
        mapping = p;
        if ( islower(id[0]) ) prefix = "n";
        else prefix = "T";
        strcpy(&(p->newid[0]), newid(prefix));
    }
    return &(p->newid[0]);
}

static char *
newid(prefix)
char *prefix;
{
    static char buf[MAX_NEWID_SIZE];
    static int i = 1;

    sprintf(&(buf[0]), "%s%d", prefix, i++);
    return &(buf[0]);
}

static map *
new_mapping_entry(id)
char *id;
{
    map *p = (map *) malloc(sizeof(map));

    if ( p == NULL )
    {
        fprintf(stderr, "fatal: out of memory\n");
        exit(1);
    }
    p->id = malloc(strlen(id)+1);
    if ( p->id == NULL )
    {
        fprintf(stderr, "fatal: out of memory\n");
        exit(1);
    }
    strcpy(p->id, id);
    return p;
}
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 16 11:18:27 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail]
Subject: Iburg paper available
Message-ID: <[e-mail]>
Keywords: code, tools, FTP
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]>
Date: Sat, 13 Feb 1993 13:35:39 GMT
Approved: [e-mail]

In response to our recent comp.compilers announcement about the
availabililty Iburg <[e-mail]>, several comp.compilers
readers have asked about the electronic availability of the
forthcoming LOPLAS paper that describes Iburg, "Engineering a simple,
efficient code generator generator."

PostScript for this paper is included in pub/iburg.tar.Z, which is
available via anonymous ftp from ftp.cs.princeton.edu
(128.112.152.13).

--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 16 11:19:43 EST 1993
Xref: iecc comp.compilers:4250 comp.lang.fortran:9134 comp.lang.c:41055 comp.lang.ada:7642
Newsgroups: comp.compilers,comp.lang.fortran,comp.lang.c,comp.lang.ada
Path: iecc!compilers-sender
From: Perrault <[e-mail]>
Subject: IBM/370 code generation by FORTRAN, C or ADA hosted on Sun
Message-ID: <[e-mail]>
Followup-To: poster
Keywords: Fortran, C, Ada, IBM, question
Sender: [e-mail]
Organization: The MITRE Corp., Bedford, Ma.
Distribution: usa
Date: Sat, 13 Feb 1993 19:45:41 GMT
Approved: [e-mail]

I am looking for a compiler, in order of preference, for FORTRAN, C or Ada
that is hosted on a UNIX workstation (preferrably a Sun SPARC) that
generates IBM/370 code.  Thanks.

Philip E. Perrault                [phone]
The MITRE Corporation                [phone] (fax)
Langley AFB, Hampton, VA            [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 16 11:21:06 EST 1993
Xref: iecc comp.compilers:4251 misc.jobs.offered:23866
Newsgroups: comp.compilers,misc.jobs.offered
Path: iecc!compilers-sender
From: [e-mail]
Subject: Compiler positions available for week ending February 14
Message-ID: <[e-mail]>
Keywords: jobs
Sender: [e-mail]
Organization: Compilers Central
Date: Sun, 14 Feb 1993 13:00:02 GMT
Approved: [e-mail]

This is a digest of ``help wanted'' and ``position available'' messages
received at comp.compilers during the preceding week.  Messages must
advertise a position having something to do with compilers and must also
conform to the guidelines periodically posted in misc.jobs.offered.  To
respond to a job offer, send mail to the author of the message.  To submit
a message, mail it to [e-mail].


-------------------------------

Date: Wed, 10 Feb 1993 14:31:42 -0800
From: Larry Meadows <[e-mail]>
Subject: Compiler-related job openings
Organization: The Portland Group, Portland, OR

The Portland Group (PGI) is seeking to fill three positions as listed
below.  None of the positions are entry-level.

PGI is involved in compiler and tools development for high performance
computer systems.  PGI is located in Wilsonville, Oregon, a suburb of
Portland.

Please send resumes to [e-mail] (ascii or postscript, no
TeX), or FAX or Mail to:

    The Portland Group
    9160 S.W. Pioneer Court, Suite H
    Wilsonville, OR  97070
    FAX:    [phone]
    Attention: Personnel

===
Technical Marketing

Seeking experienced technical marketing professional.

Desired skills:
    Proficiency in C, Fortran, Assembly language
    Experienced in benchmarking, debugging, vector/parallel processing
    Knowledge of Intel i860 and Sparc architectures
    Knowledge/experience with data-parallelism and compiler
     optimization evaluation

Responsibilities:
    Performance analysis
    Analysis of compiled code and suggestions for improvement
    Customer code porting/tuning
    Representation at technical and trade shows.


===
Compiler Developer

Seeking mid-level compiler developer to work in the area of interprocedural
analysis and distributed memory compilation systems.

Desired skills:
    Proficient in C and Fortran.
    C, C++, and/or Fortran compiler experience required.
    Knowledge of flow and data analysis techniques helpful.
    Knowledge of Sparc, i860, or similar architectures helpful.
    Knowledge of vector/parallel/distributed computing helpful.

===
Tools Developer

Seeking software engineer to help develop analysis tools, including
performance analysis, profiling, distributed memory optimization.

Desired skills:
    Proficient in C.
    Knowledge of profiling tools required.
    Experience with database support for interprocedural
      information processing helpful.
    Knowledge of Fortran and GUI (X/Motif/Openlook) helpful.
    Knowledge of Sparc, i860, or similar architectures helpful.
    Knowledge of vector/parallel/distributed computing helpful.


-------------------------------

Date: Wed, 10 Feb 93 17:18:37 PST
From: K.C. Chu <[e-mail]>
Subject: Compiler position available at Mitsubishi Sunnyvale
Organization: Mitsubishi Electric Research Laboratories, Inc.

Sunnyvale R&D Lab of Mitsubishi Electric Research Labs, Inc. (MERL) is
looking for someone with excellent experience in design (and
implementation) of (machine- and language-independent) optimizers using
data-flow analysis, inter-procedural analysis, run-time/profile
information feedback, etc.

US citizenship or green card required.  Please send inquiries or your
resume to

        K. C. Chu
    Sunnyvale R&D Lab
        Mitsubishi Electric Research Labs, Inc.
    1050 E. Arques Ave.
    Sunnyvale, CA 94086
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 16 11:25:28 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (ANDREAS ARFF)
Subject: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: performance, question, comment
Sender: [e-mail]
Organization: Ostfold College
Date: Sun, 14 Feb 1993 16:31:08 GMT
Approved: [e-mail]

I suppose this has been up to discussion here for a couple of times, and
if it is a faq, please forgive me (though it sounds unlikely).

Many years ago I heard for the first time the statement that compilers
generated more efficient code than many assembler programmers did.  And
that is what I took it for, a statement.  Doing some tests between me and
Borland C showed that borland was quite a bit better than me. Even though
I havn't done any assembler codeing for over a year now, I found it
supprising that it should beat me with so much.

Could someone tell me more about this. Are there any tests between common
compilers and assembler programmers. Who is the best?

Arff

PS. The test wasn't scientific at all, and the code wasn't very large :-)
 Just curious...
[This has indeed been discussed to death in the past.  My impression is that
for a small chunk of code, a human can almost always meet or beat a compiler,
but for large chunks people aren't as persistent as compilers at optimizing
assember code.  Reports of concrete experience are welcomed, messages along
the lines of "I don't believe any compiler can code as well as I do"
cheerfully discarded. -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 16 11:28:24 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Ross Williams)
Subject: Looking for languages that compile to C
Message-ID: <[e-mail]>
Keywords: tools, Eiffel, question
Sender: [e-mail]
Organization: Stats Pure & Applied Maths, Uni of Adelaide, Australia
Date: Mon, 15 Feb 1993 13:47:43 GMT
Approved: [e-mail]

Netters,

I'm assisting a Government Department to set up a programming development
environment and as part of that process I'm helping them choose
programming languages.

For a couple of years I've been wavering between Ada and C/C++. In my
view, for most programming, Ada is obviously better (don't flame me - I
already KNOW that many people disagree with this), but the world has
grasped C so firmly and there are so many compilers for it, and so many
libraries for it, and so much support for it, that it seems to have become
compulsary :-) Certainly, the Government Department seems pretty
enthusiastic about it, and would probably consider it a "courageous
decision" not to use it.

Anyway, it occurred to me that, given that everyone has to live with C, it
might be that the best compromise is to find some nice clean language
whose compiler is written in a portable subset of C and which compiles
down to a portable subset of C. This would have the following advantages:

   * Most of the time we wouldn't have to program in C. We could use a
   civilized typesafe language with lots of nice object orientedness and
   so on.

   * But if we needed to use a C library, Unix interface, or do some
   grotty hacks, we could temporarily break through and use C.

   * Code written in the higher language would be MORE portable than C code
   because it is GUARANTEED to compile to a portable subset of C (whereas
   a C programmer might inadvertently do something non-portable). So
   you get the best of the high-level portability of Ada
   (well-definedness), and the pragmatic practical portability of C
   (a compiler on almost every existing Von Neumann architecture machine :-).

A quick look around reveals the language Eiffel (which compiles to C) and
which seems to be even better than Ada (perhaps far better). I have read
Betrand Meyer's book "Object-oriented Software Construction" and was very
impressed. However, I just peeked in comp.lang.eiffel and found [an article
saying that Eiffel seems to be moribund. -John]

Anyway, I think it would be great if there was a civilized language out
there for which compilers exist that compile down to C. Does anyone know
of any others besides Eiffel? I'm looking more for civilized 3GLs than
constraining 4GLs designed for screen design and query lookup.

Feel free to post replies, but please be sure to email them to me too as I
may not get to see all the postings in the groups I post to - we have a
fairly short news lifetime here. Also, unless you specify otherwise,
emailing me will constitute permission to reproduce your email publicly in
postings, compendiums, FTP archives and so on that I may wish to create on
this topic. Email me if you want a summary of replies.

Thanks very much,

Ross Williams
[e-mail]

PS: I'm sure many C hackers will object to my use of the word "civilized".
However, think about this. I have a friend (a competent but not too
experienced programmer) who programs in a primitive BASIC using GOSUBS and
GOTOS and so on. He understands the power C could give him and wants the
power, but he treasures too much the way the BASIC interpreter clearly
identifies his programming errors (as opposed to blowing the machine
apart). As for me, I have learnt to live with C through subversive
techniques such as using my own heap manager that places check bytes at
the ends of allocated blocks, and by including magic numbers and checksums
in instances of supposedly closed abstractions.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 16 11:39:29 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Thomas Tornblom)
Subject: Generic peep-hole optimizer available?
Message-ID: <[e-mail]>
Keywords: optimize, tools, question
Sender: [e-mail]
Organization: Communicator Nexus AB
Date: Tue, 16 Feb 1993 09:22:27 GMT
Approved: [e-mail]

Is there any such beast?

I'm developing software for a microcontroller built on a 65C02 core and
I'm using the Aztec C v3.2 compiler. Now this compiler produces some
really pessimal code, besides the outright defunct code... but still its
better than assembly.

What I would like to get hold of is some kind of generic peep-hole
optimizer that could be tweaked to recognize and optimize 6502
assembly.

Replacing the compiler is not an option, far too much of the code
built before my time depends on this compiler.

Thanks,
Thomas
--
Real life:  Thomas To:rnblom          Email:  [e-mail]
Snail mail: Communicator Nexus AB     Phone:  [phone]
            Box 857                   Fax:    [phone]
            S - 751 08 Uppsala, Sweden

--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 16 11:40:41 EST 1993
Xref: iecc comp.compilers:4255 comp.arch:26146
Newsgroups: comp.compilers,comp.arch
Path: iecc!compilers-sender
From: [e-mail] (Tom Ball)
Subject: Branch prediction paper available
Message-ID: <[e-mail]>
Keywords: architecture, report, FTP
Sender: [e-mail]
Organization: University of Wisconsin, Madison -- Computer Sciences Dept.
Date: Mon, 15 Feb 1993 19:18:01 GMT
Approved: [e-mail]

A new technical report on heuristics for program-based static branch
prediction is available via anonymous ftp from ftp.cs.wisc.edu in
directory "tech-reports/reports/93" as file "tr1137.ps.Z" The file is
compressed postscript.


Thomas Ball       Computer Sciences Dept.
[e-mail]   University of Wisconsin-Madison

------------------------------------------------------------------------------
Title: "Branch Prediction for Free"

Thomas Ball and James R. Larus
[e-mail],  [e-mail]
University of Wisconsin-Madison, Comp. Sci. Dept. TR #1137

Abstract:

Many compilers rely on branch prediction to improve program
performance by identifying frequently executed regions and by aiding
in scheduling instructions.  *Profile-based* predictors require a
time-consuming and inconvenient compile-profile-compile cycle in
order to make predictions.  We present a *program-based* branch
predictor that performs well for a large and diverse set of programs
written in C and Fortran.  In addition to using natural loop analysis
to predict branches that control the iteration of loops, we focus on
heuristics for predicting non-loop branches, which dominate the
dynamic branch count of many programs.  The heuristics are simple and
require little program analysis, yet they are effective in terms of
coverage and miss rate.  Although program-based prediction does not
equal the accuracy of profile-based prediction, we believe it reaches
a sufficiently high level to be useful.  Additional type and semantic
information available to a compiler would enhance our heuristics.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 17 11:16:00 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: Andreas Koschinsky <[e-mail]>
Subject: Alpha - A Compiler Generator based on Attribute Grammars
Message-ID: <[e-mail]>
Keywords: parse, tools, attribute
Sender: [e-mail]
Organization: Compilers Central
Date: Tue, 16 Feb 1993 21:28:42 GMT
Approved: [e-mail]

I have written a compiler generator. The generator is called Alpha and
uses attribute grammars as specification calculus. Alpha is the result of
a thesis at Technische Universitaet Berlin. I am looking for someone who
would like to test and use Alpha. I have written some compilers with Alpha
which work well.

Some words about Alpha. Alpha generates compilers from a compiler
specification. This specification describes a compiler in terminology of
attribute grammars. Parser and Scanner are generated by means of Bison and
Flex from the compiler specification. Alpha generates an ASE-evaluator
(Jazayeri and Walter). Attributes are divided into one-pass- and
multi-pass-attributes. The generated compiler stores instances of
one-pass-attributes in a stack and multi-pass-attributes in usual memory.
This saves much memory since 80-90% of the attributes of an attribute
grammar are one-pass-attributes. Alpha generates no parse tree and
optimizes the evaluation. Alpha does not include a back end generator.

If you are interested or you need more information, you can mail me. There
is a full documentation on the specification calculus and the internals of
Alpha.  The documentation is in german since it is a thesis at a german
university.

Andreas Koschinsky
Email: [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 17 11:16:58 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (David Keppel)
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: performance
Sender: [e-mail]
Organization: Computer Science & Engineering, U. of Washington, Seattle
References: <[e-mail]>
Date: Tue, 16 Feb 1993 23:06:06 GMT
Approved: [e-mail]

[e-mail] (ANDREAS ARFF) writes:
>[Who produces fastest code: compiler or human?]

John Levine writes:
>[A human can almost always meet or beat a compiler on small chunks.]

For extremely small chunks, Superopt nearly-exhaustively checks all
instruction combinations and is hard to beat.

See:

  T. Granlund and R. Kenner, "Eliminating branches using a
  superoptimizer and the GNU C compiler,"  ACM SIGPLAN '92
  Conf. on Prog. Lang. Design and Impl., June 1992, SF CA.
  [work done on IBM RS/6000; Kenner's email address is
  [e-mail]]

I've forgotten where Henry Massalin's original Superoptimizer paper
appeared, but it *may* be available as an online TR from
`cs.columbia.edu'.

It is usually hard for a human to do *worse* than a compiler because the
human can simply use the compiler to produce code then examine the code
for possible improvements.  Humans are good enough at pattern matching
that they can usually find improvements that the compiler missed.

At the risk of beating dead horse (power):

In my (limited) experience it is ``easy'' to get a given code fragment to
go 10-20% faster, but it's rarely worthwhile: if a routine is 10% faster
and program spends 10% of its time there you've just sped up the program
by 1%.  While there are certainly programs where this is worthwhile, they
aren't the ones that I usually work on.

Often, one can stare at the source code for a while and figure out ways to
``trick'' source code to produce faster code -- by manually unrolling
loops, for example.  Although this suffers from some of the same problems
as writing assembly (optimizations for one machine are often
pessimizations for another machine), such source code `tweaks' are often
more robust, portable, and reliable.

I think there was a time when the majority of the community accepted
``unsafe at any speed.''  Today, I think most people have given up on
assembly for all but the most key routines because even machines that give
binary compatability often have better performance if you recompile with a
compiler that knows about the machine.  Assembly code can't simply be
recompiled[*], it has to be rewritten.  Thus, I think the focus, even
among performance freaks, has changed to one of trying to expose the best
information for the compiler and writing the best compilers.

[*] Unless you have an optimizing assembler, in which case you're just
writing in a very low high-level language and you're using a compiler!

Of course I'm a compiler person, so it's expectable I'd hold some such
opinion.

        ;-D on  ( Recoding a dead horse )  Pardo
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 17 13:58:00 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (James Kanze)
Subject: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: optimize
Sender: [e-mail]
Organization: Compilers Central
References:  <[e-mail]>
Date: Wed, 17 Feb 1993 14:17:26 GMT
Approved: [e-mail]

ANDREAS ARFF writes:
|> Many years ago I heard for the first time the statement that compilers
|> generated more efficient code than many assembler programmers did.  [Is
|> this really true?]

Wouldn't this depend somewhat on the architecture of the target machine?
Machines such as the Intel 80x86 line are notoriously difficult to compile
to; an experienced programmer for such a processor will easily beat the
best compiler by a factor of two or more.  On the other hand, the late NSC
32000 had an architecture designed to make life easy for the compiler, and
I would be surprized if anyone could beat a really good compiler by a
significant factor.

Along these lines, does anyone know of any research done on using semantic
information in register allocation.  For example, if as an 8086 assembler
programmer, I see a function definition:
    f( char* dst , const char* src )
I will immediately choose DI as the register for dst and SI for src (and
not the inverse).  While I wouldn't expect the compiler to recognize the
significance of the symbol dst itself, I could imagine deferring actual
choice of registers until after the entire function has been parsed,
counting different kinds of use during the parse, and then using this
information to optimize register allocation.
--
James Kanze                             email: [e-mail]
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 17 14:02:11 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: "Josh N. Pritikin" <[e-mail]>
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: optimize
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]>
Date: Wed, 17 Feb 1993 15:37:48 GMT
Approved: [e-mail]

>Could someone tell me more about this. Are there any tests between common
>compilers and assembler programmers. Who is the best?

>[This has indeed been discussed to death in the past.  My impression is that
>for a small chunk of code, a human can almost always meet or beat a compiler,
>but for large chunks people aren't as persistent as compilers at optimizing

Assembly programmers will never have job security!  Take a look at the GNU
superoptimizer ---

GSO is a function sequence generator that uses an exhaustive
generate-and-test approach to find the shortest instruction sequence for a
given function.  You have to tell the superoptimizer which function and
which CPU you want to get code for.

Sample GSO results:

  SPARC code for i5 = ((signed) i0 > (signed) i1):
          subcc   %i1,%i0,%i2
          srl     %i1,31,%i3
          sra     %i0,31,%i4
          addx    %i4,%i3,%i5

  Faster 80x86 code than the standard cmpl/seta/and for
  ecx = ((unsigned) eax > (unsigned) edx):
          cmpl    %eax,%edx
          sbbl    %ecx,%ecx
          negl    %ecx

  MC88000 code for 'find first set bit', i.e., r6 = ffs(r2):
          subu.co r3,r0,r2
          and     r4,r3,r2
          addu.ci r5,r4,r4
          ff1     r6,r5

  POWER (RS/6000) code for r6 = ((unsigned) r3 < (unsigned) r4) + r5
          sf      r6,r4,r3
          sfe     r7,r5,r6
          sf      r8,r7,r6

Aide from the CPUs in the examples above, GSO generates code for
MC680x0, Amd290xx, Pyramid(SP,AP,XP), and Alpha.

[e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 17 14:04:33 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Craig Burley)
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: optimize, design
Sender: [e-mail]
Organization: Free Software Foundation 545 Tech Square Cambridge, MA 02139
References: <[e-mail]>
Date: Wed, 17 Feb 1993 18:37:59 GMT
Approved: [e-mail]

[e-mail] (ANDREAS ARFF) writes:

   Could someone tell me more about this. Are there any tests between common
   compilers and assembler programmers. Who is the best?

I have a general observation about the issue of the quality of code
produced by compilers versus humans, which is this:

Compilers are at a disadvantage in most cases because they are not given
all the information we humans have at our disposal and they are given
restrictions that we humans can selectively ignore in cases that the
compilers can't.

Note that, in one sense, this statement could even extend from "compilers"
to "assemblers", but in another, let's assume that the human has, via the
assembler, complete control of and access to the underlying target (a UNIX
executable, an MS-DOS .EXE file, whatever).  This seems to not always be
the case with some assembler/linker toolsets (one can't always specify
just what alignment is needed, as in "make sure this code starts at an
address such that dividing its byte offset by 16 yields a remainder of
3"), but one can presumably always get around that restriction by writing
the entire application in a single monolithic assembler source chunk, even
using explicit octal/hex coding in place of mnemonic instructions where
necessary.  I.e., for the purposes of this article, assembler is to
machine-code target as a UNIX text editor is to a UNIX executable --
anything you need in an executable you should be able to make via the text
editor (if it's good), and, similarly, any machine-code target (executable
or .EXE file) you should be able to make (with varying degrees of effort
and elegance) via the assembler.

So, back to compilers.

The languages we use are a major part of the problem, but not all of it --
compiler technology is much of the rest of the problem, then throw in
library and O/S interfaces and implementations for a small portion.

A simple example of the language problem is C's enum:

enum { RED, GREEN, BLUE } color;

Some programmers typing this mean "I need three constants with distinct
values named RED, GREEN, and BLUE", other mean "I need three constants
named RED, GREEN, and BLUE with the values 0, 1, and 2, respectively".

C compilers must assume the latter statement (generally speaking) is
meant, when in fact in many cases only the former (a weaker one) is.

The difference from an optimization point of view is that the way the
constants might be used in a tight loop might well affect the values a
compiler assigns to them.  A human might decide to give them the values 0,
4, and 8, or even 0, 256, and 512, by observing that a few cycles are
saved by not having to multiply a variable of "enum color" type by some
factor to get a jump-table offset to some code or data.  A C compiler is
not likely to have this ability (safely) unless it is globally optimizing
across all program modules.

A sample solution would be a language construct that does literally mean
"I don't care about the values as long as they're distinct", but in the
context of C, it would not represent enough of an improvement to counter
the "noise factor" it would introduce to the language.  That is, few
programs would benefit from it, few programmers would use it, but many
people would be put off by having to learn yet another construct in what
is supposed to be a small language (see C++).

The "global optimization" approach -- optimizing the entire program rather
than just portions of it -- provides a machine-assisted way to get around
many such language barriers.

However, that approach has two faults I can think of when it comes to
trying to match or exceed human potential:

    1.  In trying to get around missing modes of programmer expression,
        i.e. in trying to reconstruct knowledge already in the
    programmer's head (such as "I don't really care what the actual
    values are for RED, GREEN, and BLUE") by doing a full analysis of
    the program, the global optimizer spends what often is too much
    time doing basic analysis and not really optimizing, and it can
    _still_ fail to reconstruct that knowledge.

    2.  All useful programs do some kind of I/O, but even global
        optimization does not provide for complete information on
        the formats of files accessed and their constraints.

An example of both problems is, what if the code opens a file and writes
and reads variables of type "enum color" to it?  Does that mean the
programmer really wants them to be 0, 1, or 2, or can the compiler
substitute 0, 256, and 512 there as well as for memory-resident copies?
The answer is: let's ask the human compiler.  If that human (as the
programmer) knows the file is only a temporary scratchpad, then the
arbitrary values are fine.  If it is a permanent data base, then the 0, 1,
and 2 values must be used and, if appropriate, translated accordingly (if
it is still optimal to do so).

However, a human also can be aware that the file is a permanent data base
but one that is created and maintained by the program under construction,
so the values are in flux but about to become permanent.  And, the human
also can realize that whatever values are best for the running time of the
program are what should be in the file.  And that the format of the file
isn't _yet_ fixed but might be down the road.  And when and how to trash
(or convert) the file when the optimal values change due to changes the
programmer makes in the code.  And when the file has become fixed (the
program has been put into production use, so file conversion is no longer
a valid way to deal with "more optimal" values), the human knows to no
longer change the file-resident values for "enum color" even if the
program gets to where it wants more-optimal values in memory.

How are these things communicated to a compiler?  I don't know of any
language that permits it in a way that approaches the convenience needed
to make such optimizations more feasible via an HLL than coding most or
all of the program in assembler in the first place.  (I do have lots of
ideas _how_ to make this sufficiently convenient, but they're way beyond
the scope of this post.)

Of course, the C programmer can play with all these things while mucking
around with "enum { RED = 0, GREEN = 256, BLUE = 512 } color;", and that's
what a lot of people use C for anyway, but remember, we're talking about
the difference between a compiler (such as for C) and a human doing the
compilation.  In the C-compiler case, unless the programmer constantly
looks at the assembler output from the compiler and notices places where
different constants could improve performance, the programmer won't know
to make these changes, whereas the human compiler can see that while
coding (while optimizing).

"enum color" is a rather weak example, seeing as there are other missing
language facilities that affect typical program optimization to a much
greater degree, but it is a simple one.  And, in the right application, it
could have a huge impact -- even something like a 2x difference in how
fast graphics are displayed on a color screen, or more.

Note that speed isn't always the only issue.  Sometimes space is.
Sometimes speed is the only overall issue, but given a machine's
architecture (such as the 486's cache design), space becomes a dominant
issue in optimizing certain stretches of code.  And humans often know more
about when to make those tradeoffs than compilers do, especially when
things like run-time error reporting (comparatively rare) is included -- a
code path that inevitably leads to a diagnostic is not only less important
to optimize than an alternate path that doesn't, but should be optimized
perhaps for space than for speed so the alternate path runs faster (I've
even written assembler code that lets the alternate path run further
before branching to the diagnostic patch so the typical case runs faster;
there's no way, with today's languages, I could tell a compiler to do this
elegantly).

A more classic example is this:

void
array_mult (float a[], float b[], float c[], int n)
{
int i;

for (i = 0; i < n; ++i)
  c[i] = a[i] * b[i];
}

Here is the above C code directly mapped to Fortran (not as a plug-in
replacement but as a programmer-level replacement):

      SUBROUTINE ARRAYMULT (A, B, C, N)
      INTEGER N
      REAL A(N), B(N), C(N)
      INTEGER I
C
      DO I=1, N
         C(I) = A(I) * B(I)
      END DO
C
      END

With regard to human implementation in machine code, and assuming the
human has the full program available (i.e. globally optimizes), both
procedures can be compiled to exactly the same machine code, i.e. they are
identical.  However, a C compiler cannot ever, on some architectures, make
the C version run as fast as Fortran compiler can with the Fortran
version.

Why?  Because the Fortran language includes with the above code the
assumption that the array C does not overlap A or B with respect to the
temporary size specified via N during any invocation of ARRAYMULT.  For
example, the compiled code could start off (if it wanted to do something
this weird) by zeroing C(1) through C(N), or it could save the results of
the DO loop in a temporary array and copy that into C only after the whole
DO loop were finished, and, _by definition_, the code would have the same
effect on the running program.  C, of course, places no such restrictions
on the programmer's intentions.

Now, global optimization could help the C compiler determine that no
overlaps are involved in _some_ cases (and only after a potentially huge
amount of computation).  But if indices are read in from a terminal or
file, it cannot, whereas Fortran happily goes along assuming no overlaps
ever occur.  Period.  (Of course, if indices are read in from a file, and
could potentially violate the assumption, then that is a bug in the
Fortran implementation of the program that the C implementation would not
have -- I'm assuming a "clean" file here, constructed so it meets the
requirements of the program.)  The human programmer might well know that
the C version won't ever involve overlap, just as the Fortran version
doesn't, but the C compiler might not be able to intuit that.

This again highlights the "what is the context/format of data external to
the program?" question even global optimizers need to, and cannot always,
answer -- for the Fortran version, there's an implicit answer that the
compiler could conceivably use to an advantage beyond the no-overlap rules
mentioned, whereas for the C version, that implicit answer does not exist
(except in the programmer's head).

Again, there are plenty of other examples that can show a huge impact on
execution times (though the no-overlap one actually can have a huge impact
on some machines), but the above show how even simple, behind-the- scenes
assumptions made by the language designers (and hence the compilers) but
not necessarily by the programmers (or with no way to easily encode those
assumptions in the languages) can lessen a compiler's ability to match
that of a human.

Ultimately, it's best to use the most expressive language you can find to
express your intentions (one that allows you to express as much of you
knowledge as possible in a concise, yet elegant, fashion), and remain
aware of how the compiler is likely to optimize your code so you can
decide to use assembler when and where appropriate.  This ultimate cannot
be realized with today's tools, but I think the industry will make a
significant lurch in that direction within the next 10 years, and I'm
working on helping that happen in my spare time (i.e. when I'm not writing
a Fortran compiler :-).
--
James Craig Burley, Software Craftsperson    [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 17 19:35:03 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Joe Buck)
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: optimize
Sender: [e-mail]
Organization: U. C. Berkeley
References: <[e-mail]> <[e-mail]>
Date: Wed, 17 Feb 1993 20:56:39 GMT
Approved: [e-mail]

Josh N. Pritikin <[e-mail]> writes:
>Assembly programmers will never have job security!  Take a look at the GNU
>superoptimizer ---

The GNU superoptimizer uses exhaustive search.  This means that its
behavior is exponential.  It can still be useful in certain circumstances
(find the best sequence to generate a certain small function), but it's
not going to put anyone out of business.

The sequences shown in your example are all four instructions or fewer.
How fast its performance degrades as more instructions are required
depends on how good its heuristics are, but you can't get away from the
combinatorial explosion.
--
Joe Buck    [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 17 19:36:38 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: "mohd hanafiah abdullah" <[e-mail]>
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: performance
Sender: [e-mail]
Organization: Indiana University Computer Science, Bloomington
References: <[e-mail]> <[e-mail]>
Date: Wed, 17 Feb 1993 23:28:40 GMT
Approved: [e-mail]

In most cases, programming in the large, a competent optimizing compiler
could produce faster code than a person can.

For instance, the compiler could readily do global register allocation by
using graph coloring, whereas the mentioned technique does not even cross
the person's mind at the time.  Well, even if it does it would be
infeasible for him/her to implement the allocation himself due to its
sheer size as well as impractical debugging time.

Have fun.

Napi
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 17 23:35:24 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Eliot Moss)
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: optimize, performance
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
References: <[e-mail]>
Date: Thu, 18 Feb 1993 03:37:37 GMT
Approved: [e-mail]

At SIGPLAN a couple of years ago (SIGPLAN '91, I think; the one in
Toronto), Guy Steele gave a talk on optimizing certain kinds of numerical
programs for the CM-5, called "Fortran at N Gigaflops" (or some such, for
suitable N). They generally got better speedups than are practical for
humans because they unrolled loops and did heavy and intricate register
allocation. A human could do it in theory, but it's so tedious and easy to
make a mistake that it's much better for a compiler to do it. Furthermore,
the compiler can generate many more useful object programs much faster
than the human can do them in assembly. So this is a case where the
compiler wins by brute force.
--
J. Eliot B. Moss, Associate Professor    Visiting Associate Professor
Department of Computer Science        School of Computer Science
Lederle Graduate Research Center    Carnegie Mellon University
University of Massachusetts        5000 Forbes Avenue
Amherst, MA  01003            Pittsburgh, PA  15213-3891
[phone], 545-1249 (fax)        [phone], 681-5739 (fax)
[e-mail]            [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 17 23:53:42 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Eliot Moss)
Subject: Re: Looking for languages that compile to C
Message-ID: <[e-mail]>
Keywords: C, modula
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
References: <[e-mail]>
Date: Thu, 18 Feb 1993 03:43:28 GMT
Approved: [e-mail]

By all means you should consider Modula-3. The Digital Equipment
Corporation's Systems Research Center has a compiler that produces C and
has been ported to a number of platforms. You can get it from
pub/DEC/Modula-3 on gatekeeper.dec.com. Also check out comp.lang.modula3,
including its FAQ, which lists the books out on Modula-3. Also, I note
that DEC SRC has a native compiler under development for a few platforms,
and my own research group at UMass Amherst is developing GNU Modula-3. SRC
and others have developed substantial working applications in Modula-3,
and you can get working Modula-3 implementations for free, now and in the
future.
--
J. Eliot B. Moss, Associate Professor    Visiting Associate Professor
Department of Computer Science        School of Computer Science
Lederle Graduate Research Center    Carnegie Mellon University
University of Massachusetts        5000 Forbes Avenue
Amherst, MA  01003            Pittsburgh, PA  15213-3891
[phone], 545-1249 (fax)        [phone], 681-5739 (fax)
[e-mail]            [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 18 00:10:03 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Preston Briggs)
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: optimize
Sender: [e-mail]
Organization: Rice University, Houston
References: <[e-mail]> <[e-mail]>
Date: Thu, 18 Feb 1993 04:15:03 GMT
Approved: [e-mail]

[e-mail] (Joe Buck) writes:

>The GNU superoptimizer uses exhaustive search.  This means that its
>behavior is exponential.

>How fast its performance degrades as more instructions are required
>depends on how good its heuristics are, but you can't get away from the
>combinatorial explosion.

I'm no fan of exponential algorithms, but in defense of the superoptimizer
work, I'll point out that it is used at compiler-generation time, not at
compile time.  Thus, it is possible to let it crunch away for a week
without impacting the eventual user.

It's similar to the idea of writing an exponential routine to search for
better ways to convert integer-multiply-by-a-constant to shifts, adds, and
subtracts.  There are known routines that do a good job, but an optimal
translation requires exponential search.  Therefore, build a searcher that
tries to beat your normal routine and let it run for a while (days, weeks,
...).  Anytime it does a better job, write the result down and put it in a
hash table that you query before calling the normal routine.

Unfortunately, these things have somewhat limited applicability.  You can
use them to find nice translations of particular idioms that programmers
_might_ use; but wouldn't it be nice to attack the code that the
programmer really did write (e.g., most programs multiply by 4 and 8, easy
cases; very few programs multiply by 123456789).

Preston Briggs
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 18 11:54:51 EST 1993
Xref: iecc comp.compilers:4266 comp.sources.wanted:15068
Newsgroups: comp.compilers,comp.sources.wanted
Path: iecc!compilers-sender
From: [e-mail] (Karen Trovato)
Subject: Natural Language Parser Wanted
Message-ID: <[e-mail]>
Keywords: parse, question, comment
Sender: [e-mail]
Organization: Philips Laboratories, Briarcliff, New York
Date: Thu, 18 Feb 1993 15:21:48 GMT
Approved: [e-mail]

I apologize if this is the incorrect forum for this request, but these
seem to be the most logical groups for posting on the net.

I am looking to buy or license yacc source for an english language parser
for development in a product. Perfection is not required.

Please send pointers to research, school projects, or existing products
via email, or contact me at the phone numbers or address below.

Thank you.
                Karen I. Trovato - Member of Research Staff
                Software and Services Dept.
                Philips Laboratories
                345 Scarborough Road, Briarcliff Manor, NY 10510
        Phone: [phone] Fax: [phone]
        [e-mail]
[It is my impression that people gave up trying to parse natural language
using context-free methods in about 1966.  One of the examples in the
O'Reilly "lex & yacc" book is a tiny English parser, but by the time we
get to a dozen rules or so it becomes evident that it's never going to parse
more than a tiny grammar with a tiny vocabulary. -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 18 11:55:59 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (BO/EBC/KX/ZGE Michael Bergman 682 4958)
Subject: Conversion to LL(1)
Message-ID: <[e-mail]>
Keywords: LL(1), parse, question
Sender: [e-mail]
Organization: Compilers Central
Date: Thu, 18 Feb 1993 16:07:38 GMT
Approved: [e-mail]

At the risk of being repetitive about this, I would *really* like someone
to to tell me (Jan..?) the algorithms for

a) Eliminating all epsilon productions from a CFG
b) Eliminating all cycles from a CFG

The left-recursion removal (and I suspect left-factoring as well, but this
is only a suspicion!) is only guaranteed to work if the grammar is
epsilon-free and cycle free.

I've read through a couple of old articles (Jan Schramp seems to have done
quite a lot of thinking in the area) and the subject interests me.

The left-factoring as described in the Dragon Book is IMO rather limited
as it only tries to get rid of "direct" FIRST overlap of the type:

A -> BC | BC | BC | ... | gamma
       1    2    3

where gamma represents all alternatives not beginning with B.  However,
there may still be FIRST-set overlap even if we do not have this kind of
"direct" production. Substitutions may give such a production, but then
one might run into a loop as Jan Schramp pointed out in an article dated
May 18 1992.

His example was:
S -> Aa | Bb
A -> cA | eps
B -> cB | eps

To get the common leading c in the same production, we substitute for A
and B on S's right side and get

S -> cAa | cBb | a | b
A -> cA | eps
B -> cB | eps

After factoring S, we run into a the same situation again with A and B
both having c in their FIRST sets.  Then Jan tries another approach and
first eliminates the epsilon productions:

S -> A | B
A -> cA | a
B -> cB | b

Then he wants to get the "direct" form of the common prefix situation:

S -> cA | a | cB | b
A -> cA | a
B -> cB | b

Factoring now gives:

S -> cD | a | b
D -> A | B

But D is equivalent to S, and we get S -> cS | a | b which is LL(1).


I'm wondering if the elimination of the epsilon productions was
significant.  It would be nice if we knew the left-factoring was guranteed
to work (without getting into a loop) if all epsilon productions are first
eliminted. Comments?

On the other hand, this might not lead anywhere in practice since after
the left-recursion removal, the grammar may again contain epsilon
pruductions.  These would then have to be removed using the algorithm I
was asking for, before we can apply the left-factoring. But the epsilon
elimination might very well re-introduce left-recursion.... :-(, I don't
know. On the other hand - maybe it does not!

I'm hoping someone out there is an expert on this.
--
Michael Bergman                Email: [e-mail]
KX/ZGE                    Tfn:   [phone]
Ericsson Business Networks
S-135 83 Tyreso, Sweden
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 18 23:56:36 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Jerry Roth)
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: optimize, performance
Sender: [e-mail]
Organization: Rice University, Houston
References: <[e-mail]> <[e-mail]>
Date: Thu, 18 Feb 1993 16:45:40 GMT
Approved: [e-mail]

[e-mail] writes:

>At SIGPLAN a couple of years ago (SIGPLAN '91, I think; the one in
>Toronto), Guy Steele gave a talk on optimizing certain kinds of numerical
>programs for the CM-5, called "Fortran at N Gigaflops" (or some such, for
>suitable N). They generally got better speedups than are practical for
>humans because they unrolled loops and did heavy and intricate register
>allocation. A human could do it in theory, but it's so tedious and easy to
>make a mistake that it's much better for a compiler to do it.

Here's the complete reference:

@InProceedings{BHMS:91,
    Author = {M. Bromley and S. Heller and T. McNerney and
          G. {Steele, Jr.}},
    Title = {Fortran at Ten Gigaflops:
        The {Connection Machine} Convolution Compiler},
    Booktitle = SIGPLAN91,
    Address = Toronto,
    Month = Jun,
    Year = 1991}

People also refer to this Convolution Compiler as the Stencil Compiler. It
only targets a strict subset of computational patterns known as stencils.
A user must separate the stencil from his application and place it in a
subroutine by itself, and then invoke this special compiler on it. The
compiler, after performing some pattern matching, simply generates calls
to some library routines. These routines are all *hand written microcode*.
Thus most of the work, including the intricate register allocation for
these specialized patterns, was all done by hand. The only real work done
at compile time is to determine the amount of loop unrolling and which
microcode routines to use, and this is not too difficult given that they
have limited their scope to only stencils. The impressive speed-ups
reported (from 5.6 gigaflops to 14 gigaflops) were measured against code
produced by the regular CM-2 fortran compiler.

Note, I am not knocking their work. I am really impressed by their ideas,
and hope to be able to accomplish similar things (but in a more general
fashion). I just wanted to point out that this work may have a lesser
impact on the human vs. compiler argument than initially indicated.

Thanks for your time,
Jerry Roth
Rice University
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 18 23:57:24 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Dale R. Worley)
Subject: Superoptimizers (was Re: Effectiveness of compilers today)
Message-ID: <[e-mail]>
Keywords: optimize
Sender: [e-mail]
Organization: MIT Dept. of Tetrapilotomy, Cambridge, MA, USA
References: <[e-mail]> <[e-mail]>
Date: Thu, 18 Feb 1993 17:01:35 GMT
Approved: [e-mail]

[e-mail] (Preston Briggs) writes:
   Unfortunately, [superoptimizers] have somewhat limited
   applicability.  You can use them to find nice translations of
   particular idioms that programmers _might_ use; but wouldn't it be
   nice to attack the code that the programmer really did write (e.g.,
   most programs multiply by 4 and 8, easy cases; very few programs
   multiply by 123456789).

I've wondered if it's possible to have a program grovel the ASTs of a
bunch of programs and extract out "common" combinations of operations that
should be candidates for superoptimizer investigation.

Dale Worley        Dept. of Math., MIT        [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 18 23:58:54 EST 1993
Xref: iecc comp.compilers:4270 comp.sources.wanted:15077
Newsgroups: comp.compilers,comp.sources.wanted
Path: iecc!compilers-sender
From: [e-mail] (John D. Mitchell)
Subject: Re: Natural Language Parser Wanted
Message-ID: <[e-mail]>
Keywords: parse
Sender: [e-mail]
Organization: University of California, at Berkeley
References: <[e-mail]>
Date: Fri, 19 Feb 1993 00:50:47 GMT
Approved: [e-mail]

[e-mail] (Karen Trovato) writes:
>I am looking to buy or license yacc source for an english language parser
>for development in a product. Perfection is not required.
[...]
>[It is my impression that people gave up trying to parse natural language
>using context-free methods in about 1966.  One of the examples...]

Yep.  Natural language parsing/understanding/etc. has been a major branch
of the AI universe for a long time.  You should go over to comp.ai.nlang
(or something like that).

My understanding of the latest developments is that you can get actually
reasonably good understanding but only over limited knowledge domains.

Hope this helps,
        John
        [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 18 23:59:59 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: Joydip Dass <[e-mail]>
Subject: C++ symbol table
Message-ID: <[e-mail]>
Keywords: C++, parse, question, comment
Sender: [e-mail]
Organization: Compilers Central
Date: Fri, 19 Feb 1993 02:05:54 GMT
Approved: [e-mail]

Greetings.

I am currently trying to do some work on parsing some C++ code.  I am new
at this stuff so pardon my ignorance....

I have got hold of Jim Roskind`s C++ grammar.  I have also modified his
Flex input file to suit my purposes.  However, as he points out in his
documentation, the lexer he supplied does not include a SYMBOL TABLE and
does NOT KEEP TRACK OF CURRENT SCOPES.  I am in need of these
facilities....

My objectives are -
- To keep a list of all identifiers in the C++ code being parsed.
(Identifiers include - variables, #defines, and function names etc.)

- I want to be able to identify these things separately i.e. distinguish a
function name from a variable.  I also want to be able to tell different
types of variables apart e.g. a pointer declaration from a non-pointer
variable OR an int declaration from a register declaration.
- I would like to store these in some sort of a hash table to do the
fastest possible searches.

This sounds a bit vague at the moment, but if I can achieve these
particular objectives I will be better equipped to plan future directions.

I have read the bit on symbol tables in "lex & yacc" by Levine, Mason and
Brown.  It was most helpful in understanding the basic concepts of symbol
tabels etc.  However, if anyone out there has already worked on this
problem I would like to get hold of it.  I think what I am trying to do is
more complex than the examples in the book and any help would save me a
lot of time.

Many Thanks in advance to anyone who can help me.

Joydip Das
----------------------------
[e-mail]
[Maybe you could extract what you need from g++. -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 13:07:08 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (David Keppel)
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: optimize
Sender: [e-mail]
Organization: Computer Science & Engineering, U. of Washington, Seattle
References: <[e-mail]> <[e-mail]>
Date: Fri, 19 Feb 1993 04:51:43 GMT
Approved: [e-mail]

[e-mail] (Joe Buck) writes:
>Superoptimizer uses exhaustive search and is thus exponential.

[e-mail] (Preston Briggs) writes:
>In defense, I'll point out that it is used at compiler-generation time
>[thus it can crunch for a week w/o affecting compile time.]

The original Superoptmizer was available for the compiler writer, the
compiler, and the programmer.  As I recall, Henry told me the biggest
thing he'd ever tried with it was about 20 instructions and that took a
couple weeks (an Othello move generator; substantial speedup).  Henry also
used the Superoptimizer technique on longer sequences by Superoptimizing
windows of a few instructions, then moving the window.  As I recall, the
first pass would be run with a small window and would go fast; then the
window size would be increased once the ``obvious'' sequences were removed
by the first pass; and so on.  That way, Superoptimizer (which never
considered longer sequences) would only run with the large window when the
code in question was already reasonably tight.

        ;-D on  ( Sequence-ial logic )  Pardo
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 13:08:19 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Kendall Bennett)
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: performance
Sender: [e-mail]
Organization: Collaborative Information Technology Research Institute
References: <[e-mail]> <[e-mail]>
Date: Fri, 19 Feb 1993 02:51:12 GMT
Approved: [e-mail]

[e-mail] (ANDREAS ARFF) writes:
>[Who produces fastest code: compiler or human?]

Depends on what the code is and what it does.

John Levine writes:
>[A human can almost always meet or beat a compiler on small chunks.]

True, but as mentioned elsewhere, for how much speed improvement.

[e-mail] (David Keppel) writes:
>It is usually hard for a human to do *worse* than a compiler because the
>human can simply use the compiler to produce code then examine the code
>for possible improvements.  Humans are good enough at pattern matching
>that they can usually find improvements that the compiler missed.

Ok, now this is the entirely _wrong_ way to go about recoding something in
assembly language. If you examine the compiler's code, you will never get
anything more than about 10% speed improvement or so. The only time when
using assembly language is a real bonus, is when the task being peformed
is not very well suited to a compiler.

When recoding something in assembly, you need to take an entirely new look
at the problem and try to solve it using the full power of the machine at
hand, something that compilers are not particularly good at doing (taking
advantage of machine specific optimisations). The 80x86 range of CPU's
have an extensive range of _extremely_ fast instructions for manipulating
string data (well, for manipulating any data). Compiler's generally do not
produce code that takes advantage of these instructions (except for
inlining intrinsic functions like memcpy, strcmp etc and copying blocks of
data internally). If you can re-think your problem in terms of these more
powerful instructions, you can gain massive speed improvements (200-400%
plus). Now this is really worth the effort.

There are many other things that compiler just are _not_ good at doing,
and make perfect candidates for re-coding in assembly. Some of these are
multi-precision arithmetic, and shifts and rotates. High Level languages
like C just do not have the facilities for performing add's with carry,
rotates with carry's or even full precison integer multiplication (a 32
bit by 32 bit multiply produces a 64 bit product, which under C is a 32
bit product). If your code requires any of these things, recoding is
assembly can provide a significant speed improvement (CRC algorithms,
compression routines, you name it).

>In my (limited) experience it is ``easy'' to get a given code fragment to
>go 10-20% faster, but it's rarely worthwhile: if a routine is 10% faster
>and program spends 10% of its time there you've just sped up the program
>by 1%.  While there are certainly programs where this is worthwhile, they
>aren't the ones that I usually work on.

We all know the old 80-20 rule (or even 90-10 rule) that most programs
spend 80% of their time in 20% of the code. Optimising the 80% that hardly
ever gets executed is a waste of time, but optmising that other 20%
certainly is.

No-one in their right mind is going to write an entire program in assembly
these days, but by judicious use of assembly in the right areas,
significant speedups can be had.
--
Kendall Bennett                          | Internet:                     |
RMIT Advanced Computer Graphics Centre   | [e-mail]              |
CITRI Building, 723 Swanston Street      | [e-mail]    |
Carlton Victoria 3053 AUSTRALIA.         |                               |
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 13:09:55 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail]
Subject: Re: Looking for languages that compile to C
Message-ID: <[e-mail]>
Keywords: C, modula
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]>
Date: Fri, 19 Feb 1993 09:04:55 GMT
Approved: [e-mail]

I think the original question is a strange one. It's not the language that
compiles to C, it's the compiler.

We have developed a compiler generator toolset (Elegant) that used to
compile to Modula-2 but has been rewritten to compile to (K&R) C.  (ANSI-C
is our next target.)

Why C?. Because C is what its adversaries always claim: a high level
assembler. And that's how Elegant uses it: to produce compact, highly
efficient and almost unreadable code. But with one great advantage: you
can get execuatbles on almost any platform. The platform only has to
support C.

Elegant is a bootstrapped compiler generator: it's written in Elegant. At
the moment, we have versions for several flavours of Unix (SunOS 3 and 4,
Apollo Domain, Ultrix), VAX/VMS and MS-DOS. The only things that had to be
changed for each of these platforms are a handfull of library routines
written directly in C. After that, its just one comand and a weekend of
processing later we have a new version for each of those platforms (even
the MS-DOS version is generated automatically on a PC-NFS connected PC).

If you want more information on Elegant, you are referred to

    The Elegant Compiler Generator System
    Lex Augusteijn
    (page 238-54)

    in

    Attribute Grammars and Their Applications
    P.Deransart, M. Jourdan (Eds)
    Springer Lecture Notes in Computer Science 461

Reagrds,
    Harm
--
| Harm Munk                              | Building WL 1.5.17
| Philips Research Laboratories          | P.O. Box 80 000
| Knowledge Based Systems                | 5600 JA  Eindhoven
|                                        | The Netherlands
| tel. [phone]                   | email: [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 13:11:09 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail]
Subject: object code vs. assembler code
Message-ID: <[e-mail]>
Keywords: assembler, question, comment
Sender: [e-mail]
Organization: Compilers Central
Date: Fri, 19 Feb 1993 09:25:29 GMT
Approved: [e-mail]

Many unix based compilers seem to produce assembly language output which
is assembled by a separate program to produce object modules.

Obviously it is possible for a compiler to produce object code directly
which seems to be the standard on many other systems which seems much more
efficent to me.

Is there any good reason why many compilers produce assembly language as
this seems to be a big performance hit with no gain by doing this. I can't
see that producing obejct code is *that* much harder.

-- John Burton
[Mostly it's a matter of taste.  Some Unix assemblers, particularly the
earlier ones, were very fast, so there needn't be a performance issue. -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 13:13:16 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: Frieder Monninger    <[e-mail]>
Subject: Eiffel for OS/2
Message-ID: <[e-mail]>
Keywords: Eiffel
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]>
Date: Fri, 19 Feb 1993 10:38:44 GMT
Approved: [e-mail]

>Is anyone thinking about porting Eiffel to OS/2 version 2 (32-bit)?

Eiffel/S runs under OS/2 2.0 using GCC 2.1 or Watcom 9.0 C as backend -
this means 32 bit.
--
Frieder Monninger    SIG Computer GmbH    [e-mail]
            D 6333 Braunfels    ++49 6472/2096

--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 13:14:09 EST 1993
Xref: iecc comp.compilers:4277 comp.programming:3734 comp.software-eng:10445
Newsgroups: comp.compilers,comp.programming,comp.software-eng
Path: iecc!compilers-sender
From: [e-mail] (Pedro Geraldes Freire)
Subject: Looking for pseudo-code interpreters
Message-ID: <[e-mail]>
Followup-To: [e-mail]
Keywords: interpreter, question
Sender: [e-mail]
Organization: Universidade Nova de Lisboa, PORTUGAL
Date: Fri, 19 Feb 1993 15:39:52 GMT
Approved: [e-mail]


 Hello everybody!

 We are developing a project for an integrated information system that
uses EXPRESS as a definition language. We are thinking of using some sort
of interpreter to implement the rule/procedural part of the system.  The
interpreter would have to access the data maintained by the system so it
would probably need some sort of symbolic data manipulation
capabilities... Efficiency is important but not critical.

 PD C++ or C source would be ideal. Ideas are always welcome.

 Please e-mail your answers.

 Thanks for your help,


 Pedro.
--
Pedro Geraldes Freire             | BITNET/Internet: [e-mail]
Projecto CIMTOFI          |            UUCP: [e-mail]
UNINOVA - GRI - FCT/UNL           | Fax:   (+351) (1) 295 56 41/44 61
2825 Monte Caparica, PORTUGAL     | Phone: (+351) (1) 295 44 64 ext.1560
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 13:14:43 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Henk Miltenburg)
Subject: Flex problem on DEC Alpha
Message-ID: <[e-mail]>
Keywords: lex, question
Sender: [e-mail]
Organization: Philips Research Laboratories, Eindhoven, The Netherlands
Date: Fri, 19 Feb 1993 15:41:58 GMT
Approved: [e-mail]

Hi,

I've got a problem with a flex generated scanner on the DEC Alpha. I'm
running OPEN VMS.  Everytime my program enters the scanner, it loops. I
know it is somewhere in yylex.  Has anyone the same experience, and does
know what to do about it?  Is there a new version of FLEX which solves
this problem?  The scanner is generated on a standard VMS machine and is
running fine in this environment.  I'm using FLEX 2.3.  Please reply with
e-mail to [e-mail]

Thanks

Henk Miltenburg
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 13:15:20 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Preston Briggs)
Subject: Re: C++ symbol table
Message-ID: <[e-mail]>
Keywords: C++, parse
Sender: [e-mail]
Organization: Rice University, Houston
References: <[e-mail]>
Date: Fri, 19 Feb 1993 17:38:05 GMT
Approved: [e-mail]

[e-mail] (Joydip Dass) writes:

>I have got hold of Jim Roskind`s C++ grammar.  I have also modified his
>Flex input file to suit my purposes.  However, as he points out in his
>documentation, the lexer he supplied does not include a SYMBOL TABLE and
>does NOT KEEP TRACK OF CURRENT SCOPES.  I am in need of these
>facilities....

Thr Dragon Book is a good source for this stuff.

  title="Compilers: Principles, Techniques, and Tools",
  author="Alfred V. Aho and Ravi Sethi and Jeffrey D. Ullman",
  year=1986,
  publisher="Addison-Wesley"

Also, here's a relevant paper from one of the early compiler
construction conferences.

  title="Hashed Symbol Tables for Languages with Explicit Scope Control",
  author="Susan L. Graham and W. N. Joy and O. Roubine",
  pages="50--57",
  journal=sigplan,
  year=1979,
  month=aug,
  volume=14,
  number=8,
  note=pldi79


Preston Briggs
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 13:29:40 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Joel F Klein)
Subject: SML-NJ used in winning ACM student poster project
Message-ID: <[e-mail]>
Keywords: ML
Sender: [e-mail]
Organization: Computer Science Department at Rose-Hulman
Date: Fri, 19 Feb 1993 04:41:23 GMT
Approved: [e-mail]

Where: ACM Computer Science Conference 1993, Indianapolis
Event: student research poster competition
Date: Wed 17 Feb

The second-place winning entry (undergrad division) was the Prizm Toybox,
an integrated programming environment, designed for use in introductory
computer science courses.  The interpreter for this environment was coded
in SML-NJ, using SML-Lex and SML-Yacc for the lexer and parser.  The
interpreter is for the Prizm language, a Pascal-like language designed to
reduce the learning curve for the non-programmer students who take
Rose-Hulman's CS100, Introduction to Comp Sci.

The product will probably be distributed with source code, but it is still
under development. We just wanted to make this announcement for its news
value, and to toot the horns of Dave MacQueen and Andrew Appel, as well as
our own.  Our thanks to MacQueen and Appel for SML-NJ!

Todd R. Eigenschink and Joel F. Klein
Rose-Hulman Institute of Technology

--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 14:14:15 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Preston Briggs)
Subject: Re: Superoptimizers (was Re: Effectiveness of compilers today)
Message-ID: <[e-mail]>
Keywords: optimize
Sender: [e-mail]
Organization: Rice University, Houston
References: <[e-mail]> <[e-mail]>
Date: Fri, 19 Feb 1993 17:55:17 GMT
Approved: [e-mail]

[e-mail] (Dale R. Worley) writes:

>I've wondered if it's possible to have a program grovel the ASTs of a
>bunch of programs and extract out "common" combinations of operations that
>should be candidates for superoptimizer investigation.

One approach (which I associate with Davidson and Fraser) is to have the
compiler log exceptions (i.e., opportunities!) when it comes across them.

Consider my multiply example.  We've got some general method that does
pretty well and an exception table that we use to record cases where the
general method is known to be less than optimal (presumably we've
investigated all the integers up to some k, say 1000).  Anytime a number n
comes along that is bigger than k, we check the exception table.  If
present, we emit the translation.  If not present, we use our general
method and log the fact that some interesting new number has come along.
Run all your favorite code through the compiler (say, all the SPECmark
programs), then sic the exponential search on any numbers that show up in
the log.  If you find an improvement, add it to the exception table.

I'd don't really like the multiply example (kind of small potatoes), but
other more interesting examples are possible.  Davidson and Fraser used a
similar approach several years ago to build a peephole optimizer.

  title="Automatic Generation of Peephole Optimizations",
  author="Jack W. Davidson and Christopher W. Fraser",
  journal=sigplan,
  year=1984,
  month=jun,
  volume=19,
  number=6,
  note=pldi84,
  pages="111--116"

They use a slow but complete peephole optimizer at compile-generation time
to find patterns in a training set of programs.  The patterns are then
used to build a fast peephole optimizer for production use.

Preston Briggs
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 14:15:46 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Mike Albaugh)
Subject: Effectiveness of compilers
Message-ID: <[e-mail]>
Keywords: performance, assembler
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]>
Date: Fri, 19 Feb 1993 18:03:51 GMT
Approved: [e-mail]

ANDREAS ARFF ([e-mail]) wrote:
: Could someone tell me more about this. Are there any tests between common
: compilers and assembler programmers. Who is the best?

    In my experience with "simple" chips (68K, pdp11) there are three
important cases:

    Human "tweaks" assembly code output from compiler. This tends to
improve (or worsen) by the oft-quoted 10%.

    Human attempts to hand-compile significant piece of code directly
from HLL. This sometimes gets a gain of 2x, but can also be a disaster, as
human error takes its toll. On simpler chips, sufficient rigor can usually
make it work, but I wouldn't even attempt it on something like the i860.

    Human re-thinks algorithm in terms not constrained by the HLL.
This is where impressive gains can be made. My personal best data point is
an eight-fold improvement in a data-decompression routine. This was
measured against the "tweaked" output of a C compiler, and
accepted/produced the same data format dictated by the C version, so
correctness was relatively easy to determine. Implementing the same
algorithm in C was slower than the original, as it involved bit-pointers,
rotates, and co-routining. This is not to say that I was using any
particular feature of the specific chip (68k), but rather the sort of
operations that are common to a lot of chips, but difficult to express in
C. No, Herman, you don't need to add to this :-)

    The major problem with the perennial flame war is that it seems to
end up being cast as a battle between a _particular_ HLL (usually C, on
UseNet) and the grubbiest sort of "speed at any price" bit-twiddling. I
almost never code in octal, but rely on an "industrial strength" macro-
assembler and, when needed, write special-purpose programs to generate the
"assembly" code. Yes, sometimes I write directly in assembly, but only the
expectation that the code I write will go into a _lot_ of ROMS, or dire
need (Trap handlers come to mind) is sufficient to get me to do much of
that sort of thing...

    Of course, _sometimes_ I write in assembly for _fun_ :-)

                    Mike

| Mike Albaugh ([e-mail] || netcom.com!agames.com!albaugh)
| Atari Games Corp (Arcade Games, no relation to the makers of the ST)
| 675 Sycamore Dr. Milpitas, CA 95035        voice: [phone]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 23:45:33 EST 1993
Xref: iecc comp.compilers:4283 comp.parallel:5226
Newsgroups: comp.compilers,comp.parallel
Path: iecc!compilers-sender
From: Soohong Kim <[e-mail]>
Subject: Vectorizing/Paralllelizing C Compilers today?
Message-ID: <[e-mail]>
Keywords: C, parallel, question
Sender: [e-mail]
Organization: Compilers Central
Date: Fri, 19 Feb 1993 19:53:19 GMT
Approved: [e-mail]

Hello,

    I am interested in " Vectorizing/Parallelizing C compilers" and
would like to know the current research status.

    Most of the parallel compiler research is for FORTRAN.

    Please let me know of commercial products and research projects
for Vectorizing/Parallelizing C compilers.

Thanks in advance.

Soohong Peter Kim
[e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 23:46:47 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (David Chase)
Subject: Re: C++ symbol table
Message-ID: <[e-mail]>
Keywords: C++, parse
Sender: [e-mail]
Organization: Sun
References: <[e-mail]>
Date: Fri, 19 Feb 1993 20:12:18 GMT
Approved: [e-mail]

[e-mail] (Joydip Dass) writes:
> [desperately seeking symbol table.]

I don't have a complete answer, but I do have a suggestion.  There was a
nifty trick proposed by Paul Dietz in STOC '81, and it has been used with
some success by several people that I know (in fact, it has been
rediscovered with some success by several people, and we (= me, Wegman,
Zadeck) used it in a different context to get good time bounds for a sort
of incremental SSA.  The "trick" is that instead of posing the problem as

  given location (scope) what symbol table do I use?
  given symbol table, what is the information for symbol "foo"?

you invert it, as in

  given a symbol "foo", what "scope table" do I use?
  given a scope table and a location, what information do I have?

The next part of the trick is to encode the "scopes" appropriately.  Dietz
proposed to do this (I'm working from memory, so the errors are probably
mine) by recording the entry and exit numbers for each node in a
depth-first walk of the block-structure of the program (watch out for
Duff's device in C).  Each new declaration of a variable V is assoicated
with a block, and to record that declaration you enter the entry and exit
numbers in V's scope table.  The exact structure of the scope table is
left as an exercise, but for small numbers of declarations (usual case),
something based on linear search will probably serve well.

So, your lookup algorithm becomes something like:

  use hash table to get a scope table, given an identifier.
  use scope table to get information, given a location.

This has been used in an attribute grammar system (Rodney Farrow of
Declarative Systems) because the symbol tables produced in this way can be
made to appear "applicative", yet are efficient in terms of both time and
space.  It also helps in the situation where there may not be a
declaration, because you have handy access to any declarations that there
might be.

For C++, note that your notion of "scopes" may be very fine-grained, and
probably does not correspond one-to-one with curly braces.  You'll also
need something to cope with the scopes associated with different types.

I hope this helps.

David Chase
Sun
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 19 23:47:51 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Byron Rakitzis)
Subject: Re: object code vs. assembler code
Message-ID: <[e-mail]>
Keywords: assembler, performance
Sender: [e-mail]
Organization: Network Appliance Corporation
References: <[e-mail]>
Date: Sat, 20 Feb 1993 01:18:33 GMT
Approved: [e-mail]

[e-mail] writes:
>Obviously it is possible for a compiler to produce object code directly
>which seems to be the standard on many other systems which seems much more
>efficent to me.

>[Mostly it's a matter of taste.  Some Unix assemblers, particularly the
>earlier ones, were very fast, so there needn't be a performance issue. -John]

Here are some real numbers to play with:

I ran the various stages of gcc-1.40 on 39 source files (about 7000 lines
of code) and timed each stage. These tests were run on a diskless Sun ELC
w/24M running 4.1.1.

    Program    User+Sys   Total

    cccp    2.4+6.8  == 9.2

    cc1    25.4+6.5 == 31.9

    /bin/as    5.0+6.3  == 11.3

So, assembly takes up about 20% of the total time. That's not
insignificant.

If you run a compiler with a faster code generator (such as lcc), then the
middle stage should be smaller by about a factor of 2 or 3, so assembly
can be as much as a quarter or a third of the total execution time.

(So why emit assembler? One of my long-term projects is to write a code
generator for lcc to use SPARC without register windows. I will initially
generate assembler, because it's the quickest way to get code working
(mainly because it's easy to debug). Eventually I would like to think
about generating object code directly, particularly if I try to
investigate some ideas related to linking (incremental linking, global
pointer..) where a new object format might be called for.  I am
structuring the code so that switching from one to the other will require
a trivial amount of work.)

Byron Rakitzis.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sun Feb 21 18:23:11 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (James Kanze)
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: optimize
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]> <[e-mail]>
Date: Sat, 20 Feb 1993 14:04:00 GMT
Approved: [e-mail]

Joe Buck ([e-mail]) writes:

|> [ about the Gnu superoptimizer]

The following code sequence was presented in the original article.

|>   Faster 80x86 code than the standard cmpl/seta/and for
|>   ecx = ((unsigned) eax > (unsigned) edx):
|>           cmpl    %eax,%edx
|>           sbbl    %ecx,%ecx
|>           negl    %ecx

An interesting point.  This code sequence is a well known trick regularly
used by 8086 assembly programmers 10 years back.  So it should hardly
require a super-optimizer to find it.  In fact, PL/M86 regularly generated
such sequences, way back in 1979!  (Actually, since PL/M defined FALSE as
0xff, it didn't need the final neg.)  If my memory serves me right, this
was just a carry over from PL/M80 (earlier than 1976?).

So modern compilers require a "superoptimizer" just to obtain what was
very run-of-mill code 10 years ago?  I wonder if this has something to do
with the fact that modern compilers are written by software shops (FSF,
AT&T, etc.), whereas the original PL/M was written by the chip
manufacturer.  So 10 years ago, the compiler writers knew the target
machine intemately, whereas now, they try and find a general solution for
all machine architectures.  Nevertheless, the above optimization is a win
on most conventional architectures, so there is no excuse for GNU (and
even less for Microsoft and Borland, who make strictly Intel compilers) to
not use it.

I suspect that where the assembler programmer gets the most wins is not
the really small sequences, but in the medium length stuff.  And I also
suspect that assembly programming pays off more in unorthogonal
architectures (like the 80x86) than in orthogonal ones (like the NSC
32000).
--
James Kanze                             email: [e-mail]
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sun Feb 21 18:24:25 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: Paul Robinson <[e-mail]>
Subject: Program Analysis (Was: Superoptimizers)
Message-ID: <[e-mail]>
Keywords: optimize
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]> <[e-mail]>
Date: Sat, 20 Feb 1993 21:07:37 GMT
Approved: [e-mail]

> I've wondered if it's possible to have a program grovel the ASTs of a
> bunch of programs and extract out "common" combinations of operations that
> should be candidates for superoptimizer investigation.

I'm not sure what you mean by "grovel the ASTs" but let's say that you
mean to analyze common program executions or sources to see what they are
doing.  The only problem in doing this is to get people to let you see
their code.

Read "The Psychology of Computer Programming" for an issue about this for
the exact same reason: some people wanted to analyze the errors people
were getting in their programs to see if better error messages or analysis
could be done to improve the way the system works.  For most people, it
was the equivalent of pulling teeth without anesthesia to get them to give
up their programs because people don't want to admit they've made
mistakes; programs are extremely personal, because of the fact they do
things, I believe that the attachment people can have with software
borders on the attachments between people and their offspring.

You might try going through the source code libraries of stuff on
Internet, but then again, that may be atypical since any sources there are
ones that have been "cleaned up" for the public to see.  If you want to
look at the grungy, dirty code that people write real applications in, you
are going to have to be about as circumspect as a man trying to propose
adultery to someone's otherwise faithful wife!  People's programs are
extremely personal to them.

I once wanted to find out about developing an MTA (Message Transfer Agent)
for a certain class of message processing.  The operator of one message
service had written the program to do this on his own.  I had already
written the User Agent to handle messages locally; so I asked him about
making the program available so I could implement it elsewhere and make a
split of profits from the sale.  Even though I had no intention of selling
source, and he wasn't even using the program any more, he was afraid to
let anyone else see it because it was so hastily written and very ugly in
his opinion; he didn't want anyone to know how bad it looks like.  Ugly
code always gets the Cinderella treatment.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sun Feb 21 18:26:09 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Henry Spencer)
Subject: Re: object code vs. assembler code
Message-ID: <[e-mail]>
Keywords: assembler
Sender: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]>
Date: Sun, 21 Feb 1993 00:35:18 GMT
Approved: [e-mail]

[e-mail] writes:
>Is there any good reason why many compilers produce assembly language as
>this seems to be a big performance hit with no gain by doing this. I can't
>see that producing obejct code is *that* much harder.

Depends on what machine you're on.  Back when the 68000 was new, a friend
of mine -- in the thick of 68k compiler work at the time -- said that his
experience was that it was harder to write the assembler than the compiler
code generator.  (The 68000 instruction encoding is a bit ugly.)

The advantages of producing assembler output are basically:

1. It's less work for the compiler writer.  Emitting instructions is
    typically no big deal -- writing `emitw(010213)' is not much
    harder than writing `emit("mov r2, *r3")' -- but getting the
    symbol tables right can be complicated.

2. ASCII output makes debugging simpler.  You need *some* way to read
    the final output...

3. All the knowledge of how to generate actual object modules can be
    centralized in one place.  This is a non-trivial issue if the
    format is complex or if it ever has to change, and it means
    that bug fixes can be applied in one and only one place.

4. The assembler may perform non-trivial optimizations, e.g. filling
    delay slots, that strengthen point #3.  Not uncommon nowadays.

The main disadvantage is that an incompetently-implemented assembler can
make the overall process seriously slower.  And even with a good
implementation, you necessarily take some efficiency hit in having the
assembler rediscover things like symbol-table contents that the compiler
already knows.

An interesting angle on this issue is what Plan Nine did (take a look at
research.att.com/dist/plan9doc/8.Z [it's PostScript] for details).  The
compiler's output is essentially what you'd get out of the first pass of
an assembler -- a binary form of assembler.  (There is an assembler, a
small program that turns a suitable text form into the binary form.)  The
loader incorporates most of what's normally in the second pass of an
assembler, plus the usual linker functions, plus assorted optimizations.

The paper does mention one unhappiness with this setup: compiling of
multiple source files is trivially parallelizable, but the final loading
step isn't, so there is interest in moving some of the loader's work back
into the compiler.  This would presumably result in something closer to
the traditional model.

(One note of caution: as was recently discussed here, the paper's
code-efficiency comparison to GCC is suspect because it probably used an
old and poorly-tuned GCC.)
--
Henry Spencer @ U of Toronto Zoology |  [e-mail]  utzoo!henry
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sun Feb 21 18:29:32 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (David Keppel)
Subject: Re: Superoptimizers (was Re: Effectiveness of compilers today)
Message-ID: <[e-mail]>
Keywords: optimize, bibliography
Sender: [e-mail]
Organization: Computer Science & Engineering, U. of Washington, Seattle
References: <[e-mail]> <[e-mail]>
Date: Sun, 21 Feb 1993 02:02:27 GMT
Approved: [e-mail]

>[e-mail] (Dale R. Worley) writes:
>>[Can a program grovel the ASTs of a set of programs and extract
>> "common" combinations of operations that should be candidates for
>> superoptimizer investigation?]

[e-mail] (Preston Briggs):
>[Davidson and Fraser 84 automatic generation of peephole optimizers.]

See also:

%A Robert R. Henry
%T Code Generation by Table Lookup
%R 87-07-07
%I University of Washington Computer Science
%D 1987
%X The code generator is ``trained'' by feeding it sample input DAGs.
Special patterns are generated for DAGs that occur frequently.  Thus,
the machine description is augmented with (virtual) instructions that
correspond to frequently-occuring DAGs.

        ;-D on  ( Dr. Seuss-peroptmizers )  Pardo
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sun Feb 21 18:30:25 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Tony Sloane)
Subject: Re: C++ symbol table
Message-ID: <[e-mail]>
Keywords: tools, bibliography
Sender: [e-mail]
Reply-To: [e-mail]
Organization: University of Colorado at Boulder
References: <[e-mail]> <[e-mail]>
Date: Sun, 21 Feb 1993 04:14:40 GMT
Approved: [e-mail]

The Eli system (see recent announcement in comp.compilers or send me mail
for information) provides a flexible module for handling general scoping
issues.  Eli does much more than this (try it :-) but you can use the
module independently (it's written in C).  For a description, see the
following paper:

%A U. Kastens
%A W. M. Waite
%J Acta Informatica
%P 539--558
%T An abstract data type for name analysis
%V 28
%D 1991

Tony
--
Tony Sloane                     [e-mail]
Department of Computer Science, University of Colorado at Boulder
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sun Feb 21 18:32:29 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Tim Channon)
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: performance, assembler
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Compilers Central
References: <[e-mail]>
Date: Fri, 19 Feb 1993 00:31:49 GMT
Approved: [e-mail]

> Could someone tell me more about this. Are there any tests between common
> compilers and assembler programmers. Who is the best?

Most of the posts in response to this question seem to look at it
(surprise) from the viewpoint of handcoding the same problem as that
presented to a compiler but IMO this is not at all representative because
assembler programmers in my experiance even think differently! Or as we
shall see do they?

I was recently party to a long discussion to do with this where it was
being discussed by predominately assembly programmers. A number of points
arose with perhaps one of the more common ones being stack usage where
compilers tend to but humans don't. Variable allocation tends to be
completely differently done and so on.

Looking at compiler produced code and having trouble improving it doesn't
surprise me because a human probably decided that was good code to produce
given the HL source.

Could an assembler programmer improve on an FFT library routine? I doubt
it.  You see most of this compiler generated code is actually assembler
written on behalf of the compiler author(s). :-)

I expect there are some of the best assembly programmers of the lot here
in this group and they pass this knowledge on in the form of compilers.

All IMO.

  TC.
    E-mail: [e-mail] or [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb 22 18:05:01 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Clyde Smith-Stubbs)
Subject: Re: object code vs. assembler code (Detailed response)
Message-ID: <[e-mail]>
Keywords: assembler, performance
Sender: [e-mail]
Organization: HI-TECH Software, Brisbane, QLD, Australia.
References: <[e-mail]> <[e-mail]>
Date: Mon, 22 Feb 1993 00:32:24 GMT
Approved: [e-mail]


[e-mail] writes:
>Obviously it is possible for a compiler to produce object code directly
>which seems to be the standard on many other systems which seems much more
>efficent to me.
>[Mostly it's a matter of taste.  Some Unix assemblers, particularly the
>earlier ones, were very fast, so there needn't be a performance issue. -John]

[e-mail] (Byron Rakitzis) writes:
>... assembly takes up about 20% of the total time. That's not insignificant.

Well, here's a perspective from a compiler writer: the 20% mentioned that
assembly time takes up agrees with my experience, and speeding up the
assembler is a useful exercise if you want to speed up the compiler. But
compile time is these days much less of an issue than it used to be (I
speak here with experience ranging from CP/M on a Z80, through PDP11's,
Vaxes etc. right up to current Sparc, 80486 systems etc.). Compile time on
CP/M is a major issue, on a Sparc or 486 it becomes much less so. The
trend is clear: processors are getting faster at a rate outstripping the
tendency of compilers to do more work.

The issues affecting assembler vs. object code as I've seen them over the
years are these:

Firstly, my customers overwhelmingly tell me they like being able to read
the compiler output. In fact a significant effort goes into making the
output readable (formatting, source code as comments, notes about register
allocation etc.).  I can recall very few occasions (none in recent years)
where a user would have happily traded this for slightly faster
compilation. This alone is a good enough reason to generate assembler code
(at least optionally).

Secondly, the assembly stage is inherently multi-pass. I know there exist
single pass assemblers, but they effectively defer work to the linker. I
believe most compilers that output object code do so the same way, i.e.
they produce lots of forward references and backward fixups (or some
equivalent thereto). This prevents the optimization of calls, branches
etc. and other things a multi-pass assembler can do.

Thirdly, and most important from my point of view, a compiler that
produces object code directly is actually producing machine language as
opposed to assembler language. Most assembler languages are a
meta-language to some degree or other. In particular, many processors
(especially CISC) have instructions that look similar at the assembler
level, but have totally different binary encodings. An assembler is
designed to handle this, but it's extra work to do so in a compiler. For
example, in the 8086 instruction set, the instructions

    inc    si
and
    inc    -4[bp],word

have totally different encodings. A compiler generating object code has to
handle this somehow, either by treating these two case as separate, e.g.
something like

    i += 1;

might be matched by templates

    ASPLUS register_variable constant_one -> emit(0x40 + reg(left));
or
    ASPLUS memory_location constant_one   -> emit(0xFF); emitmemop(left);

rather than the generic

    ASPLUS lvalue constant_one          -> emit("inc"); emitop(left);

OR the compiler has to examine the expression after matching and decide,
based on the operands as well, what instruction to generate. In this case
it is doing the same job as an assembler. The same applies to the 68K
where you need to worry about things move vs. moveq vs. movea. On a RISC
chip where all instructions fall into two or three formats it's less of an
issue.

None of what I've said makes it impossible to generate object code. It
does indicate (at least to me) that it is more difficult, especially if
you're dealing with a portable compiler (I've written compilers for about
12 different processor families).  The benefits are small - slightly
better compile time. Using assembler output seems to me to allow the
compiler writer to concentrate more on good code generation, and less on
idiosyncracies of the instruction set encoding.

I suspect also that some compiler writers tend towards emitting object
code simply because that's what they're used to doing, or that's what they
got taught. Certainly the compiler projects I did at uni. were oriented
towards object code production, but all the real compilers I've dealt with
produce assembler code.
--
 Clyde Smith-Stubbs       | HI-TECH Software,       | Voice: [phone]
 [e-mail]      | P.O. Box 103, Alderley, | Fax:   [phone]
 ...!nwnexus!hitech!clyde | QLD, 4051, AUSTRALIA.   | BBS:   [phone]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb 22 18:06:24 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Frederick Korz)
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: performance, bibliography
Sender: [e-mail]
Organization: Columbia University Department of Computer Science
References: <[e-mail]> <[e-mail]>
Date: Mon, 22 Feb 1993 17:13:16 GMT
Approved: [e-mail]

[e-mail] (David Keppel) writes:
>I've forgotten where Henry Massalin's original Superoptimizer paper
>appeared, but it *may* be available as an online TR from
>`cs.columbia.edu'.

  H. Massalin, "Superoptimizer: A Look at the Smallest Program,"
  Proceedings ASPLOS II, October 1987, Palo Alto, CA., (a joint ACM,
  IEEE work, published by IEEE Computer Society Press, IEEE
  #87CH2440-6, ACM Order # 556870)


Fred Korz            450 Computer Science Building
[e-mail]        Columbia University
[phone]            NY, NY  10027 (USA)
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Mon Feb 22 18:11:43 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Richard Gorton)
Subject: Re: Object vs. Assembly from a compiler
Message-ID: <[e-mail]>
Keywords: assembler, performance, comment
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]> <[e-mail]>
Date: Mon, 22 Feb 1993 18:30:02 GMT
Approved: [e-mail]

> [e-mail] writes:
> Is there any good reason why many compilers produce assembly language as
> this seems to be a big performance hit with no gain by doing this. I can't
> see that producing obejct code is *that* much harder.
>
As the moderator notes:
[Mostly it's a matter of taste.  Some Unix assemblers, particularly the
earlier ones, were very fast, so there needn't be a performance issue. -John]

Another point to consider is how much one trusts the native assembler.
Generating assembly code is just fine if the native assembler is stable,
and correct.  But if the assembler is changing and/or buggy, then
generating object code may turn out to save you lots and lots of
bug-hunting headaches.  Particularly if you don't have control of or
access to the assembler sources.

For example, some assemblers may not permit expressions involving
relocation, such as:

    sethi    %hi(_foo)+0x1000, %g2
    ld    [%g2 + %lo(_foo)+1000], %i2

but will take:
    sethi    %hi(_foo), %g2
    or    %g2, %lo(_foo), %g2
    ld    [%g2 + 1000], %i2

But a compiler generating object code is free to utilize the first form.

Richard Gorton        Alpha AXP Migration Tools - Digital Equipment Corp.
Reply-to: [e-mail]
[Is that an assembler limitation or a problem in the object format? -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 23 13:08:18 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: Michael Dyck <[e-mail]>
Subject: parser-generators for RRPGs: summary
Message-ID: <[e-mail]>
Keywords: parse, summary, EBNF
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]>
Date: Mon, 22 Feb 1993 23:35:04 GMT
Approved: [e-mail]

I wrote:
> 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".
> ...
> What parser-generators are available that accept some form of RRPG?

Here's a summary of the replies. Thanks to:

Kiong Beng Kee        [e-mail]
Karsten Nyblad        [e-mail]
Anton Ertl            [e-mail]
Todd Jonker           [e-mail]
Tim Channon           [e-mail]
Paul Oude-Luttighuis  [e-mail]
Taylor Hutt           [e-mail]
Terence J Parr        [e-mail]
Thomas Reid           [e-mail]
Judith Grass          [e-mail]
Xorian Technologies   [e-mail]

I have divided RRPG parser-generators into three categories, according
to the approach taken.

Convert the RRPG to a CFG and use a 'conventional' parser generator:
--------------------------------------------------------------------

Lalr, Ell (in Cocktail toolkit [formerly called Toolbox?])
  GMD Forschungsstelle an der Universitaet Karlsruhe
  [e-mail]
  ftp: ftp.gmd.de:gmd/cocktail

ESP (Extensible Syntax Parser)
  work-in-progress
  Todd Jonker at CMU
  (uses a Tomita parallel parser to do the parsing)

Generate a top-down parser directly from the RRPG:
--------------------------------------------------

reference:
  Barrett, Bates, Gustafson, and Couch
  "Compiler Construction - Theory and Practice, 2nd Edition",
  pp. 167-173
  (see article 93-02-024)

ANTLR,  the parser-generator in PCCTS
  (Purdue Compiler Construction Tool Set)
  (see article 93-02-009)
  ftp: marvin.ecn.purdue.edu:pub/pccts/1.06

Gray
  written in Forth
  available from [e-mail]
  (see article 92-05-111)

Generate a bottom-up parser directly from the RRPG:
---------------------------------------------------

LADE  (LAnguage Definition Environment)
  Xorian Technologies Pte. Ltd
  (see article 92-05-061)

LALR
  ProSoft (formerly LALR Research)
  (see article 93-02-005)

Yacc++
  Compiler Resources, Inc.
  (see articles 92-06-142, 91-12-061, 91-09-005, 91-08-132, 91-04-071,
   and 91-03-095)

Ryacc
  Judith Grass at AT&T Bell Labs
  in-house research prototype
  Has "several (hefty) papers on Ryacc that are distributable."
  (see article 91-05-069)

?
  work-in-progress
  Karsten Nyblad at TFL, A Danish telecommunications research lab
  (see article 91-05-076)

---------------------------------------------------

Also, there are lists of references on RRPGs in
  91-05-069
  91-05-076
  92-06-111

-Michael Dyck, [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 23 13:12:24 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Bill Nell)
Subject: question to PCCTS users
Message-ID: <[e-mail]>
Keywords: PCCTS, question
Sender: [e-mail]
Organization: Siemens Corporate Research, Princeton (Plainsboro), NJ
Date: Tue, 23 Feb 1993 14:23:37 GMT
Approved: [e-mail]

I have a couple questions about PCCTS (v1.06) that hopefully some of the
PCCTS users out there can answer.

1) When compiling antlr with itself I get the following warnings.

../bin/antlr antlr.g
Antlr parser generator   Version 1.06   1989-1992
antlr.g, line 345: warning: optional path and alt(s) of (..)* ambiguous upon
     { "#errclass" }
antlr.g, line 454: warning: alts 1 and 2 of {..} ambiguous upon { Action }
antlr.g, line 525: warning: alts 1 and 2 of {..} ambiguous upon { Action }
antlr.g, line 583: warning: alts 1 and 2 of {..} ambiguous upon { PassAction }
antlr.g, line 587: warning: alts 1 and 2 of {..} ambiguous upon { "\>" }
antlr.g, line 599: warning: alts 1 and 2 of {..} ambiguous upon { PassAction }
antlr.g, line 609: warning: alts 1 and 3 of (..) ambiguous upon { "\*" }
antlr.g, line 610: warning: alts 2 and 3 of (..) ambiguous upon { "\+" }
antlr.g, line 613: warning: alts 1 and 2 of {..} ambiguous upon { PassAction }
antlr.g, line 615: warning: alts 1 and 2 of {..} ambiguous upon { PassAction }

Is this normal?

2) The documentation that comes with PCCTS says that using multiple parsers or
calling a single parser multiple times does not work.  But, in the BUGS100
file it says:

(11) As per the manual, PCCTS had a problem with multiple ANTLR  macro
     invocations.   This has been fixed (we think).  In file dlgauto.h
     in the pccts/h directory make the following additions:

... bug fix stuff deleted ...

You should be able to do this:

parse(f1,f2)
FILE *f1, *f2;
{
     ANTLR(grammar(), f1);
     ANTLR(grammar(), f2);
}

Before, the second invocation of the ANTLR macro did not know that it
needed to get another character before beginning.  Let us know if this
screws up anything else.  Be aware that switching between input streams
will not work because characters are lost when switching to a new stream.


My questions are: Do multiple parsers/multiple parser invocations work
now?  And, I am confused about the last line in the last paragraph.  To me
it basically means that a PCCTS lexer/parser would not be able to handle
things like #include files, where you would have to switch the input
buffer to read from a new file.  Is this what that last line really means?


Thanks in advance for any help.
Bill

--
[e-mail]
Siemens Corporate Research
755 College Road East
Princeton, NJ 08540
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 23 13:13:32 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (BO/EBC/KX/ZG Michael Bergman 682 4958)
Subject: Chomsky Normal Form and parsing
Message-ID: <[e-mail]>
Keywords: parse, question
Sender: [e-mail]
Organization: Compilers Central
Date: Tue, 23 Feb 1993 17:17:35 GMT
Approved: [e-mail]

Hi everyone,
I have some more entangled(?) questions on CFG's.

This time it's Chomsky and Greibach normal forms I'm interested in.

"Languages and Machines" by Tomas A. Sudkamp [1988]
ISBN 0-201-15768-3
Addison-Wesley

contains some interesting stuff. A friend of mine had this at hand, so I
cite him:

Definition Chomsky Normal Form:

Grammar G = (V,Sigma,P,S) (Variables, alphabet, productions, start) All
productions are in one of the forms:

    1. A -> BC
    2. A -> a
    3. S -> epsilon

    B and C != S, A is arbitrary (specifically, it can be S)
    (Note that S is the only production that can have an epsilon.)

Theorem:

"Let G =(V,Sigma,P,S) be a CFG. There is an algorithm to construct a
grammar G' = (V,Sigma,P',S) in Chomsky NF that is equivalent to G."


Note that there are no other restrictions here, according to Sudkamp this
works on all CFG's.
These steps are used in the conversion:
1. Make S non-recursive
2. Eliminate all epsilon except the one in S (if there is one)
3. Eliminate all chain rules
4. Remove useless symbols (the ones not used in any production).

(After this, one can eliminate left-recursion to make it predictive
parseable.)

The question is: what's the practical use of this?
Can we parse this Chomsky Normal Form for sure using some parsing method?
Which one in that case? (I do suspect the answer is no... :-(
If not, are there some "well" defined restrictions one can put on the CFG
(e.g. unamiguity) to make the parsing possible or even more feasible?

There is also the Greibach NF which probably is better for LL/predictive
parsing, it is inherently non-left recursive for example.  The problem is
that the conversion is *nasty*, having exponential behaviour in the worst
case.  Is there a theorem stating that it is always possible to convert to
Greibach NF?  Apparently, the theorem above says that for Chomsky NF.

[added later -John]
I just found a comment on this in a comp.compilers article from May 1992:

Jonathan Eifrig ([e-mail]) writes:

> We want don't so much want to recognize a
> *language* so much as generate a parse tree of the input for a particular
> grammar.  The *grammar* itself is important; if one has to contort the
> "natural" grammar (i.e., the one that matches the semantic grouping) of
> language in order to accomodate our parsing scheme, this is a serious dis-
> advantage.  This is why, for example, we don't just convert our ambiguous
> grammars into Chomsky normal form and apply the obvious dynamic
> programming parsing scheme.  We'll see in a minute that both LL(k) and
> LR(1) parsing schemes suffer from this problem.

I guess that says it all unless someone else has any comments.

However, since it is possible to do the conversion at least
semi-automatically, maybe one could try it and see if the result is
acceptable or not. I haven't tried this myself so I don't know what it
looks like (but I can imagine it will be pretty difficult to read).

So - what's the "dynamic programming parsing scheme"? I'll be happy with
an overview of the method + a pointer to any refs if there are any.

M
--
Michael Bergman                Email: [e-mail]
KX/ZGE                    Tfn:   [phone]
Ericsson Business Networks
S-135 83 Tyreso, Sweden
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 23 15:31:23 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Jon Forrest)
Subject: Another Issue in Compiler Generated Assembly Code
Message-ID: <[e-mail]>
Keywords: assembler, comment
Sender: [e-mail]
Organization: University of California, Berkeley
Date: Tue, 23 Feb 1993 18:27:01 GMT
Approved: [e-mail]

Another issue for compiler writers to keep in mind is that if their
compiler produces assembly code, then it should 1) produce assembly code
that the assembler can actually assemble, and 2) produce assembly code
that, when assembled, is the same as the object code produced by the
compiler.

I used to work at one of the major database vendors in the VMS development
group. We found that the VMS C compiler didn't do either.  #1 is obvious
since the compiler puts all kinds of listing information and other cruft
in the assembler output. But, by clever use of awk filters on Unix we were
able to get around this. What was worse was #2. The compiler would
generate floating point constants in the assembler that used the wrong
syntax so that the end result was different code than that produced by the
compiler.

To top it off, what was even worse than either of these was the admittedly
unofficial reaction of the C compiler engineers I described this to at a
DECUS meeting. They said that since the compiler obviously didn't produce
assembler code to be compiled that they didn't think that #2 was a bug or
even worth thinking about.
--
Jon Forrest WB6EDM     [e-mail]     510-643-6764
[It's quite typical for compiler listings of assembler output not to be
legal assembler input.  Compiler authors are rarely sympathetic to the
thought that you might massage their assembler and assemble the result --
after all, if it were possible to make the assembler output better, they
would already have done so. -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 23 18:01:56 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Greg Morrisett)
Subject: 1st CFV: comp.lang.ml
Message-ID: <[e-mail]>
Followup-To: news.groups
Originator: [e-mail]
Keywords: ML, administrivia
Sender: [e-mail]
Organization: School of Computer Science, Carnegie Mellon
Date: Tue, 23 Feb 1993 18:57:28 GMT
Approved: [e-mail]

Following the required discussion period, in which consensus appears to
have been reached, this is the first call for votes for the creation of
comp.lang.ml.  This note contains information about the proposed group and
voting instructions.  Please read the entire post before responding.  In
particular, please read the "How to Vote" section before responding.

----------------------------------------------------------------------------
                            1st CALL FOR VOTES

Proposed Newsgroup:  comp.lang.ml
------------------
              Type:  Moderated
              ----
         Moderator:  Greg Morrisett, Carnegie Mellon, [e-mail]
         ---------           (submission address to be announced.)
       Description:  Discussion about the family of ML languages including
       -----------     but not limited to Standard ML, CAML, Caml-light, and
                       Lazy ML.

Charter:
-------
  Comp.lang.ml is a moderated newsgroup exclusively for discussion
  of ML.  ML is a family of advanced programming languages with [usually]
  functional control structures, strict semantics, a strict polymorphic type
  system, and parametrized modules.  It includes Standard ML, Lazy ML,
  CAML, CAML Light, and various research languages.  Implementations are
  available on many platforms, including PCs, mainframes, most models of
  workstation, multi-processors and supercomputers.  ML has many
  thousands of users, is taught at many universities (and is the first
  programming language taught at some).

  Topics for discussion would include (but are not limited to):
   * general ML enquiries or discussion
   * general interpretation of the definition of Standard ML
   * applications and use of ML
   * announcements of general interest (e.g. compiler releases)
   * discussion of semantics including sematics of extensions based on ML
   * discussion about library structure and content
   * tool development
   * comparison/contrast with other languages
   * implementation issues, techniques and algorithms including extensions
       based on ML

Moderation Guidelines:
----------------------
  The moderator will maintain and post weekly and monthly frequently
  asked questions (FAQ) lists.  Moderation will be done according to
  the following guidelines:

    1. An article that has no relevance to ML will be rejected by the
       moderator.  However, the moderator will attempt to tell the
       poster a more appropriate place for the article.

    2. An article might be rejected if the poster asks a question that
       is answered by the FAQ lists.  However, the moderator will forward
       the relevant portion(s) of the FAQ answers to the poster.

    3. The moderator reserves the right to trim down quotations of
       previous articles and to reject articles consisting essentially
       of quotations.

    4. The moderator reserves the right to send a "poorly" written article
       back to the poster, requesting that it be re-written.

    5. All other articles will be forwarded by the moderator.

    6. The moderator might add his/her own comments at the end of an
       article, such as [See the Commentary, pp.123-125] or
       [This question has been asked several times in the past, and
       never got an answer.]

Moderator Changes:
------------------
  Guidelines for the removal or change of a moderator are as follows:

    1. An RFD on the removal of the moderator must be posted to
       news.announce.newgroups, news.groups, and comp.lang.ml.
       with the follow-ups sent to news.groups.

    2. Should there be a consensus that a vote is appropriate, a
       CFV will be issued by a third party, to last not less than
       two weeks and not more than 30 days. This ballot will include
       the following options:

                    a. Should the moderator be removed? (Y/N)
                    b. The new moderator should be: (names)

    3. If more than 2/3 of the voters agree that the moderator should
       be removed, and there are no more than 100 no votes, then the
       top name in section b becomes the new moderator. Each ballot
       can contain a vote for one and only one new moderator.

Justification:
-------------
  There is currently a group for ML in the alt hierarchy, alt.lang.ml.
  This has the disadvantages of any alt group: narrow distribution
  (especially outside the US, where much ML development goes on) and
  fast expiration. Some discussion of ML has gone on in
  comp.lang.functional and in comp.lang.misc.  An ML-specific newsgroup
  would concentrate these postings and provide a focus for people
  seeking information about or discussion of the language.

  There is also a moderated worldwide mailing list for Standard ML users
  maintained at Carnegie Mellon University and a mailing list for CAML
  users maintained at INRIA.  There are now several thousand readers of
  these lists. Currently several messages pass through these lists
  each week.  We do not propose the abandoment of these lists, but a
  moderated newsgroup would take most of the traffic from each of these
  lists and would provide a new forum for questions general to the
  family of ML languages (not just SML or CAML).

  People who cannot or do not want to read the newsgroup, can subscribe
  to the SML-LIST.  As maintainer of the list, I will cross-post messages
  from the newsgroup to the mailing list and vice-versa.

  We have chosen "comp.lang.ml" as a name, patterned after other newsgroups
  that discuss programming languages, such as "comp.lang.scheme".  We have
  chosen the ".ml" suffix to remind people that the newsgroup is open
  to all dialects of ML.  While some readers might mistakenly assume
  ".ml" stands for "machine language" or "machine learning", the moderator
  will prevent irrelevant posts from reaching readers and the FAQ lists
  will clear up any confusion.

Voting Period:
-------------
  Votes will be taken from 08:00:00 EST, February 23, 1993
  until 23:59:59 EST, March 20, 1993.

How to Vote:
-----------
  To vote "Yes", send mail to "jgmorris=[e-mail]".

  To vote "No", send mail to "jgmorris=[e-mail]".

  Votes sent to these addresses are differentiated by mailing address
  _only_;  message contents and subject lines are ignored since the
  votes are processed by an automated script.

  If your mailer cannot handle one of these addresses, send your
  vote to "[e-mail]" making sure to clearly specify whether
  you vote for or against the proposed newsgroup.  Use the following
  format in your message body:

    "I vote [Yes/No] for comp.lang.ml."

  If your message is ambiguous, it will not be counted (though I will
  attempt to return your message to you, asking for an unambiguous vote.)

  Your vote will be acknowledged by email.

Reminder of Voting Rules:
-------------------------
  - One vote per person.  If you vote more than once, only the most
    recent vote will be counted.

  - Votes must be mailed to one of the above addresses.  No proxy
    voting, forwarding, etc.  Posted votes (to any newsgroup or
    mailing list) will not be counted.

  - I will not be able to discuss the vote results until after the
    poll closes, so please do not ask how the vote is going.

  - Votes received outside of the voting period will be ignored.

Thanks and remember that your vote counts!
--
-Greg Morrisett
 Carnegie Mellon Univ.
 [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 23 23:29:49 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Hans de Vreught)
Subject: Re: Chomsky Normal Form and parsing
Message-ID: <[e-mail]>
Keywords: parse, question
Sender: [e-mail]
Organization: Delft University of Technology
References: <[e-mail]>
Date: Tue, 23 Feb 1993 23:05:51 GMT
Approved: [e-mail]

[e-mail] (BO/EBC/KX/ZG Michael Bergman 682 4958) writes:
>Hi everyone, >I have some more entangled(?) questions on CFG's.

>This time it's Chomsky [...] normal forms I'm interested in.

>The question is: what's the practical use of this?

If we would leave the linguistic stuff aside (Noam Chomsky is a linguist), it
gives you a very simple form of a grammar caple to generate any CFL. That is
very practical in formal language proofs: you may assume the grammar for a CFL
is in CNF.

>Can we parse this Chomsky Normal Form for sure using some parsing method?

Furthermore, because any CFG can be put into CNF it is sufficient to have
a parser for grammars in CNF. Such a parser does exist. The
Cocke-Younger-Kasami algorithm is exactly such an algorithm. The CYK
algorithm is very simple and run in O(n^3) time. Since it can handle
ambigous grammars the mainstream applications for this algorithm can be
found in NLP.

One step further, Rytter has parallelize this algorithm to obtain a fast
parallel algorithm running in O(log n) time with O(n^6) processors on a
CRCW-PRAM. O.K. O(n^6) sounds bad, but it gives the best time complexity
known.
--
Hans de Vreught
[e-mail]
Delft University of Technology (TWI-ThI)
The Netherlands
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 23 23:32:03 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Jonathan Eifrig)
Subject: Re: Chomsky Normal Form and parsing
Message-ID: <[e-mail]>
Keywords: parse, theory
Sender: [e-mail]
Organization: The Johns Hopkins University CS Department
References: <[e-mail]>
Date: Wed, 24 Feb 1993 00:29:38 GMT
Approved: [e-mail]

In article <[e-mail]> [e-mail] (BO/EBC/KX/ZG
>I have some more entangled(?) questions on CFG's.
>
>This time it's Chomsky and Greibach normal forms I'm interested in.
>
>    [definition of CNF grammars deleted]
>
>The question is: what's the practical use of this?
>Can we parse this Chomsky Normal Form for sure using some parsing method?

>[added later -John]
>I just found a comment on this in a comp.compilers article from May 1992:
Jonathan Eifrig ([e-mail]) writes:

> We want don't so much want to recognize a
> *language* so much as generate a parse tree of the input for a particular
> grammar.  The *grammar* itself is important; if one has to contort the
> "natural" grammar (i.e., the one that matches the semantic grouping) of
> language in order to accomodate our parsing scheme, this is a serious dis-
> advantage.  This is why, for example, we don't just convert our ambiguous
> grammars into Chomsky normal form and apply the obvious dynamic
> programming parsing scheme.  We'll see in a minute that both LL(k) and
> LR(1) parsing schemes suffer from this problem.

    Wow!  Let me tell you, seeing an article you posted almost a year
ago makes one sit up and take notice!  Stop the compliments, before they
fool me into writing a book.  :-)

    As far as the parsing scheme goes, it's very simple.  (Like most
algorithms, its obvious, once you see the trick.)  Consider a CNF with k
non-terminal symbols, m terminal symbols, and n productions.  To answer
"Is string a in the language generated by the grammar?", we do the
following:

    Let a[i,j] be the substring of the input from position i to
position j in the input (0 < i,j <= n).  We build a table telling us, for
every i and j, which (if any) of the grammar symbols could generate the
string a[i,j].  Once we have the table, we just check to see if the start
symbol could have generated a[1,n].

    We build the table by induction on the length of the substrings
a[i,j].  For substrings of length 1, this is easy: A could generate
a[i,i+1] = a if and only if A -> a is a production of the grammar.  For
longer strings, we just check exhaustively: For each production A ->BC, we
check to see if there exists a k (between i and j) such that B generates
a[i,k] and C generates a[k+1,j]; since these substrings are shorter that
a[i,j] these answers are already in the table.

    A relatively straightforward counting argument shows that this
brute-force approach is even "efficient," at least as far a theorists are
concerned: it takes worst-case O(n^3) time.  For a fixed-size grammar,
it's a little better: O(n^2).  This is well-known automata theory stuff.
(In fact, it was one of the questions on my qualifier!  :-)) For a more
detailed explanation, see my favorite baby automata book "An Introduction
to Formal Languages and Automata" by Linz.

    Of course, these are the wrong sorts of parsing questions to ask,
in practice.  As I argued above, there's very little use for a parser that
just answers "Yes" or "No"; what one _really_ needs is a parser that
generates a parse tree of the input.
--
Jack Eifrig ([e-mail])       The Johns Hopkins University, C.S. Dept.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 23 23:33:07 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Paul Dietz)
Subject: Re: C++ symbol table
Message-ID: <[e-mail]>
Keywords: C++, parse
Sender: [e-mail]
Organization: University of Rochester
References: <[e-mail]> <[e-mail]>
Date: Tue, 23 Feb 1993 18:31:17 GMT
Approved: [e-mail]

[e-mail] (David Chase) writes:
> I don't have a complete answer, but I do have a suggestion.  There was a
> nifty trick proposed by Paul Dietz in STOC '81, and it has been used with
> some success by several people that I know (in fact, it has been
> rediscovered with some success by several people, and we (= me, Wegman,
> Zadeck) used it in a different context to get good time bounds for a sort
> of incremental SSA.  ...

The problem I was solving can be abstracted as follows.  Let T be a tree
whose nodes are labelled with names drawn from some set N.  Initially, the
tree consists of a single node with the null label.  The tree is updated
by the operation AddLeaf(x,n), which creates a new leaf y with parent x
and label n, returning a pointer to y.  The query FindAncestor(x,n) finds
the deepest ancestor of x with label n (possibly x itself), or null if no
such ancestor exists.

This gets solved as follows.  We store the nodes of the tree in a list, in
preorder.  Each label occuring in the tree decomposes the tree into
connected subgraphs on which the FindAncestor queries for that label
return the same answer.  These subgraphs induce a decomposition on the
preorder list.  One can easily show that if a particular label occurs k
times, it induces a partition of the preorder list into at most 2k+1
sublists.  We can represent this decomposition by storing the first
element of each of the sublists in a binary search tree, where the
comparison operation is "does this node occur before this node in the
list?"

It turns out one can implement insertions, deletions and these order
queries in a list in constant time per operation (the STOC 81 paper was
foolishly off by log* n; Tarjan and also Tsakalidis pointed out a trick to
get linear amortized time, and Dietz and Sleator (STOC 87) showed how to
do it in constant single operation time; we also gave a simpler amortized
constant time algorithm, using an idea related to one obtained by
Leiserson).  This lets one do operations on the trees in O(log k) time,
where k is the number of times the label appears in the tree.

I later shows (WADS 89) how to do all these operations in O(loglogn)
amortized time per operation (on a RAM).  This algorithm is completely
impractical, however.

Related to all this is work on so-called "fully persistent data
structures"; see Driscoll, Sarnak, Sleator and Tarjan (JCSS 89), as well
as algorithms for maintaining sorted arrays with density > some positive
constant in O(log^2 n) time per insertion.

(Dave: I'd love to see some references to people using this stuff.)

    Paul F. Dietz
    [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Tue Feb 23 23:34:01 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Soohong Kim)
Subject: C Compiler using source-to-source restructurer.
Message-ID: <[e-mail]>
Keywords: C, optimize, question, parallel
Sender: [e-mail]
Organization: University of Southern California, Los Angeles, CA
Date: Wed, 24 Feb 1993 03:58:10 GMT
Approved: [e-mail]

Hello,

I am planning to build Parallelizing C Compiler for SNAP, which is MIMD
machine being built at USC.

One of choices of compiler models I am interested in is to use
"source-to-source parallelizing restructurer" such as Parafrase-2 and
PFC+. I want to use Parafrase-2 as a compiler-preprocessor.

Here's my draft!
----------------------------------------------------------------------

  C  ==> [RESTRUCTURER] ==>  C'  ==> [COMPILER] ==> machine code

 --------------------------------------------------------------------

    C        : Sequential C source code.
    C'        : Concurrent form of C source code.
    machine code    : Machine code for SNAP.
    [RESTRUCTURER]    : Source-to-source parallelizing restructurer.
    [COMPILER]    : Optimizing Compiler.
----------------------------------------------------------------------

The problem is that Restructurer for C (C phase of Parafrase-2) is yet
working properly, although FORTRAN restructurer is doing a good job.

So, at this point, I want to build compiler for subset of C with the
current techniques of the FORTRAN compiler with restructurer, then broaden
the range of the source program.

Is there any research group who is building compilers (either for C or
FORTRAN) using source-to-source restructurer? I need your advice.

All comments are welcome.

Soohong Peter Kim                [e-mail]
--
Soohong Peter Kim               Internet: [e-mail]
Department of Electrical Engineering       Room: 222 in EE-Building
University of Southern California       Phone: [phone]
Los Angeles, CA 90089, USA
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 24 13:03:23 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Todd P. Whitesel)
Subject: Re: Another Issue in Compiler Generated Assembly Code
Message-ID: <[e-mail]>
Keywords: assembler
Sender: [e-mail]
Organization: California Institute of Technology, Pasadena
References: <[e-mail]>
Date: Wed, 24 Feb 1993 09:31:22 GMT
Approved: [e-mail]

[e-mail] (Jon Forrest) writes:
>Another issue for compiler writers to keep in mind is that if their
>compiler produces assembly code, then it should 1) produce assembly code
>that the assembler can actually assemble, and 2) produce assembly code
>that, when assembled, is the same as the object code produced by the
>compiler.

I quite agree with #1, because one fast way to get a new compiler up and
running is to have it push off a lot of tasks onto the assembler;
naturally you have to output assembly that will be accepted if this is
going to work.

However, #2 is a bit unreasonable for third party compiler writers. It
would require the very last stage of the compiler to duplicate the second
half of the local assembler; this is wasteful enough, but what really
gives it problems is trying to support multiple assemblers that accept
essentially the same syntax but have quite different ideas of how to
organize things. Sure, it would be nice, but it has a tendency to be
impractical in a multiplatform environment.

Todd Whitesel
toddpw @ cco.caltech.edu
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 24 13:04:23 EST 1993
Xref: iecc gnu.misc.discuss:8767 comp.compilers:4305
Newsgroups: gnu.misc.discuss,comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Rich Walker)
Subject: Gnu Super Optimiser & Conditional instructions
Message-ID: <[e-mail]>
Keywords: optimize, question
Sender: [e-mail]
Organization: U of Cambridge, England
Date: Wed, 24 Feb 1993 11:01:31 GMT
Approved: [e-mail]

Has anyone modified GSO to handle processors with conditional
instructions? It's another of those things that'd be nice to have, but it
looks like requiring a fair degree of understanding of the exact methods
of GSO...

--- Rich! Walker ([e-mail])
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 24 13:05:32 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Hans de Vreught)
Subject: Re: Chomsky Normal Form and parsing
Message-ID: <[e-mail]>
Keywords: parse, theory
Sender: [e-mail]
Organization: Delft University of Technology
References: <[e-mail]> <[e-mail]>
Date: Wed, 24 Feb 1993 11:40:04 GMT
Approved: [e-mail]


[e-mail] (BO/EBC/KX/ZG
>Can we parse this Chomsky Normal Form for sure using some parsing method?

[e-mail] (Jonathan Eifrig) writes:
>    Of course, these are the wrong sorts of parsing questions to ask,
>in practice.  As I argued above, there's very little use for a parser that
>just answers "Yes" or "No"; what one _really_ needs is a parser that
>generates a parse tree of the input.

Ah, but such a parser *does* exist. In the recognition phase an upper
triangular matrix is filled in such a way such that every partial parse
can be retrieved. So after that phase you only have to look why the answer
on the recognition question was yes. While establishing that justification
you are able to retrieve a parse tree. Since the parsing stage is simple
the total complexity for recognition and parsing is O(n^3).

Like I said before (in a previous posting), algorithms for CFGs in CNF are
used frequently. However, not in compiler design but in natural language
processing.
--
Hans de Vreught
[e-mail]
Delft University of Technology (TWI-ThI)
The Netherlands
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 24 13:06:41 EST 1993
Xref: iecc comp.compilers:4307 comp.lang.c:41552
Newsgroups: comp.compilers,comp.lang.c
Path: iecc!compilers-sender
From: [e-mail] (Christer Holmfors)
Subject: C-compiler for MC 68HC11
Message-ID: <[e-mail]>
Keywords: C, question
Sender: [e-mail]
Reply-To: [e-mail] (Christer Holmfors)
Organization: Lund Institute of Technology
Date: Wed, 24 Feb 1993 14:14:16 GMT
Approved: [e-mail]

Hi!  I am interested in finding a C-compiler which generates code
(assembler code) for Motorola 68HC11. It should run on PC and/or
unix-workstation.  Of course I prefer a c-compiler with the source code is
available but this isn't necessary. Is there perhaps a modified gcc out
there?

Thanks for any help!!

Christer
--
  Christer Holmfors,    student at Lund Institute of Technology
  email: [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 24 13:09:04 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Willem Jan Withagen)
Subject: New Alpha release of PASCAL frontend
Message-ID: <[e-mail]>
Keywords: Pascal, tools, FTP
Sender: [e-mail]
Organization: Compilers Central
Date: Wed, 24 Feb 1993 14:49:03 GMT
Approved: [e-mail]
X-Mailer: ELM [version 2.3 PL11]

I'd like to announce a new version of the PASCAL frontend I've written
using the Cocktail compiler tools.

Major advantages over the previous release:
  -    documentation of the internals.
  -    Semantics analysis is complete.
  -    A full symbol table is generated.
  -    It now includes a skeleton for Cross referencing and for
      storage allocation

Major disadvantage is still:
  - It doesn't have a backend (yet).

Sources are available in:
  ftp.eb.ele.tue.nl:/pub/src/pascal/frontend.zip    (all sources)
              /pub/src/pascal/frontend.README    (a short intro)
            /pub/src/pascal/frontdoc.zip    (dvi and ps)

        Willem Jan Withagen

Digital Information Systems Group, Room EH 10.35
Eindhoven University of Technology
P.O. 513                             Tel: [phone],Fax: [phone]
5600 MB Eindhoven                    The Netherlands
Internet:  [e-mail]
X400:      C=nl;ADMD=400net;PRMD=surf;O=tue;OU=ele;OU=eb;S=WJW;
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 24 13:09:50 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Peter Hamer)
Subject: looking for SDL grammar
Message-ID: <[e-mail]>
Keywords: parse, question
Sender: [e-mail]
Organization: BNR Europe Ltd, London Road, Harlow, England.
Date: Wed, 24 Feb 1993 16:29:55 GMT
Approved: [e-mail]

I'm looking for a grammar for the CCITT language SDL; eg in lex+yacc.

Does anybody know if this exists in the PD?

Thanks in advance, Peter
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 24 13:10:25 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: Andrew Henson <[e-mail]>
Subject: C++ compiler wanted
Message-ID: <[e-mail]>
Keywords: C++, question
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Compilers Central
Date: Wed, 24 Feb 1993 16:49:00 GMT
Approved: [e-mail]

I am looking for a C++ compiler that I can port to a new architechture and
operating system.

Royalites are negotiable for the successful offer; GNU is unacceptable
since the modified compiler will be sold.

Please reply by Email.

--------------
Andy Henson;  voice: +44.923.825275;  voicemail: +44.426.910223
[e-mail]; Cix is a mail service: I'm independent.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Wed Feb 24 13:11:08 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: "Scott Alden" <[e-mail]>
Subject: Data Flow Analysis in the presence of recursion.
Message-ID: <[e-mail]>
Keywords: dataflow, analysis, question
Sender: [e-mail]
Organization: Compilers Central
Date: Wed, 24 Feb 1993 17:16:40 GMT
Approved: [e-mail]

I am currently looking for information (papers, articles, etc...) on
interprocedural data flow (flow sensitive and insensitive) analysis,
particularly under the presence of recursion.

I am familiar with the work done by Banning, Barth, and Cooper & Kennedy
but would like to know if any current work has been done on the subject.
I would appreciate it if anyone can point me in the right direction.

Sincerely,
Scott D. Alden
[e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 25 22:43:21 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail]
Subject: EBNF -> BNF Translator Wanted for GTLLGEN.
Message-ID: <[e-mail]>
Keywords: EBNF, question, translator
Sender: [e-mail]
Organization: Pembroke State University
Date: Wed, 24 Feb 1993 20:09:15 GMT
Approved: [e-mail]

I am looking for a EBNF to BNF translator such that the output grammar
will be compatible with a program called GTLLGEN a LL(1-(semi)) based
table generator.

Anybody who could point me to .C or .PAS sources I would appreciate it, or
names of programs that could be found in an Archie search.

Many thanks,

- Craig Taylor   - 919-521-3814   All Relevant Disclaimers Apply!!!
        [e-mail] (Pembroke State University)
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 25 22:44:14 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Henry Spencer)
Subject: Re: Effectiveness of compilers today
Message-ID: <[e-mail]>
Keywords: optimize, assembler
Sender: [e-mail]
Organization: U of Toronto Zoology
References: <[e-mail]> <[e-mail]>
Date: Wed, 24 Feb 1993 21:59:18 GMT
Approved: [e-mail]

[e-mail] (James Kanze) writes:
>... This code sequence is a well known trick regularly
>used by 8086 assembly programmers 10 years back.  So it should hardly
>require a super-optimizer to find it...

That one code sequence is not the only justification for the
super-optimizer!  Sure, a machine that gets programmed a lot in assembler
builds up a body of folklore over the years about cute ways of doing
things.  Sometimes, some of it even gets written down.  The point of the
super-optimizer is being able to discover these things systematically
without having to wait five years for the experience to build up
(especially since assembler programming is getting less common all the
time).
--
Henry Spencer @ U of Toronto Zoology |  [e-mail]  utzoo!henry
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 25 22:44:58 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (kevin jones)
Subject: ANY info on EVA
Message-ID: <[e-mail]>
Keywords: vector,question
Sender: [e-mail]
Organization: Bowling Green State University B.G., Oh.
Date: Wed, 24 Feb 1993 22:07:17 GMT
Approved: [e-mail]

I am looking for any information on the compiler EVA - Explicit Vector
Language.  Has anyone ever heard of this obscure language, let alone
know where I could find any information on it?

Please mail me directly
Kevin Jones   [e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 25 22:46:06 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Krishnan R)
Subject: Code Generation/Coagulation
Message-ID: <[e-mail]>
Keywords: question
Sender: [e-mail]
Organization: Indian Institute of Technology, Bombay
Date: Thu, 25 Feb 1993 06:16:39 GMT
Approved: [e-mail]

There was a paper by Michael Karr on 'Code Generation through
coagulation'in ACM Sigplan symposium on CC,1984.Has anybody seen an
implementation ?.Also any more papers on the same issue ?  Also where can
I get a copy of Carr's full thesis ?
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 25 22:46:47 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: "Juergen Vollmer" <[e-mail]>
Subject: Optimizing parallel programs?
Message-ID: <[e-mail]>
Keywords: optimize, parallel, question
Sender: [e-mail]
Organization: Compilers Central
Date: Thu, 25 Feb 1993 17:26:47 GMT
Approved: [e-mail]

Hello

I'm looking for information about optimization techniques (i.e.  analysis
and transformation) of explicit parallel (imperative/functional/logical)
programs.

The optimization should be able to deal with things like: execution of
statements in parallel, message passing, shared and distributed memory,
etc. which are specified explicitly in the source program.

Any reference is welcome.  Please email to me, I will summarize.

Juergen Vollmer
[e-mail]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 25 22:47:46 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Dag Helmfrid)
Subject: Using gnu C-compiler for signal processors
Message-ID: <[e-mail]>
Keywords: GCC, DSP, question, comment
Sender: [e-mail]
Reply-To: [e-mail] (Dag Helmfrid)
Organization: Ericsson
Date: Thu, 25 Feb 1993 13:29:28 GMT
Approved: [e-mail]

Hi,

Has anyone used the gnu C-compiler for a signal processor.  Was is
possible to get resonable performance of the compiled code? It is
specially interesting to se how fixpoint nubers are handled. If anyone has
done this job for the TMS320C5x clones of processors, then a comparison
with the existing C compilers performance is of interest.

// Dag Helmfrid
[I've seen a version of GCC for the Motorola 56K floating around. -John]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 25 22:48:31 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Samuel Midkiff)
Subject: re: Data Flow Analysis in the presence of recursion
Message-ID: <[e-mail]>
Keywords: dataflow, analysis, question
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]>
Date: Thu, 25 Feb 1993 14:01:03 GMT
Approved: [e-mail]

You might want to look at Luddy Harrison's and David Sehr's PhD theses.
Harrison's is oriented towards Lisp and Sehr's is oriented towards Prolog.
Harrison can be reached at [e-mail]; and Sehr can be reached
at: [e-mail].

Sam Midkiff
[e-mail]
[phone]
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Thu Feb 25 22:49:16 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Joachim Schrod)
Subject: Re: parser-generators for RRPGs: summary
Message-ID: <[e-mail]>
Keywords: parse, EBNF
Sender: [e-mail]
Organization: TH Darmstadt, FG Systemprogrammierung
References: <[e-mail]> <[e-mail]>
Date: Thu, 25 Feb 1993 18:52:42 GMT
Approved: [e-mail]

FYI, three of the named parser generators (the freely distributable ones:
Cocktail, Eli, and PCCTS) are available by anonymous ftp:

    ftp.th-darmstadt.de [130.83.55.75]
    pub/programming/languages/compiler-compiler

in subdirectories therein. This site is in Germany and therefore
especially of interest for European users. (The others will note our
narrow intercontinental bandwidth. ;-)

Generators which produce C++ code are in a neighbour tree (below
pub/programming/languages/C++).

Enjoy.

    Joachim
--
Joachim Schrod            Email: [e-mail]
Computer Science Department
Technical University of Darmstadt, Germany
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 26 19:29:32 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: Frank Deutschmann <[e-mail]>
Subject: Tail recursion in object systems
Message-ID: <[e-mail]>
Keywords: OOP, question, optimize
Sender: [e-mail]
Organization: Compilers Central
Date: Fri, 26 Feb 1993 05:46:55 GMT
Approved: [e-mail]

I recently posted the following article to comp.object, but I think it
would be interesting to see some comp.compilers discussion on the subject.
The thread began with someone posting an example of two objects with
mutually tail-recursive methods; the interesting aspect is whether
tail-recursion optimization can be performed in a message-passing
environment.

[e-mail] (Ciaran McHale) writes:
> Instead of relying on your system to optimise mutual tail recursion,
> you might be able to rewrite you code to do:
> [...example as while loop...]

Yes, recursive code can always be rewritten, but some problems are
better expressed (read: more understandable) as recursive.

> I think you are jumping the gun a bit. Firstly, (unless my site didn't
> receive some articles) nobody here has argued that such mutual
> tail-recursion is needed often in practice.

Tail recursion is more common than you would think -- in C, any
function call immediately prior to a return can be optimized into a
jump, with potentially huge performance speedups.  Just take a look at
some code to see how often function invocations immediately preceede
returns (and note also that some compilers may be able to re-order
source statements to optimise to the jump rather than a function
call).  As you mention in your post, delegation in particular leads to
tail-recursive functions.


[e-mail] (Scott Burleigh) writes:
>I think the problem that this posting brought up is more fundamental than
>compiler optimization.  It is a problem in the semantics of object-oriented
>language design.  When we say that a given line of code indicates that "a
>message is sent to object B" we are kidding ourselves; what is really
>happening is that a function associated with object B is being called.

Yes, this is exactly my point with the RPC and migrating objects issue.
What we are seeing is that method invocation via function call is not the
same as method invocation via message passing.

C++ shows this quite clearly; we will get radically different execution
behavior if (using the standard C++ features) we have two mutually
tail-recursive objects that are located in the same address space, versus
the same two objects located in different address spaces.

In the same address space case, the compiler optimizes out the function
calls, and the program runs in constant stack space.  But in the remote
object case, the objects do method invocation via (RPC) message passing,
and the compiler's tail-recursion optimizations do not help (the call to
the RPC function is probably a jump, but that doesn't help in the large
sense).  If we don't have threads, we deadlock immediatly on the recursion
from object 2 back to object 1 (as object 1's process is blocked waiting
for the RPC return).  (This is a rather crude, default case of the mutex
preventing mutual recursion which Ciaran's post mentions.)  If we do have
threads (and on method invocation/message receipt we create a new thread),
we create threads and leave them sleeping until we run out of resources
(effectively, threads have become a substitute for stack frames, but we
can't optimize this case to run in constant space).

The cause of the difference in behavior is clearly the dichotomy between
pure function call versus message passing/handling.  However, after
thinking about this in more depth, I see no way to make the RPC behave
like a true function call.

>I suggest that the solution to the problem is to implement genuine message
>exchange in place of the ersatz.  When we want object A to send a message
>to object B, it should SEND A MESSAGE to object B even if by some
>mischance objects A and B happen to reside in the same address space; A
>should resist the temptation to muck with B directly, show it some
>respect, and simply route a message to it through some disinterested third
>party.

True, sending messages in all cases is certainly cleaner and more
consistent (it behaves the same, whether the object is local or remote),
but, after further investigation, I can not see a clear way to do the
equavallent optimization for the message passing system.  (In other words,
I'm at a loss to figure how to get a message passing system, like
Smalltalk, to execute tail-recursive code in constant space/resources.  If
Smalltalk is really capable of this optimization, I would be really
interested to hear about the details!)

But note that in a message passing system, you will be subject to the RPC
case, whether your objects are local or not (i.e.: with threads, you
eventually run out of resources; without threads, you deadlock).  In
neither case does Stephan get the desired behavior.

In any case, to do the optimization, I believe it is clear that you need a
global view of the code -- this optimization can not be implemented in a
message passing switch/layer -- as you need knowledge of whether the
message pass is the final job prior to return/reply.

Just to carry this discussion a little bit further: this says to me that
OO environments really need be based upon message passing; using function
invocation to approximate messages is not good enough, as it leads to
different behavior in different circumstances.  While it is true that
mutually tail-recursive functions are not the most common things, they do
exist, and, as systems get larger and we head to more distributed systems
with object migration support, this issue is likely to become more
serious.  I would be extreemly interested to learn if it is possible to
handle tail-recursion in constant space/resources in a message passing
environment.

-frank
--
EMail: [e-mail], Phone: 1 - 212 / 765 - 2050
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 26 23:23:07 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (David Loshin)
Subject: Call for Papers
Message-ID: <[e-mail]>
Keywords: parallel, CFP
Sender: [e-mail]
Organization: Thinking Machines Corporation, Cambridge MA, USA
Date: Fri, 26 Feb 1993 14:17:16 GMT
Approved: [e-mail]

                    Call For Papers
                     in
    Parallel and Distributed Systems: From Theory to Practice
                   for the
              Software Technology Track
                    of the
    27th Hawaii International Conference on System Sciences, HICSS-27
            Maui, Hawaii - January 4-7, 1994
            ===============================

This year, the Software Technology Track of HICSS-27 will be exclusively
focussing on a broad selection of topics in the area of Parallel and
Distributed Systems: From Theory To Practice. This particular solicitation
for the Software Track will provide a forum to discuss new advances in
theory, design, implementation, use, application, and performance
evaluation of parallel and distributed systems.  Papers are invited that
may be theoretical, conceptual tutorial or descriptive in nature. Those
papers selected for presentation will appear in the Conference
Proceedings.  HICSS-27 is sponsored by the University of Hawaii in
cooperation with the ACM and the IEEE Computer Society. The Conference
Proceedings are published by the IEEE Computer Society. A collection of
the accepted papers will be considered for inclusion in a separately bound
volume to be determined (publishers and exact dates of publication) at a
later time.


1993 Deadlines
==============
o  A 300-word abstract by March 15
o  Feedback to author on abstract by April 1
o  Eight copies of the manuscript by June 4
o  Notification of accepted papers by August 31
o  Camera-ready copies of accepted manuscripts are due by October 1

Software Technology Track Co-Chairs
===================================
 Hesham El-Rewini
 Department of Mathematics  and Computer Science
 University of Nebraska at Omaha
 Omaha, NE 68182
 [e-mail]
 [phone]

 Ted Lewis
 Department of Computer Science
 Oregon State University
 Corvallis, OR 97331
 [e-mail]
 [phone]

 Bruce Shriver
 HICSS-27 Co-Chairman
 17 Bethea Drive
 Ossining, NY 10562-1620
 [e-mail]
 [phone]


Software Technology Track Advisory Committee
============================================
o Gul Agha, University of Illinois
o Dharma Agrawal, North Carolina State University
o Dennis Allison, HaL Computer Systems & Stanford University
o Thomas Casavant, University of Iowa
o Jack Dongarra, University of Tennessee/Oak Ridge National Laboratory
o Ramez Elmasri, University of Texas at Arlington
o Hesham El-Rewini, University of Nebraska at Omaha
o Mike Evangelist, Florida International University
o John Gustafson, Ames Lab, Iowa State University
o Ted Lewis, Oregon State University
o David Padua, University of Illinois
o Behcet Sarikaya, Bilkent University, Turkey
o Bruce Shriver, Consultant (on leave from the University of Southwestern
  Lousiana)
o Ivan Stojmenovic, University of Ottawa, Canada


Specific Topics and Minitrack Coordinators
==========================================
Submit your 300-word abstract and then eight copies of the paper to one of
the following Minitrack Coordinators according to their areas of
responsibility.  Electronic submissions are encouraged.  Persons interested
in refereeing in these areas should contact the Minitrack Coordinators
directly.


1) PROGRAM PARTITIONING AND SCHEDULING IN PARALLEL AND DISTRIBUTED SYSTEMS

   Automatic Partitioning
   Static/Dynamic Scheduling
   Task Allocation
   Load balancing
   Scheduling
   Overhead Issues
   Parallel scheduling algorithms
   Execution and Communication Cost Estimation

   COORDITATOR
   -----------
   Min-You Wu, [e-mail]
   Department of Computer Science
   State University of New York
   Buffalo, NY 14260


2) TOOLS AND LANGUAGES FOR TRANSPORTABLE PARALLEL APPLICATIONS

   Parallelism & Transportability
   Tools/Languages
   Application Suitability
   Performance Issues
   Usability/Expressiveness Tradeoffs
   Scalability Issues
   Testing Tools
   Debuggers

   COORDITATOR
   -----------
   Cherri Pancake, [e-mail]
   Department of Computer Science
   Oregon State University
   Corvallis, OR 97331


3) OPERATING SYSTEM SUPPORT FOR MASSIVELY PARALLEL COMPUTER ARCHITECTURE

   Parallel Operating Systems
   Distributed Microkernels
   Dynamically Alterable System Structure
   High Performance Communication Protocols

   COORDITATOR
   -----------
   Wolfgang Schroeder-Preikschat, [e-mail]
   German National Research Center for Computer Science
   GMD FIRST
   Rudower Chaussee 5, D-1199
   Berlin, Germany


4) PARALLEL ALGORITHMS

   Design and Analysis of Parallel Algorithms in the
   following areas: Graph Theory, Image Processing,
   Computational geometry, and Combinatorics, and on
   the application of these areas in parallel computing.

   COORDITATORS
   ------------
   o Stephan Olariu, [e-mail]
   o James. L. Schwing, [e-mail]
   Department of Computer Science
   Old Dominion University
   Norfolk, VA 23529-0162


5) ISSUES AND PROBLEMS IN COMPILING FOR DISTRIBUTED MEMORY COMPUTER SYSTEMS

   Networks and Memory Hierarchies
   Optimal Allocation of Data Objects
   Optimizing for Locality of Reference
   Optimization of Communication
   Vectorization
   Parallelization
   Automatic Parallelization of  Dusty Decks
   Tools for Building Parallel Applications
   Node-Level Optimizations

   COORDITATORS
   ------------
   o Alex Vasilevsky, [e-mail]
   o David Loshin, [e-mail]
   Thinking Machines Corporation
   245 First Street
   Cambridge, Massachusetts 02142


6) PROGRAMMING MODELS AND PARADIGMS FOR PARALLEL AND DISTRIBUTED COMPUTING

   Shared Distributed Memory Model
   Virtual Shared Memory Model
   Multi-Threaded Computation Model
   Virtual Topology Programming Model
   New programming paradigms
   Parallel  Languages

   COORDITATORS
   ------------
   o Wolfgang K. Giloi,  [e-mail]
     GMD Center for Innovative Computer Systems
     Berlin, Germany

   o Carl Chang, [e-mail]
   o Jon Solworth, [e-mail]
   Dept. of EECS
   University of Illinois at Chicago
   Chicago, Illinois 60680


7) REAL-TIME COMPUTING

   Assignment of Real-Time Software in Parallel and Distributed Architectures
   Schedulability Analysis and Performance Prediction Methods
   Software Engineering Techniques for Construction of Complex Systems
   Languages
   Debuggers
   Compilers
   Code Generators and Other Tools
   Integration in Complex Heterogeneous Application Domains
   Fault-tolerance
   Dynamic and Adaptive Systems
   Responsive Systems

   COORDITATOR
   -----------
   Alexander D. Stoyenko, [e-mail]
   Real-Time Computing Lab
   Department of Computer & Information Science
   NJIT, University Heights
   Newark, NJ 07102.


8) PARALLEL & DISTRIBUTED DATABASE SYSTEMS

   Multidatabase Systems
   Distributed Database Systems
   Distributed File Systems
   Intelligent and Cooperative Information Systems
   Object-Oriented Design for Large-Scale Database Systems

   COORDITATORS
   ------------
   o M.W. Bright, [e-mail]
     IBM
     18100 Frederick Pike
     Gaithersburg, MD 20879

   o Abdelsalam  Helal, [e-mail]
     Dept. of CSE
     University of Texas at Arlington
     Arlington, TX 76019

   o A.R. Hurson, [e-mail]
     Dept. of  ECE
     The Pennsylvania State University
     University Park, PA 16802


Instructions for Submitting Papers
==================================
Manuscripts should be 22-25 typewritten, double-spaced pages in length.
Please do not send submissions that are significantly shorter or longer
than this. Papers must not have been previously presented or published,
nor currently submitted for journal publication.  Each manuscript will be
subjected to a rigorous refereeing process involving at least five
reviewers.  Manuscripts should have a title page that includes the title
of the paper, full name(s) of author(s), affiliation(s), complete postal
and electronic mail address(es), telephone and FAX number(s), and a
300-word abstract of the paper.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 26 23:24:56 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Terence J Parr)
Subject: Re: question to PCCTS users
Message-ID: <[e-mail]>
Keywords: PCCTS, tools
Sender: [e-mail]
Organization: Compilers Central
References: <[e-mail]>
Date: Fri, 26 Feb 1993 20:35:53 GMT
Approved: [e-mail]

Bill Nell ([e-mail]) writes:

> 1) When compiling antlr with itself I get the following warnings.
>
> ../bin/antlr antlr.g
> Antlr parser generator   Version 1.06   1989-1992
> antlr.g, line 345: warning: optional path and alt(s) of (..)* ambiguous
>    upon { "#errclass" }
[ other messages deleted ]
>
> Is this normal?

Yep.  These ambiguities are handled correctly by ANTLR.  Most arise from
"ambiguous" productions added to generate good error messages for
erroneous ANTLR descriptions.

[ From ANTLR BUGS100 file: ]
> > Be aware that switching between input streams will not work because
> > characters are lost when switching to a new stream.

> My questions are: Do multiple parsers/multiple parser invocations work
> now?  And, I am confused about the last line in the last paragraph.  To me
> it basically means that a PCCTS lexer/parser would not be able to handle
> things like #include files, where you would have to switch the input
> buffer to read from a new file.

1.06 PCCTS does indeed drop characters when you switch input streams and
then try to switch back; specifically, the lookahead char used by the DLG
automaton is not saved (lost).  To solve this, we have created DLG save
and restore state functions and an example that uses these functions to
handle nested #include statements.

Files dlgdef.h.fix and dlgauto.h.fix are available from the ftp site or
the mailserver to replace your existing dlgdef.h and dlgauto.h files.  The
example is in file nesting.g.  Contact [e-mail] with a
Subject: line of

Subject: email file

where 'file' is one of dlgdef.h.fix, dlgauto.h.fix, nesting.g to obtain
these files.

The ftp site, marvin.ecn.purdue.edu [128.46.179.151] in directory
pub/pccts, has the files as well.

Terence Parr
Will Cohen
Purdue Electrical Engineering
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 26 23:25:25 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Preston Briggs)
Subject: Re: Code Generation/Coagulation
Message-ID: <[e-mail]>
Keywords: code, bibliography
Sender: [e-mail]
Organization: Rice University, Houston
References: <[e-mail]>
Date: Fri, 26 Feb 1993 20:46:24 GMT
Approved: [e-mail]

[e-mail] (Krishnan R) writes:

>There was a paper by Michael Karr on 'Code Generation through
>coagulation'in ACM Sigplan symposium on CC, 1984.  Has anybody seen an
>implementation?  Also any more papers on the same issue?  Also where
>can I get a copy of Karr's full thesis ?

There's a later paper that describes an experimental implementation.

  author="W. G. Morris",
  title="{{\small CCG}}: A Prototype Coagulating Code Generator",
  pages="45--58",
  journal=sigplan,
  year=1991,
  month=jun,
  volume=26,
  number=6,
  note=pldi91

For Karr's thesis, I'd check with University Microfilms or perhaps
write Harvard.

Preston Briggs
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 26 23:27:04 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: Hermano Moura <[e-mail]>
Subject: Operational Semantics and Compiler Generation.
Message-ID: <[e-mail]>
Keywords: semantics, question
Sender: [e-mail]
Organization: Compilers Central
Date: Fri, 26 Feb 1993 18:51:50 GMT
Approved: [e-mail]

Could someone give some references regarding the use of [structural]
operational semantics for [semantics-directed] compiler generation?
Pointers to papers, systems, groups, etc are welcome. (Answers by e-mail
is preferable; I will summarize to this group if there is enough
interest.)

Many thanks,

-- Hermano Moura
   Computing Science
   Glasgow University
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Fri Feb 26 23:29:02 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Jon Solworth)
Subject: CFP: ISCA workshop on parallel coordination, San Diego, May 1993
Message-ID: <[e-mail]>
Keywords: parallel, CFP
Sender: [e-mail]
Organization: EECS Dept, Univ. of Illinois at Chicago
Date: Sat, 27 Feb 1993 00:45:48 GMT
Approved: [e-mail]


Call for papers and participation . . .

    Workshop on Fine-Grain Massively Parallel Coordination
         Intl. Symp. on Computer Architecture
            San Diego, California
               May 14-15, 1993

ABSTRACT
========

    Parallel computing consists of alternating independent computation
(on individual processors) and coordination among processors; it is the
coordination which distinguishes parallel from uniprocessor operation.
Coordination includes synchronization, communication, scheduling, and
resource management.  Efficient coordination is critical to exploiting
fine- or even medium-grain concurrency and effects performance, static vs.
dynamic tradeoffs, degree of asynchrony, and many other aspects of
parallel processor implementation and semantics.

    There is a growing trend towards using sequential microprocessors
as a base for parallel machines.

     .  As context switching time increases, how can processors be
    coordinated efficiently?  Does this condemn us to
    coarse-grain machines, or can groups of processors be scheduled to
    minimize context switching?  Are fine-grain architectures only
    achievable with custom processor hardware?  Are there fundamental
    tradeoffs between coordination efficiency and sequential processing
    efficiency?

     .    What are a sufficient set of coordination mechanisms, and how can
    they be implemented in the network or memory (including caches)?
    How can these implementations compensate for the lack of fine-grain
    parallelism support at the processor level?
    What are the tradeoffs of properties such as virtualizability and
    fault tolerance versus hardware cost, scalability, and efficiency?
    What properties should be guaranteed by the software system
    versus the architecture?

     .    What is the impact of compile-time analysis on coordination,
    including scheduling and resource allocation?



IMPORTANT DATES:
================
    Papers due:  March 22, 1993
    Acceptances: April 8,  1993
    Final papers: May 1, 1993

ORGANIZERS:
===========
    Jon A. Solworth (Chair), University of Illinois at Chicago
    Andrew Chien, University of Illinois at Urbana-Champaign
    Gary Koob, Office of Naval Research

LOCAL ARRANGEMENTS
==================
    Jerry Stamatopolous, [e-mail]

SUBMISSIONS:
============
    If you are interested in submitting to the workshop send
    5 copies of a three-page (single spaced) abstract to the chair.
    Abstracts can discuss RESEARCH RESULTS or POSITION PAPERS,
    although we expect expect the balance of accepted papers to
    be weighted towards research contributions.
    Submit by sending postscript or plain text electronically to:

        [e-mail]

    If this is a hardship, then papers may be sent by physical mail
    arriving by the due date to:

        Jon A. Solworth
        Dept. of EECS (M/C 154)
        University of Illinois at Chicago
        851 S. Morgan Rm 1120 SEO
        Chicago, IL 60607-7053

        FAX:       [phone]
             telephone: [phone]

    Submissions must include an email address and a telephone number.
    Acceptances will be made by email, posted to the network, and
    available by anonymous ftp from the directory
    parsys.eecs.uic.edu:pub/isca-ws.


WORKSHOP INFORMATION
====================

The workshop will be in San Diego, California, USA, May 14-15, as part
of the International Symposium on Computer Architecture at the
Federated Computing Research Conference (FCRC).  There will be a
registration fee, of between $150--$200.  Please send e-mail to
[e-mail] if you want to be on our mailing list.


THE FEDERATED COMPUTING RESEARCH CONFERENCE
===========================================

The Federated Computing Research Conference (FCRC) will run from May 14 to
May 22 in San Diego, California, USA.  The FCRC is an effort to bring
together a spectrum of individual computing research conferences and
workshops at a common site and at roughly the same time.  In addition,
mornings will begin with joint plenary talks on topics of broad appeal to
the computing research community.  The plenary speakers will include:
Laszlo Babai, Richard Karp, Guy L.  Steele, Jr., and Maurice Wilkes.  The
FCRC constituent conferences are the:

 *  25th Annual ACM Symposium on Theory of Computing (STOC), May 16-18
 *  20th Annual Int'l Symposium on Computer Architecture (ISCA), May 17-19
 *  9th Annual ACM Symposium on Computational Geometry, May 19-21
 *  Structure in Complexity Theory, 8th Annual IEEE Conference
        (Structures), May 18-21
 *  7th Workshop on Parallel and Distributed Simulation (PADS), May 16-19
 *  4th ACM SIGPLAN Symposium on Principles and Practices of Parallel
        Programming (PPoPP), May 19-21
 *  3rd Workshop on Parallel Algorithms (WOPA), May 19-20
 *  ACM/ONR Workshop on Parallel and Distributed Debugging, May 17-18
 *  CRA Workshop on Academic Careers for Women, May 15


SPONSORS of FCRC
================

The Federated Computing Research Conference (FCRC) is sponsored by the
Computing Research Association, ACM (with the following SIGs: SIGACT,
SIGARCH, SIGGRAPH, SIGOPS, SIGPLAN, SIGSIM), IEEE (with the following
Computer Science Technical Committees: Mathematical Foundations of
Computing, Computing Architecture, Simulation), University of Maryland
Institute for Advanced Computer Studies, DARPA, NSF, and ONR.
--
Jon A. Solworth                 internet:  [e-mail]
Dept. of EECS (M/C 154)             telephone: [phone]
University of Illinois at Chicago       FAX:       [phone]
851 S. Morgan Rm 1120 SEO
Chicago, IL 60607-7053
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sat Feb 27 21:55:13 EST 1993
Newsgroups: comp.compilers
Path: iecc!compilers-sender
From: [e-mail] (Milton A. Colvin)
Subject: Re: Tail recursion in object systems
Message-ID: <[e-mail]>
Keywords: OOP, optimize
Sender: [e-mail]
Organization: Dartmouth College, Hanover, NH
References: <[e-mail]>
Date: Sat, 27 Feb 1993 17:11:43 GMT
Approved: [e-mail]

A note on this subject: the Mentat large-grain dataflow system implemented
message passing RPC, but by something like continuation passing. The
sender passes a forwarding address for the result, not necessarily back to
the sender.  This allows tail-recursion optimization.
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.


From compilers Sun Feb 28 11:37:27 EST 1993
Xref: iecc comp.compilers:4327 misc.jobs.offered:24450
Newsgroups: comp.compilers,misc.jobs.offered
Path: iecc!compilers-sender
From: [e-mail]
Subject: Compiler positions available for week ending February 28
Message-ID: <[e-mail]>
Keywords: jobs
Sender: [e-mail]
Organization: Compilers Central
Date: Sun, 28 Feb 1993 13:00:01 GMT
Approved: [e-mail]

This is a digest of ``help wanted'' and ``position available'' messages
received at comp.compilers during the preceding week.  Messages must
advertise a position having something to do with compilers and must also
conform to the guidelines periodically posted in misc.jobs.offered.  To
respond to a job offer, send mail to the author of the message.  To submit
a message, mail it to [e-mail].


-------------------------------

From: [e-mail] (Reed Hastings)
Subject: Code Generation, Back End Optimization, Pure Software, Sunnyvale, CA
Organization: Pure Software Inc.
Date: Mon, 22 Feb 1993 15:47:38 GMT

Pure Software is looking for a talented engineer to design and implement
difficult instruction-level manipulations of existing object code.  The
successful candidate will be responsible for the future of Pure's Object
Code Insertion technology.

The ideal candidate will:

 o   have developed language implementation products;
 o   understand the complexity of Object Code Insertion;
 o   know several instruction sets;
 o   have 2 to 6 years of experience and a MSCS from a top university;
 o   possess excellent references;
 o   know SUNOS/SOLARIS inside out;
 o   desire a challenge and major rewards.

Pure Software's revolutionary Purify product transforms existing programs
at the object level introducing expanded error detection capabilities and
other features.  This product, and its derivatives, will be responsible for
a major increase in software reliability in the 90's.  As a startup, the
Company offers significant equity packages, and expects significant
commitment.

Our customers are the brightest development and testing engineers.  They
work on large cutting-edge applications on Sun workstations.  The primary
requirement is that you understand what the problems our customers are
facing, and want to help solve them.

Fax your resume and cover letter to 408.720.9200
attention Reed Hastings

-------------------------------

Organization: Scientific Placement, Inc.
From: [e-mail] (Karl Skadowski)
Date: Wed, 24 Feb 1993 17:34:30 CST
Subject: COMPILER R&D - ILLINOIS

Job Title & Location

COMPILER R&D - ILLINOIS
Real-world-experienced compiler pukes wanted.
Have 2 possibilities, heavy compiler r&d to be creative code writer,  and
another with business acumen to be a product manager.  If you don't have
product manager experience and don't know what that is, apply for the other
position.

Don't have real-world experience, only academia with a PhD???
Maybe. Let's see the bulk of your resume and we'll chat.
 Immigration status: You must be a U.S. or Canadian Citizen or have a
Permanent Residence Visa.

Please send a resume in plain text format via email to:

Karl Skadowski
Scientific Placement, Inc., Box 19949, Houston, TX 77224
713-496-6100  Fax: [phone]
Internet: [e-mail]; Compuserve: 71250,3001; AppleLink: D1580

Formats: Ascii text via Email preferred. Macintosh or PC Word processor
formats are OK via Email (binhex). Please do not send LaTex or
Postscript.Fax is discouraged unless Fine Setting on your fax machine is
used (to enable OCR scanning). US Mail on 3.5 inch diskette is OK too.

-------------------------------

From: [e-mail] (Arnold Garlick)
Subject: Sr. Programmer/Analyst/Compilers/Colorado (Recruiter)
Date: 25 Feb 1993 20:14:04 GMT

                     SENIOR PROGRAMMER/ANALYST, COMPILERS
                                (Colorado)

Technical design, implementation, development, and support of state-of-
the-art optimizing compilers for a supercomputer system.  Applicants
should have a strong background in compiler optimization techniques and
theory (particularly those related to scientific applications) and proven
vendor software development experience in one or more of:  scalar
optimization, automatic vectorization and parallelization, and
interprocedural optimization.  Solid ANSI C and Fortran programming
experience is essential.  Experience in RISC or parallel machine
architectures and the ability to work efficiently in an innovative small
team environment is highly desirable.

    ** Minimum 3 years on-the-job experience required **
             No new or recent graduates, please!

    US or Canadian Citizenship required, or US Permanent
Residency.  We are unable to assist persons requiring H-1 or  F-1 Visas.

Please respond directly to Arnold Garlick, President, Pacific Search,
2377 S. El Camino Real, Suite 201, San Clemente, CA 92672
E Mail:  [e-mail] (ASCII files only please)  Fax:  [phone].
Refer to Position #1359

-------------------------------

From: [e-mail] (Arnold Garlick)
Subject: Director of Languages/SW Engineering Management (Silicon Valley) (Recruiter)
Date: 25 Feb 1993 20:26:21 GMT

                             DIRECTOR OF LANGUAGES
                               (Silicon Valley)

Current opportunity for a Director of Languages to head a compiler group
of roughly 14 people (currently staffed at 10).  Compiler group is
aggressively pushing technology in parallelizing compilers and in
programming environment technology.  While management ability is the
fundamental requirement, the successful candidate must be at least
technically conversant in these areas.  Also required is the ability to
deal with a leading edge, fluid, loosely- structured technical and
management environment.  Job requirements include a Masters degree in
Computer Science (PhD preferred) 5 years or more experience in a technical
implementation positions, and 3 years of more management experience.
Knowledge of or implementation experience in restructuring compilers is a
definite plus, as is knowledge of RISC architectures (particularly DEC's
alpha architecture).  Job responsibilities include management of the
compiler group, setting technical direction, budgeting and review
responsibility, and hiring.
    ** Minimum 5 years on-the-job experience required **
             No new or recent graduates, please!

    US or Canadian Citizenship required, or US Permanent
Residency.  We are unable to assist persons requiring H-1 or  F-1 Visas.

Please respond directly to Arnold Garlick, President, Pacific Search,
2377 S. El Camino Real, Suite 201, San Clemente, CA 92672
E Mail:  [e-mail] (ASCII files only please)  Fax:  [phone].
Please refer to position #1372

-------------------------------

From: [e-mail] (Arnold Garlick)
Subject: Manager of Sustaining Engineering/Compiler Development (Silicon VAlley) (Recruiter)
Date: 25 Feb 1993 20:28:34 GMT

                       MANAGER OF SUSTAINING ENGINEERING
                             (Silicon Valley)

Current opportunity for a person to manage sustained engineering on a
highly advanced automatic restructuring compiler.  Transformations that
are currently included in the compiler include advanced dependence
analysis, loop interchange, limited interprocedural analysis, scalar
replacement, loop distribution, parallelization, and vectorization.  The
person in this job will be responsible for managing a small group whose
charter is to support and extend the functionality of this compiler.  A
B.S. in Computer Science is required, with a Masters (preferably focused
in compiler construction) being highly desirable.  Five or more years of
implementation experience is also a requirement.  Some managerial
experience is a plus, but is not a necessity; this job can be viewed as an
introductory step into management.  Experience with advanced restructuring
compilers is also a plus, as is experience with RISC architectures and
parallel machines.

This job is technical management, with the emphasis on technical.  The
management overhead is expected to be low (roughly 25% of the job's time),
so that technical implementation will be an important part of the job.
The job can be viewed as either an introductory step into management, for
a highly technical person desiring management responsibility, and a chance
to learn the technical details of restructuring compilers, for a person
with management experience.

    ** Minimum 5 years on-the-job experience required **
             No new or recent graduates, please!

    US or Canadian Citizenship required, or US Permanent
Residency.  We are unable to assist persons requiring H-1 or  F-1 Visas.

Please respond directly to Arnold Garlick, President, Pacific Search,
2377 S. El Camino Real, Suite 201, San Clemente, CA 92672
E Mail:  [e-mail] (ASCII files only please)  Fax:  [phone].
Please refer to position #1373

-------------------------------

From: [e-mail] (Arnold Garlick)
Subject: Dependence Analysis/Parallel Programming Environment (Silicon Valley) (Recruiter)
Date: 25 Feb 1993 20:30:37 GMT

            DEPENDENCE ANALYSIS/PARALLEL PROGRAMMING ENVIRONMENT
                              (Silicon Valley)

Career opportunity for a technical lead to be responsible for the
dependence analysis related phases of a parallel programming environment.
This person will be responsible for designing the dependence analysis
phases of an advanced interactive programming environment targeted towards
using interprocedural analysis and other advanced analysis to generate
highly optimized code, with an emphasis on multiple CPU parallelism.  This
person will also be responsible for heading up the implementation effort
as well.  Much of the base functionality can be drawn from an existing
restructuring compiler, so that the project does not need to start from
scratch.
A PhD in Computer Science with an emphasis on dependence analysis and
parallelism is required.  Industrial implementation experience and
experience with interactive parallel programming tools is a definite plus.
This project is an attempt to produce a product out of advanced
technology/ research-level information, so experience in transforming
research tools into production-level tools is also an advantage.

    ** Minimum 3 years on-the-job experience required **
             No new or recent graduates, please!

    US or Canadian Citizenship required, or US Permanent
Residency.  We are unable to assist persons requiring H-1 or  F-1 Visas.

Please respond directly to Arnold Garlick, President, Pacific Search,
2377 S. El Camino Real, Suite 201, San Clemente, CA 92672
E Mail:  [e-mail] (ASCII files only please)  Fax:  [phone].
Please refer to position #1374

-------------------------------

From: [e-mail] (Arnold Garlick)
Subject: Compiler Development/Code Optimization, SF Bay Area (Recruiter)
Date: 25 Feb 1993 20:22:20 GMT

        SENIOR SOFTWARE ENGINEER - COMPILERS
            (San Francisco Bay Area)

Compiler development position emphasizing code optimization, instruction
scheduling and middle path bridges to intermediate languages.  Company
develops advanced RISC-based workstations which employ multiprocessing
architecture.  Operating system background should be in MS-DOS.

    ** Minimum 3 years on-the-job experience required **
             No new or recent graduates, please!

    US or Canadian Citizenship required, or US Permanent
Residency.  We are unable to assist persons requiring H-1 or  F-1 Visas.

Please respond directly to Arnold Garlick, President, Pacific Search,
2377 S. El Camino Real, Suite 201, San Clemente, CA 92672
E Mail:  [e-mail] (ASCII files only please)  Fax:  [phone].
Please refer to Position #1200

-------------------------------

From: [e-mail] (Arnold Garlick)
Subject: Senior Programmer/Analyst-Compiler Development (Backend) (Colorado) (Recruiter)
Date: 25 Feb 1993 20:18:16 GMT

            SENIOR PROGRAMMER/ANALYST - COMPILER DEVELOPMENT (BACKEND)
                                  (Colorado)

Technical design, development, implementation and support of
state-of-the-art optimizing compilers for an advanced, very high speed
supercomputer system.  Should have a strong background in compiler
back-end design and implementation, and proven vendor software development
experience in code generation, instruction scheduling and register
assignment for vector of RISC architectures.  Solid ANSI C and Fortran
programming experience and the ability to work efficiently in an
innovative small-team environment is essential.  Experience in parallel
machine architectures is highly desirable.  Key requirement for position
are:

Must be a good, thorough programmer.  MS-level (or higher preferred)
degree, with a minimum of 2 years experience in vendor-supplied compiler
development.  (Cray,vector and RISC architectures are a plus.)  Good C and
Fortran 77 programming experience (Pascal, Fortran 90 and assembly
experience are a plus.)  (The reason for this is that existing compilers
are written in a combination of Pascal, C and Cray assembler, and the
objective is to write the new compilers in C and Cray assembler.  The two
source langauges processed by the compilers are C and Fortran ... will be
trashing the Pascal compiler.  Future languages are Fortran '90 and C++,
with no immediate plans or need to process those languages are yet.)

    ** Minimum 2 years on-the-job experience required **
             No new or recent graduates, please!

    US or Canadian Citizenship required, or US Permanent
Residency.  We are unable to assist persons requiring H-1 or  F-1 Visas.

Please respond directly to Arnold Garlick, President, Pacific Search,
2377 S. El Camino Real, Suite 201, San Clemente, CA 92672
E Mail:  [e-mail] (ASCII files only please)  Fax:  [phone].
Please refer to position #1364
--
Send compilers articles to [e-mail] or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.