home *** CD-ROM | disk | FTP | other *** search
/ Media Share 9 / MEDIASHARE_09.ISO / progmisc / comp9304.zip / 93-04 next >
Text File  |  1993-04-30  |  491KB  |  12,805 lines
  1.  
  2. From compilers Thu Apr  1 07:00:12 EST 1993
  3. Xref: iecc comp.compilers:4459 news.answers:6791
  4. Newsgroups: comp.compilers,news.answers
  5. Path: iecc!compilers-sender
  6. From: compilers-request@iecc.cambridge.ma.us (John R. Levine)
  7. Subject: comp.compilers monthly message and Frequently Asked Questions
  8. Message-ID: <monthly-Apr-93@comp.compilers>
  9. Followup-To: poster
  10. Keywords: administrivia
  11. Sender: compilers-sender@iecc.cambridge.ma.us
  12. Supersedes: <monthly-Mar-93@comp.compilers>
  13. Organization: Compilers Central
  14. Date: Thu, 1 Apr 1993 12:00:05 GMT
  15. Approved: compilers@iecc.cambridge.ma.us
  16. Expires: Sat, 1 May 1993 23:59:00 GMT
  17.  
  18. Archive-name: compilers-faq
  19.  
  20. This is the comp.compilers monthly message, last edited April 1993.
  21.  
  22. NOTE:  At the end of this message are some answers to frequently asked
  23. questions.  Please read them before you post.
  24.  
  25. -- What is comp.compilers?
  26.  
  27. It is a moderated usenet news group addressing the topics of compilers in
  28. particular and programming language design and implementation in general.
  29. It started in 1986 as a moderated mailing list, but interest quickly grew to
  30. the point where it was promoted to a news group.  Recent topics have
  31. included optimization techniques, language design issues, announcements of
  32. new compiler tools, and book reviews.
  33.  
  34. Messages come from a wide variety of people ranging from undergraduate
  35. students to well-known experts in industry and academia.  Authors live all
  36. over the world -- there are regular messages from the U.S, Canada, Europe,
  37. Australia, and Japan, with occasional ones from as far away as Malaysia.  I
  38. have no idea how large the readership is, since the anarchic nature of
  39. usenet makes it impossible to tell who reads it, but I believe that the total
  40. is in the tens of thousands.
  41.  
  42. Unless there is specific language to the contrary, each message represents
  43. only the personal opinion of its author.  I claim no compilation copyright on
  44. comp.compilers.  As far as I am concerned, anyone can reproduce any message
  45. for any purpose.  Individual authors may retain rights to their messages,
  46. although I will not knowingly post anything that does not permit unlimited
  47. distribution in any form.  If you find comp.compilers useful in writing a
  48. book, producing a product, etc., I would appreciate an acknowledgement of
  49. usenet and comp.compilers.
  50.  
  51. -- How do I receive it?
  52.  
  53. The easiest way is to read comp.compilers on a system that gets usenet news.
  54.  
  55. If you don't have access to usenet news, it's also available via E-mail via
  56. a LISTSERV forwarder at the American University.  To subscribe a person
  57. should send e-mail to listserv@american.edu with one line in the mail
  58. message (not in the subject!)  That line should read:
  59.  
  60.                         SUBSCRIBE COMPIL-L full_name
  61. for example:
  62.                         SUBSCRIBE COMPIL-L Ima Hacker
  63.  
  64. To get off the list the subscriber should send e-mail to the same address
  65. with the message:       SIGNOFF COMPIL-L
  66.  
  67. If you have problems getting on or off the list, please contact me.  In
  68. particular, if you want to use an address other than your own personal mail
  69. address, you have to ask me to set it up.  If I receive bounce messages for
  70. an address on the mailing list for two days in a row, I delete it.  If this
  71. happens to you and your address subsequently becomes reachable again, you
  72. can resubscribe.
  73.  
  74. -- How do I submit a message?
  75.  
  76. Mail it to compilers@iecc.cambridge.ma.us, also known as compilers@iecc.uucp
  77. or iecc!compilers.  I review messages nearly every day, usually including
  78. weekends, and most messages are posted to the net within a day after I
  79. receive them.  Occasionally when I go on vacation there may be up to a
  80. week's delay, though I try to send out a message when that will happen.
  81.  
  82. Most net news systems will automatically turn posted messages into mail to
  83. compilers, but some, particularly systems running notes, don't do that
  84. correctly.  As a result, I sometimes receive hundreds of copies of a
  85. message, all mangled slightly differently.  Please mail your contributions
  86. unless you're sure your posting software works correctly.
  87.  
  88. When you send a message to compilers, I understand that to mean that you
  89. want me to post it to usenet, which means it will be sent to tens of
  90. thousands of potential readers at thousands of computers all around the
  91. world.  It may also appear in a printed comp.compilers annual and other
  92. books, in the ACM SIGPLAN Notices, in on-line and off-line archives,
  93. CD-ROMs, and anywhere else that some reader decides to use it.
  94.  
  95. If you don't want me to post something, send it instead to
  96. compilers-request.  (See below.)
  97.  
  98. -- What happens to submitted messages?
  99.  
  100. Barring mail problems, they arrive in a special mailbox here at iecc.  I
  101. then edit the headers, trim down quoted text, fix typos and grammatical
  102. errors, remove cute signatures, and then post them to usenet.  If I think a
  103. message needs more editing than that, I return it to the author for
  104. rewriting.  The main reasons I return a message are that it appears more
  105. appropriate for another group, the message is too garbled to fix, it
  106. contains too much quoted material relative to the amount of new material, or
  107. I don't understand it.  I also usually return messages that directly attack
  108. individuals, since the net has plenty of other places for ad-hominem battles.
  109. Another possibility is that a message doesn't have a valid return e-mail
  110. address.  If your mail system insists on putting a bogus address in the From:
  111. line, be sure that you put a usable address in your signature.
  112.  
  113. If a message asks a simple question I sometimes answer it myself rather than
  114. posting it.  When two or three messages arrive with the same answer to a
  115. question, I usually post only one of them, with a comment crediting the
  116. others.
  117.  
  118. If you send in a message and don't either see it posted or receive something
  119. back in a few days, it probably got lost in the mail and you should contact
  120. me, preferably via a different mail route.  I post or respond to all
  121. messages except for ones that appear to have been sent by mistake, e.g. no
  122. contents, or contents consisting only of another quoted message.  Sometimes
  123. when I'm feeling exasperated I disregard messages that re-ask one of the
  124. frequently asked questions that are answered below.
  125.  
  126. One of the most time-consuming jobs in moderating the group is trimming down
  127. the quotes in followup articles.  In most cases, you can expect readers to
  128. have seen the previous article, so only a few lines of quoted text should be
  129. needed to remind the reader of the context.
  130.  
  131. I have installed a simple-minded quote filter that mechanically returns to
  132. the sender any message that contains more quoted than unquoted lines.  Please
  133. edit your quotes before you send in a response, to avoid having the filter
  134. bounce your message.  Since the quote filter is pretty dumb, I do look at
  135. bounced messages myself.  If the filter bounces a message of yours by mistake,
  136. don't panic -- it'll get posted anyway.
  137.  
  138. ``Help wanted'' and ``Position Available'' messages are collected each week
  139. and posted in a digest every Sunday.
  140.  
  141. -- How do I respond to the author of a message?
  142.  
  143. I try to be sure that every message contains valid From: and Reply-To:
  144. headers.  The automatic "reply" commands in most news readers let you send
  145. mail to the author.  If you're replying to a message in a digest, be sure
  146. to respond to the author of the particular message, not to the pseudo-author
  147. of the digest.
  148.  
  149. Some obsolete news readers attempt to reply using the Path: header, but for
  150. technical reasons the Path: header in a moderated message cannot point to
  151. the actual author.  In fact, the Path: header in a compilers message is
  152. deliberately a bad mail address, so if you have such a news reader you'll
  153. have to edit the addresses in responses yourself and, I hope, encourage your
  154. system manager to update your news and mail software.
  155.  
  156. Sometimes mail to an author bounces, either because a gateway isn't
  157. working or because the return address is unregistered or otherwise bad.
  158. Please don't ask me to forward it, since my machine is no better connected
  159. than anyone else's.  (It's not on the Internet and only talks uucp.)  If
  160. you send me a message obviously intended for the author of an item, I will
  161. discard it on the theory that if it wasn't important enough for you to
  162. send it to the right place, it isn't important enough for me, either.
  163.  
  164. -- How do I contact the moderator?
  165.  
  166. Send me mail at compilers-request@iecc.cambridge.ma.us.  If for some
  167. reason your system chokes on that address (it shouldn't, it's registered)
  168. mail to Levine-John@yale.edu or johnl@spdcc.com will get to me.  I treat
  169. messages to compilers-request as private messages to me unless they state
  170. that they are for publication.
  171.  
  172. -- Are back issues available?
  173.  
  174. I have complete archives going back to the original mailing list in 1986.
  175. The archives now fill about 6 megabytes, and are growing at over 200K per
  176. month.  I update the archives at the end of each month.  People with ftp
  177. access can get them from primost.cs.wisc.edu, (128.105.2.115) where James
  178. Larus has kindly provided space.  The archives contain a compressed Unix
  179. mailbox format file for each month, with names like 91-08.Z.  The file
  180. INDEX.Z lists all of the subject lines for every message in the archives,
  181. and in most cases is the first file you should retrieve.
  182.  
  183. The archives are available via modem from Channel One, an excellent local
  184. BBS.  You have to register, but no payment is needed to download the
  185. archives which are in Area 6.  (If you call more than once or twice, it
  186. would be nice to sign up for at least the $25 trial membership.)  The 2400
  187. BPS telephone number is +1 617 354 8873, and the Telebit number is +1 617
  188. 354 0470.  There is a ZIP format archive per month with names like
  189. comp9108.zip, with the most recent archive also containing the index.
  190.  
  191. There is now a mail server at compilers-server@iecc.cambridge.ma.us that can
  192. mail you indexes, messages, and the files mentioned below.  Send it a
  193. message containing "help" to get started.
  194.  
  195. I have also published a printed edition of the 1990 messages grouped
  196. by thread and topic, and with some indexes, and expect to publish a
  197. 1992 and maybe 1991 edition.  Send me mail for further details, or
  198. see the message about the book which should immediately follow this
  199. one.
  200.  
  201. -- Some Frequently Asked Questions:
  202.  
  203. NOTE: Many issues are discussed occasionally on comp.compilers, but not
  204. frequently enought to make the FAQ sheet.  If you have a question but the
  205. answer isn't in the FAQ, you may well be able to get good background by
  206. reading the appropriate articles in the archive.  If you can FTP, please
  207. at least get the index and look through it.
  208.  
  209. The various files that I mention below that I have are in the compilers
  210. archive at primost.cs.wisc.edu, and are also available from the mail
  211. server mentioned above.  If you can FTP them, please do so rather than
  212. using the mail server, since the mail bandwith is quite small.
  213.  
  214. * Where can I get a C or C++ grammar in yacc?
  215.  
  216. Jim Roskind's well-known C++ grammar is in the archive, as is a C grammar
  217. written by Jeff Lee.  Dave Jones posted a parser as message 91-09-030.
  218. Another C grammar was posted to comp.sources.misc in June 1990, v13 i52,
  219. archive name ansi-c_su.  GCC and G++ are based on yacc grammars, see
  220. below.
  221.  
  222. * Where can I get the Gnu C compiler?
  223.  
  224. GCC is a high-quality free C and C++ compiler.  (Free is not the same as
  225. public domain, see the GCC distribution for details.)  It is available in
  226. source from from prep.ai.mit.edu.  You need an existing C compiler and
  227. libraries to bootstrap it.
  228.  
  229. A version for 386 MS-DOS by DJ Delorie <dj@ctron.com> is available by FTP
  230. from barnacle.erc.clarkson.edu or wowbagger.pc-labor.uni-bremen.de and by
  231. mail from archive-server@sun.soe.clarkson.edu in the archive msdos/djgpp.
  232. See messages 91-09-054 and 91-09-066.
  233.  
  234. * Are there other free C compilers?
  235.  
  236. The lcc compiler, written by people at Princeton and Bell Labs, is
  237. available via FTP from princeton.edu.  It is supposed to generate code as
  238. good as GCC while being considerably faster and smaller.  It comes with a
  239. demonstration VAX code generator and documentation on the code generation
  240. interfaces.  Production code generators for the VAX, MIPS, and Motorola
  241. 68020 are available for research use to universities willing to execute a
  242. license agreement; the FTP package elaborates.  Lcc uses a hard-coded C
  243. parser because it's faster than yacc.
  244.  
  245. * Where can I get a Fortran grammar in yacc or a Fortran compiler?
  246.  
  247. I have a small subset parser in the archive mentioned above.  The F2C
  248. Fortran to C translator is a respectable Fortran system (so long as
  249. you have a C compiler to compile its output and its libraries) and
  250. contains a full F77 parser and is available in source form via FTP
  251. from research.att.com and by mail from netlib@research.att.com.
  252.  
  253. * Where can I get Modula-2, Pascal or Ada grammars in yacc?
  254.  
  255. I have one each of those, too, in the archive mentioned above, though I
  256. haven't tried to use any of them.
  257.  
  258. * Where can I get a Cobol grammar in yacc?
  259.  
  260. Nowhere for free, as far as I can tell.  This question is asked every few
  261. months and there has never, ever, been any positive response. Perhaps some
  262. of the interested people could get together and write one.  The commercial
  263. PCYACC from Abraxas (see below) comes with a bunch of sample grammars
  264. including one for Cobol-85.
  265.  
  266. * Where can I get a Basic grammar in yacc?
  267.  
  268. Take a look at ftp.uu.net:comp.sources.unix/volume2/basic which contains
  269. a Basic interpreter with yacc parser.
  270.  
  271. * Are there free versions of yacc and lex ?
  272.  
  273. Vern Paxton's flex is a superior reimplementation of lex.  It is available
  274. from the same places as Gnu sources.  Berkeley Yacc is a quite compatible
  275. PD version of yacc by Bob Corbett, available as ~ftp/pub/byacc.tar.Z on
  276. okeeffe.berkeley.edu.  Gnu Bison is derived from an earlier version of
  277. Corbett's work and is also fairly compatible with yacc.
  278.  
  279. * Are there versions of yacc and lex for MS-DOS?
  280.  
  281. There are several of them.  Commercial versions are MKS lex&yacc from MKS
  282. in Waterloo Ont., +1 519 884 2251 or inquiry@mks.com, and PCYACC from
  283. Abraxas Software in Portland OR, +1 503 244 5253.  Both include both yacc
  284. and lex along with a lot of sample code.
  285.  
  286. The standard flex source compiles under the usual DOS compilers, although
  287. you may want to make some of the buffers smaller.  A DOS version of Bison
  288. is on wuarchive.wustl.edu [128.252.135.4] and other servers under
  289. /mirrors/msdos/txtutl/bison111.zip. See message 92-07-012 for more info.
  290.  
  291. * What other compilers and tools are freely available?
  292.  
  293. There is a three-part FAQ posting in comp.compilers and other groups
  294. listing compiler tools freely available in source form, maintained by
  295. David Muir Sharnoff <muir@cogsci.berkeley.edu>.  It is posted
  296. monthly, right after this message.  If it's not on your system, you
  297. can FTP it from pit-manager.mit.edu in the directory
  298. /pub/usenet/news.answers/free-compilers, or via mail by sending a
  299. message to to mail-server@pit-manager.mit.edu with the command "send
  300. usenet/news.answers/free-compilers/*" in the text.
  301.  
  302. * How can I get started with yacc and lex and compiler writing in general?
  303.  
  304. By reading any of the many books on the topic.  Here are a few of them.
  305. Also see message 93-01-155 which reviews many compiler textbooks.
  306.  
  307. Aho, Sethi, and Ullman, "Compilers: Principles, Techniques, and Tools,"
  308. Addison Wesley, 1986, ISBN 0-201-10088-6, the "dragon book".  Describes
  309. clearly and completely lexing and parsing techniques including the ones in
  310. yacc and lex.  The authors work or have worked at Bell Labs with Steve
  311. Johnson and Mike Lesk, the authors of Yacc and Lex.
  312.  
  313. Alan Holub, "Compiler Design in C," Prentice-Hall, 1990, ISBN
  314. 0-13-155045-4.  A large book containing the complete source code to a
  315. reimplementation of yacc and lex and a C compiler.  Quite well written,
  316. too, though it has a lot of errors.  The fourth printing is supposed to
  317. correct most of them.
  318.  
  319. John R. Levine, Tony Mason, and Doug Brown, ``Lex & Yacc,'' 2nd Edition,
  320. O'Reilly and Associates, 1992, ISBN 1-56592-000-7, $29.95.  A concise
  321. introduction with completely worked out examples and an extensive
  322. reference section.  The new edition is completely revised from the earlier
  323. 1990 edition.
  324.  
  325. Donnely and Stallman, "The Bison Manual," part of the on-line distrubution
  326. of the FSF's Bison, a reimplementation of yacc.  As with everything else from
  327. the FSF, full source code is included.
  328.  
  329. Axel T. Schreiner and H. George Friedman, Jr., "Introduction to Compiler
  330. Construction with UNIX," Prentice-Hall, 1985.  Oriented to tutorial work.
  331. Good for beginners.  Develops a small subset-of-C compiler through the book.
  332. (Recommended by Eric Hughes <hughes@ocf.Berkeley.EDU>.)  Richard Hash
  333. <rgh@shell.com> comments that the book has many typographical errors, and
  334. readers should be suspicious of the examples until they actually try them.
  335. Richard Y. Kim <richard@ear.mit.edu> reports that sources are available for
  336. FTP as a.cs.uiuc.edu:pub/friedman/tar.
  337.  
  338. Bennett, J.P. "Introduction to Compiling Techniques - A First Course Using
  339. Ansi C, Lex and Yacc," McGraw Hill Book Co, 1990, ISBN 0-07-707215-4.
  340. It's intended for a first course in modern compiler techniques, is very
  341. clearly written, and has a full chapter on YACC.  I found it to be a good
  342. introductory text before getting into the 'Dragon book'.  (Recommended by
  343. John Merlin <J.H.Merlin@ecs.southampton.ac.uk>.)  Source code is available
  344. at ftp.bath.ac.uk.
  345.  
  346. Charles N. Fischer & Richard J. LeBlanc, "Crafting A Compiler", Benjamin
  347. Cummings Publishing, Menlo Park, CA, 1988, ISBN 0-8053-3201-4.  There's
  348. also a revised version as of 1990 or 1991 titled "Crafting A Compiler in
  349. C", with all examples in C (the original used ADA/CS).  Erich Nahum
  350. <nahum@cs.umass.edu> writes: A key compiler reference.  We used the
  351. original to great effect in Eliot Moss' graduate compiler construction
  352. class here at UMass.  My feeling is that Fischer & LeBlanc is a good
  353. tutorial, and one should use Aho, Sethi, & Ullman as a reference.
  354.  
  355. Des Watson, "High-Level Languages and Their Compilers," International
  356. Computer Science Series, Addison-Wesley Publishing Company, Wokingham
  357. England, 1989.  Adrian Howard <adrianh@cogs.sussex.ac.uk> writes: This is
  358. the kindest, most readable introduction to compilers at the graduate level
  359. I have ever read - an excellent example of what textbooks should all be
  360. like.
  361.  
  362. W.M. Waite and G. Goos, "Compiler Construction," Springer-Verlag, New
  363. York, 1984.  Dick Grune <dick@cs.vu.nl> writes: A theoretical approach to
  364. compiler construction. Refreshing in that it gives a completely new view
  365. of many subjects. Heavy reading, high information density.
  366.  
  367. J.P. Tremblay and P.G. Sorenson, "The Theory and Practice of Compiler
  368. Writing," McGraw-Hill, 1985.  Dick Grune <dick@cs.vu.nl> writes: Extensive
  369. and detailed. Heavy reading. To be consulted when other sources fail.
  370.  
  371. James E. Hendrix, "The Small-C Compiler", 2nd ed., M&T Books, ISBN
  372. 0-934375-88-7 <Book Alone>, 1-55851-007-9 <MS-DOS Disk>,
  373. 0-934375-97-6 <Book AND Disk>.
  374.  
  375. William Jhun <ec_ind03@oswego.edu> writes: It explaines the C-language is
  376. thorough....and explains every single aspect of the compiler. The book
  377. compares source code to p-code to assembly. It goes over a nice set of
  378. optimization routines, explains the parser, the back end, and even
  379. includes source code, which the compiler on the disk can actually compile
  380. itself. It's an extremely interesting book, check it out.
  381.  
  382. If anyone sends in others, I'll be happy to add them to the list.
  383.  
  384. * Where I can I FTP the sources to the programs in Holub's "Compiler
  385. Design in C" ?
  386.  
  387. You can't.  See page xvi of the Preface for ordering information.
  388.  
  389. Regards,
  390. John Levine, comp.compilers moderator
  391. -- 
  392. Send compilers articles to compilers@iecc.cambridge.ma.us or
  393. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  394.  
  395.  
  396. From compilers Thu Apr  1 07:00:19 EST 1993
  397. Newsgroups: comp.compilers
  398. Path: iecc!compilers-sender
  399. From: compilers-request@iecc.cambridge.ma.us (John R. Levine)
  400. Subject: Comp.compilers 1990 Annual
  401. Message-ID: <book-Apr-93@comp.compilers>
  402. Keywords: administrivia
  403. Sender: compilers-sender@iecc.cambridge.ma.us
  404. Supersedes: <book-Mar-93@comp.compilers>
  405. Organization: Compilers Central
  406. Date: Thu, 1 Apr 1993 12:00:15 GMT
  407. Approved: compilers@iecc.cambridge.ma.us
  408. Expires: Sat, 1 May 1993 23:59:00 GMT
  409.  
  410. NOTE: This is a monthly repost of the message about the printed version of
  411. the 1990 comp.compilers message.
  412.  
  413.             Comp.compilers 1990 Annual
  414.              Edited by John R. Levine
  415.  
  416. The Comp.compilers 1990 Annual is a printed edition of the messages posted
  417. to the usenet newsgroup comp.compilers in 1990.  Usenet is an informal
  418. distributed electronic bulletin board system connecting thousands of
  419. computers around the world.  Most of the systems attached to it run some
  420. version of Unix, though others systems ranging from MS-DOS personal
  421. computers to Cray mainframes now participate.  Comp.compilers is a
  422. moderated usenet news group addressing the topics of compilers in
  423. particular and programming language design and implementation in general.
  424. It started in 1986 as a moderated mailing list, but interest quickly grew
  425. to the point where it was promoted to a news group.  Recent topics have
  426. included optimization techniques, language design issues, announcements of
  427. new compiler tools, and book reviews.
  428.  
  429. Messages come from a wide variety of people ranging from undergraduate
  430. students to well-known experts in industry and academia.  Authors live all
  431. over the world - there are regular messages from the U.S, Canada, Europe,
  432. Australia, and Japan, with occasional ones from as far away as Malaysia.
  433. The anarchic nature of usenet makes it impossible to tell how large the
  434. readership is, but the total is probably in the tens of thousands.
  435.  
  436. The book's contents include 807 of the year's total 914 messages, leaving
  437. out only administrative messages and unanswered questions.  The messages
  438. themselves are unedited except for removing boilerplate header and trailer
  439. lines.
  440.  
  441. The book is 604 pages, each 11 x 8.5 inches with two pages of text side by
  442. side in reasonably legible 8 point type.  Messages are grouped by topic
  443. (C, optimization, book reviews, etc.) and within each topic messages in a
  444. thread are grouped together.  There is a permuted subject index, a keyword
  445. index, and an author index.  The book is GBC bound, a plastic spiral
  446. binding that lies flat.
  447.  
  448. Pricing
  449.  
  450. The price is $40 per book, plus $2 sales tax for copies delivered in
  451. Massachusetts, plus appropriate postage and packaging per copy:
  452.  
  453.   Pick up in Cambridge  free |  Foreign surface        $10
  454.   U.S. surface            $3 |  Foreign airmail:
  455.   U.S. priority           $5 |             Americas    $12
  456.   U.S. Federal Express   $20 |             Europe      $20
  457.   Canada              $7 |             All other   $30
  458.  
  459. No further discounts apply on single copies of the book, as this price is
  460. pre-discounted from the list price of $50.  Quantity discounts and
  461. shipping charges for large or unusual orders can be negotiated.
  462.  
  463. How to order
  464.  
  465. All orders must be prepaid.  Send a check payable to I.E.C.C. along with
  466. the delivery address.  We cannot take purchase orders, credit cards, or
  467. COD orders.  Foreign orders must be prepaid in U.S. dollars, preferably by
  468. a check on a U.S. bank, but anything our bank can handle is acceptable.
  469. (They charge $20 extra for foreign checks and $5 for incoming bank wires.)
  470.  
  471. The mailing address is:
  472.  
  473. I.E.C.C.
  474. P.O. Box 349
  475. Cambridge MA 02238-0349
  476.  
  477. The book is also available at list price from several bookstores.
  478. Being real bookstores, they take credit cards and the like.
  479.  
  480.     Computer Literacy Bookshop, 2590 N 1st St, San Jose CA 95131
  481.         +1 408 435 1118, orders@clbooks.com
  482.  
  483.     Quantum Books, 4 Cambridge Center, Cambridge MA 02141
  484.         +1 617 494 5042, quanbook@world.std.com
  485.  
  486. The book has ISBN 0-944954-02-2, and is under the imprint of Center Book
  487. Publishers, Inc.
  488. -- 
  489. Send compilers articles to compilers@iecc.cambridge.ma.us or
  490. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  491.  
  492.  
  493. From compilers Thu Apr  1 07:00:28 EST 1993
  494. Xref: iecc comp.compilers:4461 comp.lang.misc:9656 comp.sources.d:4721 comp.archives.admin:881 news.answers:6792
  495. Newsgroups: comp.compilers,comp.lang.misc,comp.sources.d,comp.archives.admin,news.answers
  496. Path: iecc!compilers-sender
  497. From: David Muir Sharnoff <muir@idiom.berkeley.ca.us>
  498. Subject: Catalog of compilers, interpreters, and other language tools [p1of3]
  499. Message-ID: <free1-Apr-93@comp.compilers>
  500. Followup-To: comp.archives.admin
  501. Summary: montly posting of free language tools that include source code
  502. Keywords: tools, FTP, administrivia
  503. Sender: compilers-sender@iecc.cambridge.ma.us
  504. Supersedes: <free1-Mar-93@comp.compilers>
  505. Reply-To: muir@idiom.berkeley.ca.us
  506. Organization: University of California, Berkeley
  507. Date: Thu, 1 Apr 1993 12:00:23 GMT
  508. Approved: compilers@iecc.cambridge.ma.us
  509. Expires: Sat, 1 May 1993 23:59:00 GMT
  510.  
  511. Archive-name: free-compilers/part1
  512. Last-modified: 1993/03/24
  513. Version: 3.2
  514.  
  515.  
  516.     Catalog of Free Compilers and Interpreters.
  517.  
  518. This document attempts to catalog freely availiable compilers,
  519. interpreters, libraries, and language tools.  This is still a draft
  520. document: it has errors, it is not complete, and I might re-organize
  521. it.  It is my intention that it be aimed at developers rather than
  522. researchers.  I am much more intersted in production quality systems.
  523.  
  524. There is some overlap of coverage between this document and other
  525. lists and catalogs.  See the references section for a list...
  526.  
  527. To be on this list a package must be free and have source code
  528. included.  If there are any packages on this list that do not have
  529. source code included or are not free, then I would appreciate it if it
  530. is brought to my attention so that I may correct the error.
  531.  
  532. There are many fields filled in with a question mark (?).  If you have
  533. information which would allow me to remove question marks, please
  534. send it to me.    The only field which I do not expect to be completely
  535. obvious is the "parts" field because I wish to distinguish between 
  536. compilers, translators, and interpretors.  To qualify as a compiler
  537. as I'm using the term, it must compile to a machine-readable format 
  538. no higher-level than assembly.    Why?  Just because.  If you've
  539. got a better idea, send it in.
  540.  
  541. This document may be ftp'ed from idiom.berkeley.ca.us.  Be nice to my 
  542. SLIP link.  
  543.  
  544. If you would be interested in purchasing a CD-ROM with a complete 
  545. set of the source code listed here, let me know.  If enough people 
  546. are interested, I might cut a disc.  Bear in mind that you can get
  547. most, if not all, of this from Prime Time Freeware's disc set.
  548. Or would you be more interested in sparc binaries?  $250 interested?
  549. Or would you like to either take over maintenance of this document
  550. or pay me to keep doing it?  (hint: maintaining this is taking too
  551. much of my time)
  552.  
  553. David Muir Sharnoff <muir@idiom.berkeley.ca.us>, 1993/02/13
  554.  
  555. ------------------------- selected major changes ------------------------------
  556.  
  557.     Selected changes section
  558.  
  559.     language        package
  560.     --------        -------
  561. new listings:
  562.     Ada            Adamakegen
  563.     Assembler (various)    GNU assembler (GAS)
  564.     Assembler (multpl 8bit)    ?
  565.     Assembler (DSP56k)    ? [5]
  566.     BNF (yacc), Ada        aflex-ayacc [1]
  567.     C            GNU superoptimizer
  568.     C            MasPar mpl & ampl
  569.     C            dsp56k-gcc [5]
  570.     C            dsp56165-gcc [5]
  571.     C (Duel)        DUEL (a <practical> C debugging language)
  572.     C, C++, Objective-C    GNU CC [so, I'm a bit slow --muir]
  573.     C, C++            Xcoral
  574.     C++            aard ?
  575.     CASE - DSP        Ptolomy [5]
  576.     CLU            SUN CLU
  577.     E            Amiga E
  578.     E (a persistent C++)    GNU E
  579.     elisp            GNU Emacs
  580. :    es (a functional shell)    es
  581.     math manipulation    FUDGIT
  582.     math - unix bc        GNU BC
  583.     math - symbolic calcltr    GNU Calc
  584.     Modula-2        PRAM emulator and parallel modula-2 compiler
  585.     Modual-2, Modula-3    M2toM3
  586.     NewsClip        NewsClip
  587.     Pascal            a frontend
  588.     Pascal            tptc
  589.     Pascal            ptc
  590.     Prolog            BinProlog [2]
  591.     Prolog            2? (@aisun1.ai.uga.edu) [2]
  592.     Prolog            ? (@aisun1.ai.uga.edu) [2]
  593.     Prolog            Open Prolog [2]
  594.     Prolog            UPMAIL Tricia Prolog [2]
  595.     Prolog            Modular SB-Prolog [2]
  596.     Prolog ?         BABYLON [3]
  597.     Prolog            XWIP (X Window Interface for Prolog)
  598.     Prolog            PI 
  599.     Scheme            PCS/Geneva [4]
  600.     Simula            Cim
  601.     Sisal            Optimizing Sisal Compiler ?
  602.     Standard ML        The ML Kit
  603.     Tcl            Tcl/Tk Contrib Archive
  604.     troff            groff [care to make a TeX entry?  --muir]
  605.     VHDL            ALLIANCE
  606. new versions:
  607.     C, C++, ...        gdb 4.8
  608.     C, nroff        c2man 1.10
  609.     Common Lisp        CLISP 1993/03/10
  610.     BNF (yacc)        byacc 1.9
  611.     Gopher            Gopher 2.28a
  612.     lisp            RefLisp 2.67
  613.     Logo            Berkeley Logo 2.9 alpha
  614.     Logo            MswLogo 3.2
  615.     Milarepa        Milarepa Prototype 1.0 
  616.     Modula-3        SRC Modual-3 2.11
  617.     perl, yacc        perl-byacc 1.8.2
  618.     Sather            Sather 0.2i
  619.     Scheme            scm 4b4
  620.     Scheme            Scheme->C 15mar93
  621.     sed            GNU sed 1.11
  622.     SGML            sgmls 1.1
  623.     Tcl            Tcl 6.6, Tk 3.1
  624. edits:
  625.     Extended BNF, Modula-2    GMD Compiler Toolbox (aka Cocktail)
  626.     rc (plan 9 shell)    rc
  627.     J            J
  628.     Scheme            PC-Scheme [4]
  629. deleted (no source):
  630.     Modula-2        fst
  631.     Modula-2, Pascal    metro
  632.     Oberon            Oberon from ETH Zurich
  633.  
  634.  
  635. [1] New info from the Language List by Bill Kinnersley
  636. [2] New info from comp.lang.prolog FAQ by Jamie Andrews
  637. [3] New info from the Lisp FAQ by Mark Kantrowitz
  638. [4] New info from the Scheme FAQ by Mark Kantrowitz
  639. [5] New info from the comp.dsp FAQ by Phil Lapsley
  640.  
  641. -------------------------------------------------------------------------------
  642. ------------------------------- tools -----------------------------------------
  643. -------------------------------------------------------------------------------
  644.  
  645. language:    ABC
  646. package:    ABC
  647. version:    1.04.01
  648. parts:        ?
  649. author:        Leo Geurts, Lambert Meertens, 
  650.         Steven Pemberton <Steven.Pemberton@cwi.nl>
  651. how to get:    ftp programming/languages/abc/* from mcsun.eu.net or ftp.eu.net
  652. description:    ABC is an imperative language embedded in its own
  653.         environment. It is interactive, structured,
  654.         high-level, very easy to learn, and easy to use.
  655.         It is suitable for general everyday programming,
  656.         such as you would use BASIC, Pascal, or AWK for.
  657.         It is not a systems-programming language. It is an
  658.         excellent teaching language, and because it is
  659.         interactive, excellent for prototyping.     ABC programs
  660.         are typically very compact, around a quarter to a
  661.         fifth the size of the equivalent Pascal or C program.
  662.         However, this is not at the cost of readability,
  663.         on the contrary in fact.
  664. references:    "The ABC Programmer's Handbook" by Leo Geurts,
  665.         Lambert Meertens and Steven Pemberton, published by 
  666.         Prentice-Hall (ISBN 0-13-000027-2)
  667.         "An Alternative Simple Language and Environment for PCs" 
  668.         by Steven Pemberton, IEEE Software, Vol. 4, No. 1, 
  669.         January 1987, pp.  56-64.
  670. ports:        unix, MSDOS, atari, mac
  671. contact:    abc@cwi.nl
  672. updated:    1991/05/02
  673.  
  674. language:    ABCL/1 (An object-Based Concurrent Language)
  675. package:    ABCL/1 
  676. version:    ?
  677. parts:        ?
  678. author:        Akinori Yonezawa, ABCL Group now at Department of Information 
  679.         Science, the University of Tokyo
  680. how to get:    ftp pub/abcl1/* from camille.is.s.u-tokyo.ac.jp
  681. description:    Asynchronous message passing to objects.  
  682. references:    "ABCL: An Object-Oriented Concurrent System", Edited by 
  683.         Akinori Yonezawa, The MIT Press, 1990, (ISBN 0-262-24029-7)
  684. restriction:    no commercial use, must return license agreement
  685. requires:    Common Lisp
  686. contact:    abcl@is.s.u-tokyo.ac.jp
  687. updated:    1990/05/23
  688.  
  689. language:    ABCL ???
  690. package:    ABCL/R2
  691. version:    ?
  692. author:        masuhara@is.s.u-tokyo.ac.jp, matsu@is.s.u-tokyo.ac.jp,
  693.         takuo@is.s.u-tokyo.ac.jp, yonezawa@is.s.u-tokyo.ac.jp
  694. how to get:    ftp pub/abclr2/* from camille.is.s.u-tokyo.ac.jp
  695. description:    ABCL/R2 is an object-oriented concurrent reflective language
  696.         based on Hybrid Group Architecture.  As a reflective language,
  697.         an ABCL/R2 program can dynamically control its own behavior,
  698.         such as scheduling policy, from within user-program.  An an
  699.         object-oriented concurrent language, this system has almost all
  700.         functions of ABCL/1.
  701. requires:    Common Lisp
  702. updated:    1993/01/28
  703.  
  704. language:    Ada
  705. package:    Ada/Ed
  706. version:    1.11.0a+
  707. parts:        translator(?), interpreter, ?
  708. author:        ?
  709. how to get:    ftp pub/Ada/Ada-Ed from cnam.cnam.fr
  710. description:    Ada/Ed is a translator-interpreter for Ada. It is
  711.         intended as a teaching tool, and does not have the
  712.         capacity, performance,    or robustness of commercial
  713.         Ada compilers. Ada/Ed was developed at New York
  714.         University, as part of a long-range project in
  715.         language definition and software prototyping.
  716. conformance:    last validated with version 1.7 of the ACVC tests.
  717.         being an interpreter, it does not implement most 
  718.         representation clauses, and thus does not support systems 
  719.         programming close to the machine level.
  720. contact:    ? Michael Feldman <mfeldman@cs.washington.edu> ?
  721. updated:    1992/05/08
  722.  
  723. language:    Ada
  724. package:    Ada grammar
  725. version:    ?
  726. parts:        scanner(lex), parser(yacc)
  727. how to get:    ftp from primost.cs.wisc.edu or mail to
  728.         compilers-server@iecc.cambridge.ma.us
  729. contact:    masticol@dumas.rutgers.edu
  730. updated:    1991/10/12
  731.  
  732. language:    Ada
  733. package:    Compiler for Toy/Ada in SML/NJ
  734. version:    ?
  735. parts:        translator(?)
  736. author:        Amit Bhatiani <bhatiaa@polly.cs.rose-hulman.edu>
  737. how to get:    ftp pub/compiler*.tar.Z from master.cs.rose-hulman.edu
  738. conformance:    subset
  739. updated:    1992/04/08
  740.  
  741. language:    Ada
  742. package:    NASA PrettyPrinter
  743. version:    ?
  744. parts:        Ada LR parser, ?
  745. how to get:    ftp from Ada Software Repository on wsmr-simtel20.army.mil
  746. description:    pretty-print program that contains an ada parser
  747. requires:    Ada
  748. info-source:    Michael Feldman <mfeldman@seas.gwu.edu> in comp.compilers
  749.         [he also has a yacc grammar for ada]
  750. updated:    1991/02/01
  751.  
  752. language:    Ada
  753. package:    yacc grammar for Ada
  754. version:    ?
  755. parts:        parser(yacc)
  756. author:        Herman Fischer
  757. how to get:    ftp  PD2:<ADA.EXTERNAL-TOOLS>GRAM2.SRC 
  758.         from wsmr-simtel20.army.mil
  759. contact:    ?
  760. updated:    1991/02/01
  761.  
  762. language:    Ada
  763. package:    Paradise
  764. version:    2.0
  765. parts:        library
  766. how to get:    ftp pub/Ada/Paradise from cnam.cnam.fr
  767. author:        ?
  768. description:    Paradise is a subsystem (a set of packages) developped
  769.         to implement inter-processes, inter-tasks and
  770.         inter-machines communication for Ada programs in
  771.         the Unix world. This subsystem gives the user full
  772.         access to files, pipes, sockets (both Unix and
  773.         Internet), and pseudo-devices.
  774. ports:        Sun, Dec, Sony Mips, Verdex compiler, DEC compiler, 
  775.         Alsys/Systeam compiler
  776. contact:    paradise-info@cnam.cnam.fr
  777. updated:    1992/09/30
  778.  
  779. language:    Ada
  780. package:    Adamakegen
  781. version:    2.6.3
  782. parts:        makefile generator
  783. author:        Owen O'Malley <omalley@porte-de-st-ouen.ics.uci.edu>
  784. how to get:    ftp ftp/pub/arcadia/adamakegen* from spare.ics.uci.edu
  785. description:    A program that generates makefiles for Ada programs 
  786. requires:    Icon
  787. ports:        Verdix, SunAda 
  788. updated:    1993/03/02
  789.  
  790. language:    ADL (Adventure Definition Language)
  791. package:    ADL
  792. parts:        interpreter
  793. author:        Ross Cunniff <cunniff@fc.hp.com>, Tim Brengle
  794. how to get:    comp.sources.games archive volume 2
  795. description:    An adventure language, semi-object-oriented with LISP-like
  796.         syntax.     A superset of DDL.
  797. updated:    ?
  798.  
  799. language:    Algol, Foogol
  800. package:    foogol
  801. version:    ?
  802. parts:        compiler
  803. author:        ?
  804. how to get:    comp.sources.unix archive volume 8
  805. conformance:    subset of Algol
  806. description:    ?
  807. ports:        VAX
  808. updated:    ?
  809.  
  810. language:    ALLOY
  811. package:    ALLOY
  812. version:    2.0?
  813. parts:        interpreter, documentation, examples
  814. author:        Thanasis Mitsolides <mitsolid@cs.nyu.edu>
  815. how to get:    ftp pub/local/alloy/* from cs.nyu.edu
  816. description:    ALLOY is a higher level parallel  programming language
  817.         appropriate for programming  massively parallel computing
  818.         systems.   It is based on  a combination  of  ideas from
  819.         functional,  object oriented  and logic programming languages.
  820.         The  result  is     a  language that can  directly support
  821.         functional, object  oriented  and logic     programming  styles
  822.         in a  unified  and controlled framework.   Evaluating modes
  823.         support serial    or parallel execution,    eager or  lazy
  824.         evaluation,  non-determinism or     multiple solutions etc.
  825.         ALLOY is  simple as it only requires  29 primitives in all
  826.         (half of which for Object Oriented Programming support).
  827. ports:        sparc, ?
  828. updated:    1991/06/11
  829.  
  830. language:    APL
  831. package:    I-APL
  832. how to get:    ftp languages/apl/* from watserv1.waterloo.edu
  833. updated:    1992/07/06
  834.  
  835. language:    APL
  836. package:    APLWEB
  837. version:    ?
  838. parts:        translator(web->apl), translator(web->TeX)
  839. author:        Dr. Christoph von Basum <CvB@erasmus.hrz.uni-bielefeld.de>
  840. how to get:    ftp languages/apl/aplweb/* from watserv1.uwaterloo.ca
  841. updated:    1992/12/07
  842.  
  843. language:    Assembler (various)
  844. package:    GNU assembler (GAS)
  845. version:    2.0
  846. parts:        assembler, documentation
  847. how to get:    ftp gas-2.0.tar.z from a GNU archive site
  848. description:    Many CPU types are now handled, and COFF and IEEE-695 formats
  849.         are supported as well as standard a.out.
  850. ports:        Sun-3, Sun-4, i386/{386BSD, BSD/386, Linux, PS/2-AIX},
  851.         VAX/{Ultrix,BSD,VMS}
  852. bugs:        bug-gnu-utils@prep.ai.mit.edu
  853. updated:    1993/03/09
  854.  
  855. language:    Assembler (8051)
  856. package:    CAS: The Free Full-Featured 8051 Assembler
  857. version:    1
  858. parts:        assembler
  859. author:        Mark Hopkins <markh@csd4.csd.uwm.edu>
  860. how to get:    ftp /pub/8051/assem from csd4.csd.uwm.edu
  861. description:    an Experimental public domain one-pass assembler for the 8051
  862.         with C-like syntax.  Related software contained in /pub/8051,
  863.         including arbitrary precision math, and multitasking routines.
  864. ports:        MSDOS, Ultrix, Sun (contact author)
  865. requries:    ANSI-C compiler
  866. updated:    1992/08/13
  867.  
  868. language:    Assembler (mc6809)
  869. package:    usim
  870. version:    0.11
  871. parts:        simulator, documentation
  872. author:        Ray P. Bellis <rpb@psy.ox.ac.uk>
  873. how to get:    ftp /pub/mc6809/usim-* from ftp.cns.ox.ac.uk
  874. description:    a mc6809 simulator
  875. updated:    1993/02/14
  876.  
  877. language:    Assembler (DSP56000)
  878. package:    ?
  879. version:    1.1
  880. parts:        assembler
  881. author:        Quinn Jensen <jensenq@qcj.icon.com>
  882. how to get:    alt.sources archive or ftp ? from wuarchive.wustl.edu
  883. description:    ?
  884. updated:    ?
  885.  
  886. language:    Assembler (6502, Z80, 8085, 68xx)
  887. package:    ?
  888. version:    ?
  889. author:        msmakela@cc.helsinki.fi and Alan R. Baldwin
  890. how to get:    ftp ? from ccosun.caltech.edu
  891. description:    I have enhanced a set of 68xx and Z80 and 8085 cross assemblers
  892.         to support 6502. These assemblers run on MS-DOS computers or on
  893.         any systems that support standard Kerninghan & Richie C, for
  894.         example, Amiga, Atari ST and any "big" machines
  895. updated:    1993/03/10
  896.  
  897. language:    ? attribute grammar ?
  898. package:    Alpha
  899. version:    pre-release
  900. parts:        semantic-analysis generator?, documentation(german)
  901. author:        Andreas Koschinsky <koschins@cs.tu-berlin.de>
  902. how to get:    from author
  903. description:    I have written a compiler generator. The generator is called
  904.         Alpha and uses attribute grammars as specification calculus.
  905.         Alpha is the result of a thesis at Technische Universitaet
  906.         Berlin. I am looking for someone who would like to test and use
  907.         Alpha.    Alpha generates compilers from a compiler
  908.         specification. This specification describes a compiler in
  909.         terminology of attribute grammars. Parser and Scanner are
  910.         generated by means of Bison and Flex.  Alpha generates an
  911.         ASE-evaluator (Jazayeri and Walter).  The documentation is in
  912.         german since it is a thesis at a german university.
  913. updated:    1993/02/16
  914.  
  915. language:    awk (new)
  916. package:    mawk
  917. version:    1.1.3
  918. how to get:    ftp public/mawk* from oxy.edu
  919. parts:        interpreter
  920. author:        Mike Brennan <brennan@bcsaic.boeing.com>
  921. conformance:    superset
  922.         + RS can be a regular expression
  923. features:    + faster than most new awks
  924. ports:        sun3,sun4:sunos4.0.3 vax:bsd4.3,ultrix4.1 stardent3000:sysVR3 
  925.         decstation:ultrix4.1 msdos:turboC++
  926. contact:    Mike Brennan <brennan@bcsaic.boeing.com>
  927. status:        actively developed
  928. updated:    1993/03/14
  929.  
  930. language:    awk (new)
  931. package:    GNU awk (gawk)
  932. version:    2.14
  933. parts:        interpreter, documentation
  934. author:        David Trueman <david@cs.dal.ca> and 
  935.         Arnold Robbins <arnold@cc.gatech.edu>
  936. how to get:    ftp gawk-2.14.tar.Z from a GNU archive site
  937. conformance:    superset
  938. ports:        unix, msdos:msc5.1
  939. status:        activly developed
  940. updated:    1992/11/18
  941.  
  942. language:    BASIC
  943. package:    bwBASIC (Bywater BASIC interpreter)
  944. version:    1.10
  945. parts:        interpreter, shell, ?
  946. author:        Ted A. Campbell <tcamp@acpub.duke.edu>
  947. how to get:    ftp pub/bywater/* from duke.cs.duke.edu
  948. description:    ?
  949. conformance:    large superset of ANSI Standard for Minimal BASIC (X3.60-1978)
  950. requires:    ANSI C
  951. ports:        DOS, Unix
  952. updated:    1992/11/05
  953.  
  954. language:    BASIC
  955. package:    ? basic ?
  956. version:    ?
  957. parts:        paser(yacc), interpreter
  958. author:        ?
  959. how to get:    comp.sources.unix archives volume 2
  960. updated:    ?
  961.  
  962. language:    BASIC
  963. package:    ? bournebasic ?
  964. version:    ?
  965. parts:        interpreter
  966. author:        ?
  967. how to get:    comp.sources.misc archives volume 1
  968. description:    ?
  969. updated:    ?
  970.  
  971. language:    BASIC
  972. package:    ? basic ?
  973. version:    ?
  974. parts:        interpreter
  975. author:        ?
  976. how to get:    ftp ? from wsmr-simtel20.army.mil
  977. description:    ?
  978. contact:    ?
  979. updated:    ?
  980.  
  981. language:    BASIC
  982. package:    ubasic
  983. version:    8
  984. parts:        ?
  985. author:        Yuji Kida
  986. how to get:    ? ask archie ?
  987. references:    reviewed in Notices of the A.M.S #36 (May/June 1989),
  988.         and "A math-oriented high-precision BASIC", #38 (3/91)
  989. contact:    ?
  990. updated:    1992/07/06
  991.  
  992. language:    BCPL
  993. package:    ?
  994. version:    ?
  995. author:        ?
  996. how to get:    ftp systems/amiga/programming/languages/BCPL/BCPL4Amiga.lzh
  997.         from wuarchive.wustl.edu.
  998. description:    The original INTCODE interpreter for BCPL.
  999. ports:        Amiga, UNIX, MSDOS
  1000. contact:    ?
  1001. updated:    ?
  1002.  
  1003. language:    BCPL
  1004. package:    ?
  1005. version:    ?
  1006. how to get:    ftp [.languages]bcpl.tar_z from ftp.syd.dit.csiro.au
  1007. description:    A BCPL* (Basic Combined Programming Language) compiler 
  1008.         bootstrap kit with an INTCODE interpreter in C.     
  1009. contact:    Ken Yap <ken@syd.dit.CSIRO.AU>
  1010. updated:    ?
  1011.  
  1012. language:    BNF (Extended)
  1013. package:    TXL: Tree Transformation Language
  1014. version:    6.0
  1015. parts:        translator generator
  1016. author:        Jim Cordy <cordy@qucis.queensu.ca>
  1017. how to get:    ftp txl/00README for instructions from qusuna.qucis.queensu.ca
  1018. description:    + TXL is a generalized source-to-source translation
  1019.         system suitable for rapidly prototyping computer
  1020.         languages and language processors of any kind.    It has
  1021.         been used to prototype several new programming
  1022.         languages as well as specification languages, command
  1023.         languages, and more traditional program transformation
  1024.         tasks such as constant folding, type inference, source
  1025.         optimization and reverse engineering.  TXL takes
  1026.         as input an arbitrary context-free grammar in extended
  1027.         BNF-like notation, and a set of show-by-example
  1028.         transformation rules to be applied to inputs parsed
  1029.         using the grammar.  
  1030. updated:    1992/02/23
  1031.  
  1032. language:    BNF (Extended)
  1033. package:    Gray
  1034. version:    3
  1035. parts:        parser generator(Forth)
  1036. author:        Martin Anton Ertl <anton@mips.complang.tuwien.ac.at>
  1037. how to get:    author; version 2 is on various ftp sites
  1038. description:    Gray is a parser generator written in Forth.  It takes 
  1039.         grammars in an extended BNF and produces executable Forth 
  1040.         code for recursive descent parsers.  There is no special 
  1041.         support for error handling.
  1042. requires:    Forth
  1043. ports:        TILE Release 2 by Mikael Patel
  1044. updated:    1992/05/22
  1045.  
  1046. language:    BNF ??
  1047. package:    ZUSE
  1048. version:    ?
  1049. parts:        parser generator(?)
  1050. author:        Arthur Pyster
  1051. how to get:    ? Univ Calif at Santa Barbara ?
  1052. description:    ll(1) paser generator
  1053. requires:    Pascal
  1054. updated:    1986/09/23
  1055.  
  1056. language:    BNF ??
  1057. package:    FMQ
  1058. version:    ?
  1059. parts:        paser generator w/error corrector generator
  1060. author:        Jon Mauney
  1061. how to get:    ftp from csczar.ncsu.edu
  1062. status:        ?
  1063. contact:    ?
  1064. updated:    1990/03/31
  1065.  
  1066. language:    BNF ??
  1067. package:    ATS (Attribute Translation System)
  1068. version:    ?
  1069. author:        ? University of Saskatchewan ?
  1070. how to get:    ?
  1071. description:    generates table-driven LL(1) parsers with full insert-only
  1072.         error recovery.     It also handles full left-attribute semantic
  1073.         handling, which is a dream compared to using YACC's parser
  1074.         actions.
  1075. contact:    ?
  1076. info-source:    Irving Reid <irving@bli.com> in comp.compilers
  1077. status:        ?
  1078. updated:    1988/11/29
  1079.  
  1080. language:    BNF (Extended)
  1081. package:    PCCTS (Purdue Compiler-Construction Tool Set)
  1082. version:    1.06
  1083. parts:        scanner generator, parser generator (LL(k)), documentation,
  1084.         tutorial
  1085. author:        Terence J. Parr <parrt@ecn.purdue.edu>, Will E. Cohen
  1086.         <cohenw@ecn.purdue.edu>, Henry G. Dietz <hankd@ecn.purdue.edu>
  1087. how to get:    ftp pub/pccts/1.06 from marvin.ecn.purdue.edu
  1088.     uk:        ftp /comput*/progra*/langu*/tools/pccts/* from src.doc.ic.ac.uk
  1089. description:    PCCTS is similar to a highly integrated version of YACC
  1090.         and LEX; where ANTLR (ANother Tool for Language
  1091.         Recognition) corresponds to YACC and DLG (DFA-based
  1092.         Lexical analyzer Generator) functions like LEX.
  1093.         However, PCCTS has many additional features which make
  1094.         it easier to use for a wide range of translation
  1095.         problems.  PCCTS grammars contain specifications for
  1096.         lexical and syntactic analysis, semantic predicates,
  1097.         intermediate-form construction and error reporting.
  1098.         Rules may employ Extended BNF (EBNF) grammar constructs
  1099.         and may define parameters, return values and local
  1100.         variables.  Languages described in PCCTS are recognized
  1101.         via LL(k) parsers constructed in pure, human-readable,
  1102.         C code.     PCCTS parsers may be compiled with C++.
  1103. ports:        UNIX, DOS, OS/2
  1104. portability:    very high
  1105. contact:    Terence J. Parr <parrt@ecn.purdue.edu>
  1106. updated:    1992/12/14
  1107.  
  1108. language:    Coco (BNF variant) ?
  1109. package:    Cocol ?
  1110. version:    2 ?
  1111. parts:        parser geneartor(LL(1))
  1112. description:    ?
  1113. status:        ?
  1114. contact:    Pat Terry?
  1115. updated:    ?
  1116.  
  1117. language:    BNF ??
  1118. package:    LLGen
  1119. version:    ?
  1120. parts:        parser generator
  1121. author:        ? Fischer and LeBlanc ?
  1122. how to get:    ? ftp from csczar.ncsu.edu ?
  1123. description:    LL(1) parser generator
  1124. conformance:    subset of FMQ
  1125. reference:    "Crafting A Compiler", by Fischer and LeBlanc
  1126. status:        ?
  1127. contact:    ?
  1128. updated:    1990/03/31
  1129.  
  1130. language:    BNF (Extended), BNF (yacc), Modula-2
  1131. package:    GMD Toolbox for Compiler Construction (aka Cocktail)
  1132. version:    9209
  1133. parts:        parser generator (LALR -> C, Modula-2), documentation,
  1134.         parser generator (LL(1) -> C, Modula-2), tests,
  1135.         scanner generator (-> C, Modula-2), tests
  1136.         translator (Extended BNF -> BNF), translator (Modula-2 -> C),
  1137.         translator (BNF (yacc) -> Extended BNF), examples
  1138.         abstract syntax tree generator, attribute-evaluator generator,
  1139. how to get:    ftp pub/cocktail/dos from ftp.karlsruhe.gmd.de
  1140.     OS/2:    ftp.eb.ele.tue.nl/pub/src/cocktail/dos-os2.zoo 
  1141. description:    A huge set of compiler building tools. 
  1142. requires:    (ms-dos only) DJ Delorie's DOS extender (go32)
  1143.         (OS/2 only) emx programming environment for OS/2
  1144. ports:        msdos, unix, os/2
  1145. contact:    Josef Grosch <grosch@karlsruhe.gmd.de>
  1146.     OS/2:    Willem Jan Withagen <wjw@eb.ele.tue.nl>
  1147. discussion:    subscribe to Cocktail using listserv@eb.ele.tue.nl
  1148. updated:    1992/10/01
  1149.  
  1150. language:    BNF ????
  1151. package:    T-gen
  1152. version:    2.1
  1153. parts:        parser generator, documentation, ?
  1154. author:        Justin Graver <graver@comm.mot.com>
  1155. how to get:    ftp pub/st80_r41/T-gen2.1/* from st.cs.uiuc.edu
  1156. description:    T-gen is a general-purpose object-oriented tool for the 
  1157.         automatic generation of string-to-object translators. 
  1158.         It is written in Smalltalk and lives in the Smalltalk 
  1159.         programming environment.  T-gen supports the generation 
  1160.         of both top-down (LL) and bottom-up (LR) parsers, which 
  1161.         will automatically generate derivation trees, abstract 
  1162.         syntax trees, or arbitrary Smalltalk objects.  The simple 
  1163.         specification syntax and graphical user interface are 
  1164.         intended to enhance the learning, comprehension, and 
  1165.         usefulness of T-gen.
  1166. ports:        ParcPlace Objectworks/Smalltalk 4.0 & 4.1
  1167. requires:    Smalltalk-80
  1168. updated:    1992/10/18
  1169.  
  1170. language:    BNF 
  1171. package:    Eli Compiler Construction System
  1172. version:    3.4.2
  1173. parts:        ?????, translator(WEB->BNF?)
  1174. how to get:    ftp pub/cs/distribs/eli/* from ftp.cs.colorado.edu
  1175. ports:        Sun-3/SunOS4.1 Sun-4/SunOS4.1.2 RS/6000/AIX3 Mips/Ultrix4.2
  1176.         HP9000/300/HP-UX8.00 HP9000/700/HP-UX8.07
  1177. description:    Eli integrates off-the-shelf tools and libraries with
  1178.         specialized language processors to generate complete compilers
  1179.         quickly and reliably.  It simplifies the development of new
  1180.         special-purpose languages, implementation of existing languages
  1181.         on new hardware and extension of the constructs and features of
  1182.         existing languages.
  1183. discussion:    <eli-request@cs.colorado.edu>
  1184. contact:    <compiler@cs.colorado.edu>, <compiler@uni-paderborn.de>
  1185. updated:    1993/02/11
  1186.  
  1187. language:    Milarepa 
  1188. package:    Milarepa Perl/BNF Parser 
  1189. version:    Prototype 1.0
  1190. parts:        parser-generator, examples, tutorial
  1191. author:        Jeffrey Kegler <jeffrey@jeffrey@netcom.com>
  1192. description:    Milarepa takes a source grammar in the Milarepa language (a
  1193.         straightforward mix of BNF and Perl) and generates a Perl file,
  1194.         which, when enclosed in a simple wrapper, parses some third
  1195.         language described by the source grammar.
  1196.         This is intended to be a real hacker's parser.  It is not
  1197.         restricted to LR(k), and the parse logic follows directly from
  1198.         the BNF.  It handles ambiguous grammars, ambiguous tokens
  1199.         (tokens which were not positively identified by the lexer) and
  1200.         allows the programmer to change the start symbol.  The grammar
  1201.         may not be left recursive.  The input must be divided into
  1202.         sentences of a finite maximum length.  There is no fixed
  1203.         distinction between terminals and non-terminals, that is, a
  1204.         symbol can both match the input AND be on the left hand side of
  1205.         a production.  Multiple Marpa grammars are allowed in a single
  1206.         perl program.
  1207.         It's only a prototype primarily due to poor speed.  This is
  1208.         intended to be remedied after Perl 5.0 is out.
  1209. requires:    perl
  1210. updated:    1993/03/17
  1211.  
  1212. language:    BNF (yacc)
  1213. package:    NewYacc
  1214. version:    1.0
  1215. parts:        parser generator, documenation
  1216. how to get:    ftp src/newyacc.1.0.*.Z from flubber.cs.umd.edu
  1217. author:        Jack Callahan <callahan@mimsy.cs.umd.edu> 
  1218. description:     [someone want to fill it in? --muir]
  1219. reference:    see Dec 89 CACM for a brief overview of NewYacc.
  1220. updated:    1992/02/10
  1221.  
  1222. language:    BNF (yacc)
  1223. package:    bison
  1224. version:    1.18
  1225. parts:        parser generator, documentation
  1226. author:        Robert Corbett ?
  1227. how to get:    ftp bison-1.16.tar.Z from a GNU archive site
  1228. bugs:        bug-gnu-utils@prep.ai.mit.edu
  1229. ports:        unix, atari, ?
  1230. restriction:    !! will apply the GNU General Public License to *your* code !!
  1231. updated:    1992/01/28
  1232.  
  1233. language:    BNF (yacc)
  1234. package:    ? jaccl ?
  1235. version:    ?
  1236. parts:        parser generator
  1237. author:        Dave Jones <djones@megatest.uucp>
  1238. description:    a LR(1) parser generator
  1239. how to get:    ?
  1240. updated:    1989/09/08
  1241.  
  1242. language:    BNF (yacc)
  1243. package:    byacc (Berkeley Yacc)
  1244. version:    1.9
  1245. parts:        parser generator
  1246. author:        Robert Corbett <Robert.Corbett@eng.sun.com>
  1247. how to get:    To be determined.  Probably ftp from a Berkeley system.
  1248. description:    ?
  1249. history:    Used to be called Zoo, and before that, Zeus
  1250. updated:    1993/02/22
  1251.  
  1252. language:    BNF (yacc)
  1253. package:    aflex-ayacc
  1254. version:    1.2a
  1255. parts:        parser generator (Ada), scanner generator (Ada)
  1256. author:        IRUS (Irvine Research Unit in Software)
  1257. how to get:    ftp pub/irus/aflex-ayacc_1.2a.tar.Z from liege.ics.uci.edu
  1258. description:    Lex and Yacc equivalents that produce Ada output
  1259. announcements:    irus-software-request@ics.uci.edu
  1260. contact:    irus-software-request@ics.uci.edu
  1261. updated:    1993/01/06
  1262.  
  1263. language:    BURS ?
  1264. package:    Iburg
  1265. version:    ?
  1266. parts:        parser generator?
  1267. author:        Christopher W. Fraser <cwf@research.att.com>, David R. Hanson
  1268.         <drh@princeton.edu>, Todd A. Proebsting <todd@cs.arizona.edu>
  1269. how to get:    ftp pub/iburg.tar.Z from ftp.cs.princeton.edu
  1270. description:    Iburg is a program that generates a fast tree parser.  It is
  1271.         compatible with Burg. Both programs accept a cost-augmented
  1272.         tree grammar and emit a C program that discovers an optimal
  1273.         parse of trees in the language described by the grammar. They
  1274.         have been used to construct fast optimal instruction selectors
  1275.         for use in code generation.  Burg uses BURS; Iburg's matchers
  1276.         do dynamic programming at compile time.
  1277. updated:    1993/02/10
  1278.  
  1279. language:    C, C++, Objective-C, RTL
  1280. package:    GNU CC (gcc)
  1281. version:    2.3.3
  1282. parts:        compiler, runtime, libraries, examples, documentation
  1283. author:        Richard Stallman <rms@gnu.ai.mit.edu> and others
  1284. how to get:    ftp gcc-2.3.3.tar.Z from a GNU archive site
  1285. description:    A very high quality, very portable compiler for C, C++,
  1286.         Objective-C.  The compiler is designed to support multiple
  1287.         front-ends and multiple back-ends by translating first
  1288.         into RTL (Register Transfer Language) and from there into
  1289.         assembly for the target architecture.   Front ends for
  1290.         Ada, Pascal, and Fortran are all under development.
  1291. conformance:    C: superset of K&R C and ANSI C.
  1292.         C++: not exactly cfront 3.0? [could someone tell me which
  1293.         version of cfront it is equivalent to, if any?  --muir]
  1294.         Objective-C: ?
  1295. portability:    very high in the theory, somewhat annoying in practice
  1296. ports:        3b1, a29k, aix385, alpha, altos3068, amix, arm, convex,
  1297.         crds, elxsi, fx2800, fx80, genix, hp320,
  1298.         i386-{dos,isc,sco,sysv.3,sysv.4,mach,bsd,linix}, iris,
  1299.         i860, i960, irix4, m68k, m88ksvsv.3, mips-news,
  1300.         mot3300, next, ns32k, nws3250-v.4, hp-pa, pc532,
  1301.         plexus, pyramid, romp, rs6000, sparc-sunos,
  1302.         sparc-solaris2, sparc-sysv.4, spur, sun386, tahoe, tow,
  1303.         umpis, vax-vms, vax-bsd, we32k
  1304. status:        actively developed
  1305. restriction:    Copyleft
  1306. bugs:        gnu.gcc.bug
  1307. discussion:    gnu.gcc.help
  1308. announcements:    gnu.gcc.announce
  1309. updated:    1992/12/26
  1310.  
  1311. language:    C
  1312. package:    GNU superoptimizer
  1313. version:    2.2
  1314. author:        Torbjorn Granlund <tege@gnu.ai.mit.edu> with Tom Wood
  1315. parts:        exhaustive instruction sequence optimizer
  1316. how to get:    ftp superopt-2.2.tar.Z from a GNU archive site
  1317. description:    GSO is a function sequence generator that uses an exhaustive
  1318.         generate-and-test approach to find the shortest instruction
  1319.         sequence for a given function.  You have to tell the
  1320.         superoptimizer which function and which CPU you want to get
  1321.         code for.
  1322.         This is useful for compiler writers.
  1323. restriction:    Copyleft
  1324. ports:        Alpha, Sparc, i386, 88k, RS/6000, 68k, 29k, Pyramid(SP,AP,XP)
  1325. bugs:        Torbjorn Granlund <tege@gnu.ai.mit.edu>
  1326. updated:    1993/02/16
  1327.  
  1328. language:    C
  1329. package:    xdbx
  1330. version:    2.1
  1331. parts:        X11 front end for dbx
  1332. how to get:    retrieve xxgdb from comp.sources.x volumes 11, 12, 13, 14, & 16
  1333. contact:    Po Cheung <cheung@sw.mcc.com>
  1334. updated:    1992/02/22
  1335.  
  1336. language:    C
  1337. package:    ups
  1338. version:    2.1
  1339. parts:        interpreter, symbolic debugger, tests, documentation
  1340. how to get:    ? ftp from contrib/ups*.tar.Z from export.lcs.mit.edu ?
  1341.     unofficial: unofficial enhancements by Rod Armstrong <rod@sj.ate.slb.com>,
  1342.         available by ftp misc/unix/ups/contrib/rob from sj.ate.slb.com
  1343. author:        Mark Russell <mtr@ukc.ac.uk>
  1344. description:    Ups is a source level C debugger that runs under X11 or 
  1345.         SunView.  Ups includes a C interpreter which allows you to add 
  1346.         fragments of code simply by editing them into the source window
  1347. ports:        Sun, Decstation, VAX(ultrix), HLH Clipper
  1348. discussion:    ups-users-request@ukc.ac.uk
  1349. bugs:        Mark Russell <mtr@ukc.ac.uk>
  1350. updated:    1991/05/20
  1351.  
  1352. language:    C (ANSI)
  1353. package:    lcc
  1354. version:    1.8
  1355. parts:        compiler, test suite, documentation
  1356. author:        Dave Hanson <drh@cs.princeton.edu>
  1357. how to get:    ftp pub/lcc/lccfe-*.tar.Z from princeton.edu
  1358. description:    + hand coded C parser (faster than yacc)
  1359.         + retargetable
  1360.         + code "as good as GCC"
  1361. ports:        vax (mips, sparc, 68k backends are commercial)
  1362. status:        small-scale production use using commerical backends; the
  1363.         commercial backends are cheap (free?) to universities.
  1364. discussion:    lcc-requests@princeton.edu
  1365. updated:    1992/02/20
  1366.  
  1367. language:    C
  1368. package:    GCT
  1369. version:    1.4
  1370. parts:        test-coverage-preprocessor
  1371. author:        Brian Marick <marick@cs.uiuc.edu>
  1372. how to get:    ftp pub/testing/gct.file/ftp.* from cs.uiuc.edu
  1373. description:    GCT is test-coverage tool based on GNU C.  Coverage tools 
  1374.         measure how thoroughly a test suite exercises a program.
  1375. restriction:    CopyLeft
  1376. discussion:    Gct-Request@cs.uiuc.edu
  1377. support:    commercial support available from author, (217) 351-7228
  1378. ports:        sun3, sun4, rs/6000, 68k, 88k, hp-pa, ibm 3090,
  1379.         ultrix, convex, sco
  1380. updated:    1993/02/12
  1381.  
  1382. langauge:    C
  1383. package:    MasPar mpl, ampl
  1384. version:    3.1
  1385. parts:        compiler
  1386. how to get:    ftp put/mpl-* from maspar.maspar.com
  1387. description:    mpl & ampl - the intrinsic parallel languages for MasPar's
  1388.         machines are C (ampl is actually a gcc port these days). You
  1389.         can get the source from marpar.com.
  1390. contact:    ?
  1391. updated:    ?
  1392.  
  1393. language:    C
  1394. package:    dsp56k-gcc
  1395. version:    ?
  1396. parts:        compiler
  1397. how to get:    ftp pub/ham/dsp/dsp56k-tools/dsp56k-gcc.tar.Z from nic.funet.fi
  1398.     au:        ftp pub/micros/56k/g56k.tar.Z from evans.ee.adfa.oz.au
  1399. description:    A port of gcc 1.37.1 to the Motorola DSP56000 done by 
  1400.         Motorola
  1401. contact:    ?
  1402. updated:    ?
  1403.  
  1404. language:    C
  1405. package:    dsp56165-gcc
  1406. version:    ?
  1407. parts:        compiler
  1408. author:        Andrew Sterian <asterian@eecs.umich.edu>
  1409. how to get:    ftp usenet/alt.sources/? from wuarchive.wustl.edu    
  1410. description:    A port of gcc 1.40 to the Motorola DSP56156 and DSP56000.
  1411. updated:    ?
  1412.  
  1413. language:    C
  1414. package:    Harvest C
  1415. version:    2.1
  1416. how to get:    ftp mac/development/languages/harves* from archive.umich.edu
  1417. description:    ?
  1418. ports:        Macintosh
  1419. contact:    Eric W. Sink
  1420. updated:    1992/05/26
  1421.  
  1422. language:    C, C++
  1423. package:    Xcoral
  1424. version:    1.72
  1425. parts:        editor
  1426. how to get:    ftp ? from ftp.inria.fr
  1427. description:    Xcoral is a multiwindows mouse-based text editor, for X Window
  1428.         System, with a built-in browser to navigate through C functions
  1429.         and C++ classes hierarchies...  Xcoral provides variables width
  1430.         fonts, menus, scrollbars, buttons, search, regions,
  1431.         kill-buffers and 3D look.  Commands are accessible from menus
  1432.         or standard key bindings. Xcoral is a direct Xlib client and
  1433.         run on color/bw X Display.
  1434. contact:    ?
  1435. updated:    1993/03/14
  1436.  
  1437. language:    C++
  1438. package:    aard ???
  1439. version:    ?
  1440. parts:        memory use tracer
  1441. how to get:    ftp pub/aard.tar.Z from wilma.cs.brown.edu
  1442. description:    We have a prototype implementation of a tool to do memory
  1443.         checking.  It works by keeping track of the typestate of each
  1444.         byte of memory in the heap and the stack.  The typestate can be
  1445.         one of Undefined, Uninitialized, Free or Set.  The program can
  1446.         detect invalid transitions (i.e. attempting to set or use
  1447.         undefined or free storage or attempting to access uninitialized
  1448.         storage).  In addition, the program keeps track of heap
  1449.         management through malloc and free and at the end of the run
  1450.         will report all memory blocks that were not freed and that are
  1451.         not accessible (i.e.  memory leaks).
  1452.         The tools works using a spliced-in shared library.
  1453. contact:    Steve Reiss <spr@cs.brown.edu>
  1454. requires:    Sparc, C++ 3.0.1, SunOS 4.X
  1455.  
  1456. language:    C++
  1457. package:    ET++
  1458. version:    3.0-alpha
  1459. parts:        class libraries, documentation
  1460. how to get:    ftp C++/ET++/* from iamsun.unibe.ch
  1461. contact:    Erich Gamma <gamma@ifi.unizh.ch>
  1462. updated:    1992/10/26
  1463.  
  1464. language:    C++
  1465. package:    C++ grammar
  1466. how to get:    comp.sources.misc volume 25
  1467. description:    [is this a copy of the Roskind grammer or something else?
  1468.         --muir]
  1469. parts:        parser(yacc)
  1470. updated:    1991/10/23
  1471.  
  1472. language:    C++
  1473. package:    COOL
  1474. version:    ?
  1475. parts:        libraries, tests, documentation
  1476. how to get:    ftp ? from cs.utexas.edu
  1477. description:    A C++ class library developed at Texas Instruments.  Cool
  1478.         contains a set of containers like Vectors, List, Has_Table,
  1479.         etc.  It uses a shallow hierarchy with no common base 
  1480.         class.    The funtionality is close to Common Lisp data
  1481.         structures (like libg++).  The template syntax is very close
  1482.         to Cfront3.x and g++2.x.  Can build shared libraries on Suns.
  1483. ports:        ?
  1484. contact:    Van-Duc Nguyen <nguyen@crd.ge.com>
  1485. updated:    1992/08/05
  1486.  
  1487. language:    C++, Extended C++
  1488. package:    EC++
  1489. version:    ?
  1490. parts:        translator(C++), documentation
  1491. author:        Glauco Masotti <masotti@lipari.usc.edu>
  1492. how to get:    ? ftp languages/c++/EC++.tar.Z from ftp.uu.net ?
  1493. description:    EC++ is a preprocessor that translates Extended C++
  1494.         into C++.  The extensions include:
  1495.         + preconditions, postconditions, and class invariants
  1496.         + parameterized classes
  1497.         + exception handling 
  1498.         + garbage collection
  1499. status:        ?
  1500. updated:    1989/10/10
  1501.  
  1502. language:    C++
  1503. package:    LEDA
  1504. version:    3.0
  1505. parts:        libraries
  1506. how to get:    ftp pub/LEDA/* from ftp.cs.uni-sb.de
  1507. description:    library of efficient data types and algorithms.
  1508.         New with 3.0: both template and non-template versions.
  1509. contact:    Stefan N"aher <stefan@mpi-sb.mpg.de>
  1510. updated:    1992/11/30
  1511.  
  1512. language:    E (a persistent C++ variant)
  1513. package:    GNU E
  1514. version:    2.3.3
  1515. parts:        compiler
  1516. how to get:    ftp exodus/E/gnu_E* from ftp.cs.wisc.edu
  1517. description:    GNU E is a persistent, object oriented programming language
  1518.         developed as part of the Exodus project.  GNU E extends C++
  1519.         with the notion of persistent data, program level data objects
  1520.         that can be transparently used across multiple executions of a
  1521.         program, or multiple programs, without explicit input and
  1522.         output operations.
  1523.         GNU E's form of persistence is based on extensions to the C++
  1524.         type system to distinguish potentially persistent data objects
  1525.         from objects that are always memory resident.  An object is
  1526.         made persistent either by its declaration (via a new
  1527.         "persistent" storage class qualifier) or by its method of
  1528.         allocation (via persistent dynamic allocation using a special
  1529.         overloading of the new operator).  The underlying object
  1530.         storage system is the Exodus storage manager, which provides
  1531.         concurrency control and recovery in addition to storage for
  1532.         persistent data.
  1533. restriction:    Copyleft; not all runtime sources are available (yet)
  1534. requires:    release 2.1.1 of the Exodus storage manager
  1535. contact:    exodus@cs.wisc.edu
  1536. updated:    1993/01/20
  1537.  
  1538. language:    C (ANSI)
  1539. package:    ? 1984 ANSI C to K&R C preprocessor ?
  1540. version:    ?
  1541. parts:        translator(K&R C)
  1542. author:        ?
  1543. how to get:    from comp.sources.unix archive volume 1
  1544. status:        ?
  1545. updated:    ?
  1546.  
  1547. language:    C (ANSI)
  1548. package:    unproto ?
  1549. version:    ? 4 ? 1.6 ?
  1550. parts:        translator(K&R C)
  1551. author:        Wietse Venema <wietse@wzv.win.tue.nl>
  1552. how to get:    ftp pub/unix/unproto4.shar.Z from ftp.win.tue.nl
  1553. contact:    ?
  1554. updated:    ?
  1555.  
  1556. language:    C (ANSI)
  1557. package:    cproto
  1558. version:    ?
  1559. parts:        translator(K&R C)
  1560. author:        Chin Huang <chin.huang@canrem.com>
  1561. how to get:    from comp.sources.misc archive volume 29
  1562. description:    cproto generates function prototypes from function definitions.
  1563.         It can also translate function definition heads between K&R
  1564.         style and ANSI C style.
  1565. ports:        UNIX, MS-DOS
  1566. updated:    1992/07/18
  1567.  
  1568. langauge:    C (ANSI)
  1569. package:    cextract
  1570. version:    1.7
  1571. parts:        translator(K&R C), header file generator
  1572. how to get:    ftp from any comp.sources.reviewed archive
  1573. author:        Adam Bryant <adb@cs.bu.edu>
  1574. description:    A C prototype extractor, it is ideal for generating
  1575.         header files for large multi-file C programs, and will
  1576.         provide an automated method for generating all of the
  1577.         prototypes for all of the functions in such a program.
  1578.         It may also function as a rudimentary documentation
  1579.         extractor, generating a sorted list of all functions
  1580.         and their locations
  1581. ports:        Unix, VMS
  1582. updated:    1992/11/03
  1583.  
  1584. language:    C, ANSI C, C++
  1585. package:    ? The Roskind grammars ?
  1586. version:    ? 2.0 ?
  1587. parts:        parser(yacc), documenation
  1588. author:        Jim Roskind <jar@hq.ileaf.com>
  1589. how to get:    ftp pub/*grammar* from ics.uci.edu
  1590. description:    The C grammar is CLEAN, it does not use %prec, %assoc, and
  1591.         has only one shift-reduce conflict.  The C++ grammar has
  1592.         a few conflicts.
  1593. status:        ?
  1594. updated:    1989/12/26
  1595.  
  1596. language:    C, C++
  1597. package:    xxgdb
  1598. version:    1.06
  1599. parts:        X11 front end for gdb
  1600. how to get:    retrieve xxgdb from comp.sources.x volumes 11, 12, 13, 14, & 16
  1601. contact:    Pierre Willard <pierre@la.tce.com>
  1602. updated:    1992/02/22
  1603.  
  1604. language:    C, C++
  1605. package:    gdb
  1606. version:    4.8
  1607. parts:        symbolic debugger, documentation
  1608. how to get:    ftp gdb-*.tar.[zZ] from a GNU archive site
  1609. author:        many, but most recently Stu Grossman <grossman@cygnus.com> 
  1610.         and John Gilmore <gnu@cygnus.com> of Cygnus Support
  1611. ports:        most unix variants, vms, vxworks, amiga, msdos
  1612. bugs:        <bug-gdb@prep.ai.mit.edu>
  1613. restriction:    CopyLeft
  1614. updated:    1993/02/19
  1615.  
  1616. language:    Duel (a <practical> C debugging language)
  1617. package:    DUEL
  1618. version:    1.10
  1619. parts:        front end
  1620. author:        Michael Golan <mg@cs.princeton.edu>
  1621. how to get:    ftp duel/* from ftp.cs.princeton.edu
  1622. description:    DUEL is a front end to gdb.  It implements a language
  1623.         designed for debbuging C programs.  It maily features 
  1624.         efficient ways to select and display data items.
  1625. requires:    gdb
  1626. status:        author is pushing the system hard.
  1627. updated:    1993/03/15
  1628.  
  1629. language:    C, C++, Objective C
  1630. package:    emx programming environment for OS/2
  1631. version:    0.8f
  1632. parts:        gcc, g++, gdb, libg++, .obj linkage, DLL, headers
  1633. how to get:    ftp pub/os2/2.0/programming/emx-0.8f from ftp-os2.nmsu.edu
  1634.     europe:    ftp soft/os2/emx-0.8f from rusmv1.rus.uni-stuttgart.de
  1635. author:        Ebenhard Mattes <mattes@azu.informatik.uni-stuttgart.de>
  1636. discussion:    subscribe to emxlist using listserv@ludd.luth.se
  1637. updated:    1992/09/21
  1638.  
  1639. language:    C
  1640. package:    PART's C Pthreads
  1641. version:    ?
  1642. parts:        library
  1643. author:        PART (POSIX / Ada-Runtime Project)
  1644. how to get:    ftp pub/PART/pthreads* from ftp.cs.fsu.edu
  1645. description:    As part of the PART project we have been designing and
  1646.         implementing a library package of preemptive threads which is
  1647.         compliant with POSIX 1003.4a Draft 6. A description of the
  1648.         interface for our Pthreads library is now available on ftp. Our
  1649.         implementation is limited to the Sun SPARC architecture and
  1650.         SunOS 4.1.x. We do not make any use of Sun's light-weight
  1651.         processes to achieve better performance (with one I/O-related
  1652.         exception).
  1653. restriction:    GNU Library General Public License
  1654. discussion:    send "Subject: subscribe-pthreads" to mueller@uzu.cs.fsu.edu
  1655. contact:    pthreads-bugs@ada.cs.fsu.edu
  1656. updated:    1993/03/05
  1657.  
  1658. language:    C, nroff
  1659. package:    c2man
  1660. version:    1.10
  1661. parts:        documentation generator (C -> nroff -man)
  1662. how to get:    alt.sources archive
  1663. author:        Graham Stoney <greyham@research.canon.oz.au>
  1664. description:    c2man is a program for generating Unix style manual pages in 
  1665.         nroff -man format directly from ordinary comments embedded 
  1666.         in C source code
  1667. updated:    1992/11/20
  1668.  
  1669. language:    Small-C
  1670. package:    smallc
  1671. version:    ?
  1672. parts:        compiler
  1673. author:        ?
  1674. how to get:    ?, comp.sources.unix volume 5
  1675. description:    Small-C is a subset of the C programming language for which a
  1676.         number of public-domain compilers have been written.  The
  1677.         original compiler was written by Ron Cain and appeared in the
  1678.         May 1980 issue of Dr.Dobb's Journal.  More recently, James
  1679.         E.Hendrix has improved and extended the original Small-C
  1680.         compiler and published "The Small-C Handbook", ISBN
  1681.         0-8359-7012-4 (1984).  Both compilers produce 8080 assembly
  1682.         language, which is the most popular implementation of Small-C
  1683.         to-date.  My 6502 Small-C compiler for the BBC Micro is based
  1684.         on "RatC", a version of the original Ron Cain compiler
  1685.         described by R.E.Berry and B.A.Meekings in "A Book on C", ISBN
  1686.         0-333-36821-5 (1984).  The 6502 compiler is written in Small-C
  1687.         and was bootstrapped using Zorland C on an Amstrad PC1512 under
  1688.         MSDOS 3.2, then transferred onto a BBC Micro using Kermit.  The
  1689.         compiler can be used to cross-compile 6502 code from an MSDOS
  1690.         host, or as a 'resident' Small-C compiler on a BBC Micro.
  1691. conformance:    subset of C
  1692. ports:        68k, 6809, VAX, 8080, BBC Micro, Z80
  1693. updated:    1989/01/05
  1694.  
  1695. language:    C-Refine, C++-Refine, *-Refine
  1696. package:    crefine
  1697. version:    3.0
  1698. parts:        pre-processor, documentation
  1699. how to get:    aquire from any comp.sources.reviewed archive
  1700. author:        Lutz Prechelt <prechelt@ira.uka.de>
  1701. description:    C-Refine is a preprocessor for C and languages that
  1702.         vaguely resemble C's syntax.  It allows symbolic naming
  1703.         of code fragments so as to redistribute complexity and
  1704.         provide running commentary.
  1705. portability:    high
  1706. ports:        unix, msdos, atari, amiga.
  1707. updated:    1992/07/16
  1708.  
  1709. language:    CAML (Categorical Abstract Machine Language)
  1710. package:    CAML
  1711. version:    3.1
  1712. parts:        ?
  1713. author:        ?
  1714. description:    CAML is a language belonging to the ML family including:
  1715.         + lexical binding discipline
  1716.         + static type inference
  1717.         + user-defined (sum and product) types
  1718.         + possibly lazy data structures
  1719.         + possibly mutable data structures
  1720.         + interface with the Yacc parser generator
  1721.         + pretty-printing tools
  1722.         + and a complete library.
  1723. how to get:    ? ftp lang/caml from nuri.inria.fr ?
  1724. status:        ?
  1725. discussion:    ?
  1726. ports:        Sun-3 Sun-4 Sony-68k Sony-R3000 Decstation Mac-A/UX Apollo
  1727. portability:    ?
  1728. bugs:        weis@margaux.inria.fr or caml@margaux.inria.fr
  1729. updated:    ?
  1730.  
  1731. language:    Caml Light
  1732. package:    Caml Light
  1733. version:    0.4
  1734. how to get:    ftp lang/caml-light/* from nuri.inria.fr
  1735. author:        Xavier Leroy <xleroy@margaux.inria.fr>
  1736. parts:        bytecode compiler, runtime, scanner generator, parser generator
  1737. ports:        most unix, Macintosh, Amiga, MSDOS
  1738. conformance:    subset of CAML
  1739. features:    very small
  1740. performance:    five to ten times slower than SML-NJ
  1741. portability:    very high
  1742. contact:    Xavier Leroy <xleroy@margaux.inria.fr>
  1743. updated:    1991/10/05
  1744.  
  1745. language:    Candle, IDL (Interface Description Language)
  1746. package:    Scorpion System
  1747. version:    5.0
  1748. author:        University of Arizona
  1749. parts:        software development environment for developing
  1750.         software development environments, documentation
  1751. how to get:    ftp scorpion/* from cs.arizona.edu
  1752. description:    20 tools that can be used to construct specialized
  1753.         programming environments
  1754. history:    The Scorpion  Project  was  started  by     Prof.    Richard
  1755.         Snodgrass as an outgrowth of the SoftLab Project (which pro-
  1756.         duced the IDL Toolkit) that he started when he    was  at     the
  1757.         University  of    North  Carolina.   The    Scorpion  Project is
  1758.         directed by him at the University of Arizona  and  by  Karen
  1759.         Shannon at the University of North Carolina at Chapel Hill.
  1760. reference:    "The Interface Description Language: Definition and Use," 
  1761.         by Richard Snodgrass, Computer Science Press, 1989,
  1762.         ISBN 0-7167-8198-0
  1763. ports:        Sun-3, Sun-4, Vax, Decstation, NeXT, Sequent, HP9000
  1764. discussion:    info-scorpion-request@cs.arizona.edu
  1765. contact:    scorpion-project@cs.arizona.edu
  1766. updated:    1991/04/10
  1767.  
  1768. language:    CASE-DSP (Computer Aided Software Eng. for Digital Signal Proc)
  1769. package:    Ptolemy
  1770. version:    ?
  1771. parts:        grahpical algorithm layout, code generator, simulator
  1772. how to get:    ftp pub/? from ptolemy.bekeley.edu
  1773. description:    Ptolemy provides a highly flexible foundation for the
  1774.         specification, simulation, and rapid prototyping of systems.
  1775.         It is an object oriented framework within which diverse models
  1776.         of computation can co-exist and interact.  For example, using
  1777.         Ptolemy a data-flow system can be easily connected to a
  1778.         hardware simulator which in turn may be connected to a
  1779.         discrete-event system, etc.  Because of this, Ptolemy can be
  1780.         used to model entire systems.
  1781.         In addition, Ptolemy now has code generation capabilities.
  1782.         From a flow graph description, Ptolemy can generate both C code
  1783.         and DSP assembly code for rapid prototyping.  Note that code
  1784.         generation is not yet complete, and is included in the current
  1785.         release for demonstration purposes only.
  1786. ports:        Sun-4, MIPS/Ultrix; DSP56001, DSP96002, and SPROC.
  1787. contact:    ptolemy@ohm.berkeley.edu
  1788. updated:    ?
  1789.  
  1790. language:    Common Lisp
  1791. package:    CMU Common Lisp
  1792. version:    16f
  1793. parts:        incremental compiler, profiler, runtime, documentation, 
  1794.         editor, debugger
  1795. how to get:    ftp /afs/cs.cmu.edu/project/clisp/release/16f-source.tar.Z 
  1796.         from ftp.cs.cmu.edu.  Precompiled versions also available 
  1797. description:    includes *macs-like editor (hemlock), pcl, and clx.
  1798. conformance:    mostly X3J13 compatible.
  1799. ports:        Sparc/Mach Sparc/SunOS Mips/Mach IBMRT/Mach
  1800. contact:    slisp@cs.cmu.edu
  1801. updated:    1992/12/17
  1802.  
  1803. language:    Common Lisp
  1804. package:    PCL (Portable Common Loops)
  1805. version:    8/28/92 PCL
  1806. parts:        library
  1807. author:        ? Richard Harris <rharris@ptolemy2.rdrc.rpi.edu> ?
  1808. how to get:    ftp pcl/* from parcftp.xerox.com
  1809. description:    A portable CLOS implementation.     CLOS is the object oriented 
  1810.         programming standard for Common Lisp.  Based on Symbolics 
  1811.         FLAVORS and Xerox LOOPS, among others.    Loops stands for
  1812.         Lisp Object Oriented Programming System.
  1813. status:        ?
  1814. ports:        Lucid CL 4.0.1, CMUCL 16e, ?
  1815. updated:    1992/09/02
  1816.  
  1817. language:    Common Lisp
  1818. package:    WCL
  1819. version:    2.14
  1820. parts:        ?, shared library runtime, source debugger
  1821. author:        Wade Hennessey <wade@leland.Stanford.EDU>
  1822. how to get:    ftp pub/wcl/* from sunrise.stanford.edu
  1823. description:    A common lisp implementation as a shared library.  WCL
  1824.         Is not a 100% complete Common Lisp, but it does have
  1825.         the full development environment including dynamic file
  1826.         loading and debugging.    A modified version of GDB provides
  1827.         mixed-language debugging.  A paper describing WCL was
  1828.         published in the proceedings of the 1992 Lisp and Functional
  1829.         Programming Conference. 
  1830. requires:    GNU C 2.1 (not 2.2.2)
  1831. ports:        Sparc/SunOS
  1832. contact:    <wcl@sunrise.stanford.edu>
  1833. discussion:    <wcl-request@sunrise.stanford.edu>
  1834. updated:    1992/10/28
  1835.  
  1836. language:    Common Lisp
  1837. package:    KCL (Kyoto Common Lisp)
  1838. parts:        translator(C), interpreter
  1839. how to get:    ? ftp pub/kcl*.tar.Z from rascal.ics.utexas.edu ?
  1840. author:        T. Yuasa <yuasa@tutics.tut.ac.jp>, M. Hagiya 
  1841.         <hagiya@is.s.u-tokyo.ac.jp> 
  1842. description:    KCL, Kyoto Common Lisp, is an implementation of Lisp,
  1843.         It is written in the language C to run under Un*x-like 
  1844.         operating systems.  KCL is very C-oriented; for example, 
  1845.         the compilation of Lisp functions in KCL involves a 
  1846.         subsidiary C compilation.
  1847. conformance:    conforms to the book ``Common Lisp: The Language,''
  1848.         G. Steele, et al., Digital Press, 1984.     
  1849. restriction:    must sign license agreement
  1850. discussion:    kcl-request@cli.com
  1851. bugs:        kcl@cli.com
  1852. updated:    1987/06
  1853.  
  1854. language:    Common Lisp
  1855. package:    AKCL (Austin Kyoto Common Lisp)
  1856. version:    1-615
  1857. parts:        improvements
  1858. author:        Bill Schelter <wfs@cli.com>
  1859. how to get:    ftp pub/akcl-*.tar.Z from rascal.ics.utexas.edu
  1860. author:        Bill Schelter <wfs@rascal.ics.utexas.edu>
  1861. description:    AKCL is a collection of ports, bug fixes, and
  1862.         performance improvements to KCL.
  1863. ports:        Decstation3100, HP9000/300, i386/sysV, IBM-PS2/aix, IBM-RT/aix
  1864.         SGI Sun-3/Sunos[34].* Sun-4 Sequent-Symmetry IBM370/aix,
  1865.         VAX/bsd VAX/ultrix NeXT
  1866. updated:    1992/04/29
  1867.  
  1868. language:    Common Lisp
  1869. package:    CLX 
  1870. version:    5.01
  1871. parts:        library
  1872. how to get:    ftp contrib/CLX.R5.01.tar.Z from export.lcs.mit.edu
  1873. description:    Common Lisp binding for X
  1874. contact:    ?
  1875. ports:        ?, CMU Common Lisp
  1876. bugs:        bug-clx@expo.lcs.mit.edu
  1877. updated:    1992/08/26
  1878.  
  1879. language:    Common Lisp
  1880. package:    CLISP
  1881. version:    ?
  1882. parts:        bytecode compiler, translator(->C), runtime, library, editor
  1883. author:        Bruno Haible <haible@ma2s2.mathematik.uni-karlsruhe.de>,
  1884.         Michael Stoll <michael@rhein.iam.uni-bonn.de>
  1885. how to get:    ftp pub/lisp/clisp from ma2s2.mathematik.uni-karlsruhe.de
  1886. description:    CLISP is a Common Lisp (CLtL1) implementation by Bruno Haible
  1887.         of Karlsruhe University and Michael Stoll of Munich University,
  1888.         both in Germany.  It needs only 1.5 MB of RAM.  German and
  1889.         English versions are available, French coming soon.  Packages
  1890.         running in CLISP include PCL and, on Unix machines, CLX.
  1891. conformance:    CLISP is mostly CLtL1 compliant.  It implements 99% of the 
  1892.         standard
  1893. ports:        Atari, Amiga, MS-DOS, OS/2, Linux, Sun4, Sun386i, HP90000/800
  1894.         and others
  1895. discussion:    send "subscribe clisp-list" to 
  1896.         listserv@ma2s2.mathematik.uni-karlsruhe.de
  1897. restriction:    GNU General Public License
  1898. updated:    1993/03/10
  1899.  
  1900. language:    Common Lisp
  1901. package:    Cartier's Contribs
  1902. version:    1.2
  1903. parts:        libraries, documentation
  1904. author:        Guillaume Cartier <cartier@math.uqam.ca>
  1905. how to get:    ftp pub/mcl2/contrib/Cartiers* from cambridge.apple.com
  1906. description:    libraries for MCL
  1907. requires:    Macintosh Common Lisp
  1908. updated:    1992/11/30
  1909.  
  1910. language:    Common Lisp
  1911. package:    QT-OBJECTS
  1912. version:    ?
  1913. author:        Michael Travers <mt@media.mit.edu> and others
  1914. parts:        library
  1915. description:    interface between MCL and QuickTime
  1916. requires:    Macintosh Common Lisp
  1917. updated:    1992/12/20
  1918.  
  1919. language:    Common Lisp
  1920. package:    Memoization ?
  1921. version:    ?
  1922. parts:        library
  1923. how to get:    ftp pub/Memoization from archive.cs.umbc.edu
  1924. author:        Marty Hall <hall@aplcenmp.apl.jhu.edu>
  1925. description:    Automatic memoization is a technique by which an existing 
  1926.         function can be transformed into one that "remembers" 
  1927.         previous arguments and their associated results
  1928. updated:    1992/11/30
  1929.  
  1930. language:    Common Lisp
  1931. package:    GINA (Generic Interactive Application) 
  1932. version:    2.2
  1933. parts:        language binding, class library, interface builder
  1934. how to get:    ftp /gmd/gina from ftp.gmd.de 
  1935.     usa:    ftp contrib/? from export.lcs.mit.edu
  1936. description:    GINA is an application framework based on Common Lisp and 
  1937.         OSF/Motif to simplify the construction of graphical 
  1938.         interactive applications. It consists of:
  1939.         + CLM, a language binding for OSF/Motif in Common Lisp.
  1940.         + the GINA application framework, a class library in CLOS
  1941.         + the GINA interface builder, an interactive tool implemented 
  1942.         with GINA to design Motif windows.
  1943. requires:    OSF/Motif 1.1 or better.  Common Lisp with CLX, CLOS, PCL and
  1944.         processes.
  1945. ports:        Franz Allegro, Lucid, CMU CL and Symbolics Genera
  1946. discussion:    gina-users-request@gmdzi.gmd.de
  1947. -- 
  1948. Send compilers articles to compilers@iecc.cambridge.ma.us or
  1949. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  1950.  
  1951.  
  1952. From compilers Thu Apr  1 07:00:38 EST 1993
  1953. Xref: iecc comp.compilers:4462 comp.lang.misc:9657 comp.sources.d:4722 comp.archives.admin:882 news.answers:6793
  1954. Newsgroups: comp.compilers,comp.lang.misc,comp.sources.d,comp.archives.admin,news.answers
  1955. Path: iecc!compilers-sender
  1956. From: David Muir Sharnoff <muir@idiom.berkeley.ca.us>
  1957. Subject: Catalog of compilers, interpreters, and other language tools [p2of3]
  1958. Message-ID: <free2-Apr-93@comp.compilers>
  1959. Followup-To: comp.archives.admin
  1960. Summary: montly posting of free language tools that include source code
  1961. Keywords: tools, FTP, administrivia
  1962. Sender: compilers-sender@iecc.cambridge.ma.us
  1963. Supersedes: <free2-Mar-93@comp.compilers>
  1964. Reply-To: muir@idiom.berkeley.ca.us
  1965. Organization: University of California, Berkeley
  1966. References: <free1-Apr-93@comp.compilers>
  1967. Date: Thu, 1 Apr 1993 12:00:32 GMT
  1968. Approved: compilers@iecc.cambridge.ma.us
  1969. Expires: Sat, 1 May 1993 23:59:00 GMT
  1970.  
  1971. Archive-name: free-compilers/part2
  1972. Last-modified: 1993/03/24
  1973. Version: 3.2
  1974.  
  1975.  
  1976. language:    Concurrent Clean
  1977. package:    The Concurrent Clean System
  1978. version:    0.8.1
  1979. parts:        development environment, documentation, compiler(byte-code), 
  1980.         compiler(native), interpreter(byte-code), examples
  1981. how to get:    ftp pub/Clean/* from ftp.cs.kun.nl 
  1982. author:        Research Institute for Declarative Systems, 
  1983.         University of Nijmegen
  1984. description:    The Concurrent Clean system is a programming
  1985.         environment for the functional language Concurrent
  1986.         Clean, developed at the University of Nijmegen, The
  1987.         Netherlands. The system is one of the fastest
  1988.         implementations of functional languages available at
  1989.         the moment. Its I/O libraries make it possible to do
  1990.         modern, yet purely functional I/O (including windows,
  1991.         menus, dialogs etc.) in Concurrent Clean. With the
  1992.         Concurrent Clean system it is possible to develop
  1993.         real-life applications in a purely functional
  1994.         language.
  1995.         * lazy and purely functional
  1996.         * strongly typed - based on Milner/Mycroft scheme
  1997.         * module structure
  1998.         * modern I/O
  1999.         * programmer-infulenced evaluation order by annotations
  2000. contact:    clean@cs.kun.nl
  2001. ports:        Sun-3, Sun-4, Macintosh
  2002. updated:    1992/11/07
  2003.  
  2004. language:    Dylan
  2005. pakcage:    Thomas
  2006. version:    ? first public release ?
  2007. parts:        translator(Scheme)
  2008. how to get:    ftp pub/DEC/Thomas from gatekeeper.pa.dec.com
  2009. author:        Matt Birkholz <Birkholz@crl.dec.com>, Jim Miller 
  2010.         <JMiller@crl.dec.com>, Ron Weiss <RWeiss@crl.dec.com>
  2011. description:    Thomas, a compiler written at Digital Equipment
  2012.         Corporation's Cambridge Research Laboratory compiles
  2013.         a language compatible with the language described
  2014.         in the book "Dylan(TM) an object-oriented dynamic
  2015.         language" by Apple Computer Eastern Research and
  2016.         Technology, April 1992.     It does not perform well.
  2017.         Thomas is NOT Dylan(TM).
  2018. ports:        MIT's CScheme, DEC's Scheme->C, Marc Feeley's Gambi, Mac, PC, 
  2019.         Vax, MIPS, Alpha, 680x0
  2020. requires:    Scheme
  2021. updated:    1992/09/11
  2022.  
  2023. language:    E
  2024. package:    Amiga E
  2025. version:    2.1b
  2026. parts:        compiler, assembler, linker, utilities
  2027. author:        Wouter van Oortmerssen <Wouter@mars.let.uva.nl>
  2028. how to get:    ftp amiga/dev/lang/AmigaE21b.lha from amiga.physik.unizh.ch
  2029. description:    An Amiga specific E compiler.  E is a powerful and flexible
  2030.         procedural programming language and Amiga E a very fast com-
  2031.         piler for it, with features such as compilation speed of
  2032.         20000 lines/minute on a 7 Mhz amiga, inline assembler and
  2033.         linker integrated into compiler, large set of integrated
  2034.         functions, module concept with 2.04 includes as modules,
  2035.         flexible type-system, quoted expressions, immediate and typed
  2036.         lists, low level polymorphism, exception handling and much,
  2037.         much more.  Written in Assembly and E.    
  2038. discussion:    comp.sys.amiga.programmer (sometimes)
  2039. ports:        Amiga
  2040. portability:    not portable at all
  2041. status:        actively developed
  2042. updated:    1993/03/01
  2043.  
  2044. language:    EDIF (Electronic Design Interchange Format)
  2045. package:    Berkeley EDIF200 
  2046. version:    7.6
  2047. parts:        translator-building toolkit
  2048. author:        Wendell C. Baker and Prof A. Richard Newton of the Electronics 
  2049.         Research Laboratory, Department of Electrical Engineering and 
  2050.         Computer Sciences at the University of California, Berkeley, CA
  2051. how to get:    ftp from pub/edif in ic.berkeley.edu
  2052. description:    ?
  2053. ports:        ?
  2054. restriction:    no-profit w/o permission
  2055. updated:    1990/07
  2056.  
  2057. language:    EDIF v 2 0 101
  2058. package:    University of Manchester EDIF v 2 0 101 Syntax Checker
  2059. how to get:    ftp pub/edif from edif.cs.man.ac.uk
  2060. description:    Parser/Syntax checker for EDIF v 2 0 101 written in ANSI-C
  2061.  
  2062. language:    Eiffel
  2063. package:    ?
  2064. version:    ?
  2065. parts:        source checker
  2066. author:        Olaf Langmack <langmack@inf.fu-berlin.de> and Burghardt Groeber
  2067. how to get:    ftp pub/heron/ep.tar.Z from ftp.fu-berlin.de
  2068. description:    A compiler front-end for Eiffel-3 is available. It has been
  2069.         generated automatically with the Karlsruhe toolbox for
  2070.         compiler construction according to the most recent public
  2071.         language definition. The parser derives an easy-to-use
  2072.         abstract syntax tree, supports elementary error recovery
  2073.         and provides a precise source code indication of errors. It
  2074.         performs a strict syntax check and analyses 4000 lines of
  2075.         source code per second on a Sun-SPARC workstation.
  2076. updated:    1992/12/14
  2077.  
  2078. language:    EuLisp
  2079. package:    Feel (Free and Eventually Eulisp)
  2080. version:    0.75
  2081. parts:        interpreter, documentation
  2082. how to get:    ftp pub/eulisp from ftp.bath.ac.uk
  2083. author:        Pete Broadbery <pab@maths.bath.ac.uk>
  2084. description:    + integrated object system
  2085.         + a module system
  2086.         + parallelism
  2087.         + interfaces to PVM library, tcp/ip sockets, futures, 
  2088.         Linda, and CSP.
  2089. ports:        most unix
  2090. portability:    high, but can use shared memory and threads if available
  2091. updated:    1992/09/14
  2092.  
  2093. language:    FMPL of Accardi
  2094. package:    FMPL interpreter
  2095. version:    1
  2096. parts:        interpreter, documentation
  2097. author:        Jon Blow <blojo@xcf.berkeley.edu>
  2098. how to get:    ftp src/local/fmpl/* from xcf.berkeley.edu
  2099. description:    FMPL is an experimental prototype-based object-oriented 
  2100.         programming language developed at the Experimental Computing
  2101.         Facility of the University of California, Berkeley.
  2102.         + lambda-calculus based constructs.
  2103.         + event-driven (mainly I/O events)
  2104. updated:    1992/06/02
  2105.  
  2106. language:    FORTH
  2107. package:    TILE Forth
  2108. version:    2.1
  2109. parts:        interpreter
  2110. author:        Mikael Patel <mip@sectra.se>
  2111. how to get:    ftp tile-forth-2.1.tar.Z from a GNU archive site
  2112. description:    Forth interpreter in C; many Forth libraries
  2113. conformance:    Forth83
  2114. restriction:    shareware/GPL
  2115. ports:        unix
  2116. updated:    1991/11/13
  2117.  
  2118. language:    FORTH
  2119. package:    cforth
  2120. version:    ?
  2121. parts:        interpreter
  2122. author:        ?
  2123. how to get:    comp.sources.unix archive volume 1
  2124. description:    ?
  2125. updated:    ?
  2126.  
  2127. language:    FORTH
  2128. package:    F68K
  2129. version:    ?
  2130. how to get:    ftp atari/Languages/f68k.* from archive.umich.edu
  2131. description:    a portable Forth system for Motorola 68k computers
  2132. ports:        Atari ST/TT, Amiga, Sinclair QL and OS9
  2133. portability:    very high for 68000 based systems
  2134. contact:    Joerg Plewe <joerg.plewe@mpi-dortmund.mpg.de>
  2135. updated:    1992/12/14
  2136.  
  2137. language:    Forth, Yerk
  2138. package:    Yerk
  2139. version:    3.62
  2140. parts:        ?
  2141. how to get:    ftp pub/Yerk/? from oddjob.uchicago.edu
  2142. description:    Yerk is an object oriented language based on a
  2143.         Forth Kernel with some major modifications.  It
  2144.         was originally known as Neon, developed and sold
  2145.         as a product by Kriya Systems from 1985 to 1989.
  2146.         Several of us at The University of Chicago have
  2147.         maintained Yerk since its demise as a product.
  2148.         Because of the possible trademark conflict that
  2149.         Kriya mentions, we picked the name Yerk, which is
  2150.         at least not an acronym for anything, but rather
  2151.         stands for Yerkes Observatory, part of the Department
  2152.         of Astronomy and Astrophysics at U of C.
  2153. author:        ?
  2154. updated:    ?
  2155.  
  2156. language:    Forth?
  2157. package:    Mops
  2158. version:    2.3
  2159. parts:        ?
  2160. how to get:    ftp pub/Yerk/? from oddjob.uchicago.edu
  2161. description:    ???
  2162. updated:    1993/03/22
  2163.  
  2164. language:    Fortran
  2165. package:    f2c
  2166. version:    ?
  2167. parts:        translator(C)
  2168. author:        ?
  2169. how to get:    ftp ft2/? from netlib@research.att.com
  2170. bugs:        dmg@research.att.com
  2171. updated:    ? 1991/02/16 ?
  2172.  
  2173. language:    Fortran
  2174. package:    Floppy
  2175. version:    ?
  2176. parts:        ?
  2177. how to get:    ffccc in comp.sources.misc archive volume 12
  2178. description:    ?
  2179. contact:    ?
  2180. updated:    1992/08/04
  2181.  
  2182. language:    Fortran
  2183. package:    Flow
  2184. version:    ?
  2185. parts:        ?
  2186. how to get:    comp.sources.misc archive volume 31
  2187. author:        Julian James Bunn <julian@vxcrna.cxern.ch>
  2188. descripton:    The Flow program is a companion to Floppy, it allows the user 
  2189.         to produce various reports on the structure of Fortran 
  2190.         77 code, such as flow diagrams and common block tables.
  2191. requires:    Floppy
  2192. ports:        VMS, Unix, CMS
  2193.  
  2194. language:    Fortran
  2195. package:    Adaptor (Automatic DAta Parallelism TranslatOR)
  2196. version:    ?
  2197. parts:        translator(Fortran), documentation
  2198. how to get:    ftp gmd/adaptor/* from ftp.gmd.de
  2199. description:    Adaptor is a tool that transforms data parallel
  2200.         programs written in Fortran with array extensions,
  2201.         parallel loops, and  layout directives    to parallel
  2202.         programs with explicit message passing.
  2203.         ADAPTOR is not a compiler but a source to source
  2204.         transformation that generates Fortran 77 host and
  2205.         node programs with message passing.  The new
  2206.         generated source codes have to be compiled by the
  2207.         compiler of the parallel machine. 
  2208. ports:        Alliant FX/2800, iPSC/860, Net of Sun-4 or RS/6000 
  2209.         Workstations (based on PVM), Parsytec GCel, Meiko Concerto
  2210. contact:    Thomas Brandes <brandes@gmdzi.gmd.de>
  2211. updated:    1992/10/17
  2212.  
  2213. language:    Fortran, C
  2214. package:    cfortran.h
  2215. version:    2.6
  2216. parts:        macros, documentation, examples
  2217. author:        Burkhard Burow
  2218. how to get:    ftp cfortran/* from zebra.desy.de
  2219. description:    cfortran.h is an easy-to-use powerful bridge between
  2220.         C and FORTRAN. It provides a completely transparent, machine
  2221.         independent interface between C and FORTRAN routines and
  2222.         global data.
  2223.         cfortran.h provides macros which allow the C preprocessor to
  2224.         translate a simple description of a C (Fortran) routine or
  2225.         global data into a Fortran (C) interface.
  2226. references:    reviewed in RS/Magazine November 1992 and
  2227.         a user's experiences with cfortran.h are to be described
  2228.         in the 1/93 issue of Computers in Physics.
  2229. portability:    high
  2230. ports:        VAX VMS or Ultrix, DECstation, Silicon Graphics, IBM RS/6000,
  2231.         Sun, CRAY, Apollo, HP9000, LynxOS, f2c, NAG f90.
  2232. contact:    burow@vxdesy.cern.ch
  2233. updated:    1992/04/12
  2234.  
  2235. langauge:    Fortran
  2236. package:    fsplit
  2237. version:    ?
  2238. parts:        ?
  2239. how to get:    ?
  2240. description:    a tool to split up monolithic fortran programs
  2241. updated:    ?
  2242.  
  2243. language:    Fortran
  2244. package:    ?
  2245. version:    ?
  2246. author:        Steve Mccrea <mccrea@gdwest.gd.com>
  2247. description:    a tool to split up monolithic fortran programs
  2248. requires:    new awk
  2249. updated:    ?
  2250.  
  2251. language:    FP
  2252. package:    ? funcproglang ?
  2253. version:    ?
  2254. parts:        translator(C)
  2255. author:        ?
  2256. how to get:    comp.sources.unix archive volume 13
  2257. descrition:    ? Backus Functional Programming ?
  2258. updated:    ?
  2259.  
  2260. language:    Garnet ??
  2261. package:    Garnet
  2262. version:    2.1 alpha
  2263. how to get:    ftp from /usr/garnet/? from a.gp.cs.cmu.edu
  2264. description:    ?
  2265. contact:    ?
  2266. updated:    ?
  2267.  
  2268. language:    Garnet
  2269. package:    Multi-Garnet
  2270. version:    2.1
  2271. how to get:    ftp /usr/garnet/alpha/src/contrib/multi-garnet 
  2272.         from a.gp.cs.cmu.edu
  2273. author:        Michael Sannella <sannella@cs.washington.edu>
  2274. description:    better contstraint system for Garnet ??
  2275. updated:    1992/09/21
  2276.  
  2277. language:    Gofer (Haskell derivitive)
  2278. package:    Gofer
  2279. version:    2.28a
  2280. parts:        interpreter, translator(->C), documentation, examples
  2281. author:        Mark Jones <jones-mark@cs.yale.edu>
  2282. how to get:    ftp pub/haskell/gofer from nebula.cs.yale.edu
  2283.     uk:        pub/Packages/Gofer from ftp.comlab.ox.ac.uk
  2284. description:     Gofer is based quite closely on the Haskell programming
  2285.         language, version 1.2.  It supports lazy evaluation, higher
  2286.         order functions, pattern matching, polymorphism, overloading
  2287.         etc and runs on a wide range of machines.
  2288. conformances:    Gofer does not implement all of Haskell, although it is 
  2289.         very close.
  2290. status:        maintained but not developed (for a while anyway)
  2291. ports:        many, including Sun, PC, Mac, Atari, Amiga
  2292. updated:    1993/03/09
  2293.  
  2294. language:    Haskell
  2295. package:    Chalmers Haskell (aka Haskell B.)
  2296. version:    ?
  2297. parts:        ?
  2298. how to get:    ftp pub/haskell/chalmers/hbc from animal.cs.chalmers.se
  2299. requires:    LML
  2300. contact:    ?
  2301. updated:    1992/07/06
  2302.  
  2303. language:    Haskell
  2304. package:    The Glasgow Haskell Compiler (GHC)
  2305. version:    0.10
  2306. parts:        translator(C), tests, profiler
  2307. how to get:    ftp pub/haskell/glasgow/* from nebula.cs.yale.edu
  2308.     uk:        ftp pub/haskell/glasgow/* from ftp.dcs.glasgow.ac.uk
  2309.     se:        ftp pub/haskell/glasgow/* from animal.cs.chalmers.se
  2310. description:    + almost all of Haskell is implemented
  2311.         + An extensible I/O system is provided, based on a "monad"
  2312.         + significant language extensions are implemented: Fully 
  2313.         fledged unboxed data types, Ability to write arbitrary in-line
  2314.         C-language code, Incrementally-updatable arrays, Mutable
  2315.         reference types.
  2316.         + generational garbage collector
  2317.         + Good error messages
  2318.         + programs compiled with GHC "usually" beat
  2319.         Chalmers-HBC-compiled ones.
  2320.         + compiler is written in a modular and well-documented way.
  2321.         + Highly configurable runtime system. 
  2322.         - No interactive system.
  2323.         - Compiler is greedy on resources.
  2324. requires:    GNU C 2.1+, perl, Chalmers HBC 0.998.x (source build only)
  2325. conformance:    Almost all of Haskell is implemented.
  2326. ports:        Sun4
  2327. portability:    should be high
  2328. bugs:        <glasgow-haskell-bugs@dcs.glasgow.ac.uk>
  2329. contact:    <glasgow-haskell-request@dcs.glasgow.ac.uk>
  2330. updated:    1992/12/14
  2331.  
  2332. language:    Hermes
  2333. package:    IBM Watson prototype Hermes system
  2334. version:    0.8alpha patchlevel 01
  2335. parts:        bytecode compiler, bytecode translator(C), runtime
  2336. author:        Andy Lowry <lowry@watson.ibm.com>
  2337. how to get:    ftp pub/hermes/README from software.watson.ibm.com
  2338. description:    Hermes is a very-high-level integrated language and
  2339.         system for implementation of large systems and
  2340.         distributed applications, as well as for
  2341.         general-purpose programming.  It is an imperative,
  2342.         strongly typed, process-oriented language.  Hermes
  2343.         hides distribution and heterogeneity from the
  2344.         programmer.  The programmer sees a single abstract
  2345.         machine containing processes that communicate using
  2346.         calls or sends.     The compiler, not the programmer,
  2347.         deals with the complexity of data structure layout,
  2348.         local and remote communication, and interaction with
  2349.         the operating system.  As a result, Hermes programs are
  2350.         portable and easy to write.  Because the programming
  2351.         paradigm is simple and high level, there are many
  2352.         opportunities for optimization which are not present in
  2353.         languages which give the programmer more direct control
  2354.         over the machine.
  2355. reference:    Strom, Bacon, Goldberg, Lowry, Yellin, Yemini. Hermes: A
  2356.         Language for Distributed Computing. Prentice-Hall, Englewood
  2357.         Cliffs, NJ.  1991.  ISBN: O-13-389537-8.
  2358. ports:        RS6000 Sun-4 NeXT IBM-RT/bsd4.3 (Sun-3 and Convex soon)
  2359. discussion:    comp.lang.hermes
  2360. updated:    1992/03/22
  2361.  
  2362. language:    Hope
  2363. package:    ?
  2364. parts:        ?
  2365. how to get:    ftp ? from brolga.cc.uq.oz.au
  2366. author:        ?
  2367. description:    Functional language with polymorphic types and lazy lists.
  2368.         First language to use call-by-pattern.
  2369. ports:        Unix, Mac, PC
  2370. updated:    1992/11/27
  2371.  
  2372. language:    ici
  2373. package:    ici
  2374. parts:        interpreter, documentation, examples
  2375. author:        Tim Long
  2376. how to get:    ftp pub/ici.cpio.Z from extro.ucc.su.oz.au
  2377. description:    ICI has dynamic arrays, structures and typing with the flow
  2378.         control     constructs,  operators     and syntax of C.  There are
  2379.         standard functions to provided the sort of support  provided
  2380.         by  the     standard  I/O and the C libraries, as well as addi-
  2381.         tional types and functions to support common needs  such  as
  2382.         simple data bases and character based screen handling.
  2383. ports:        Sun4, 80x86 Xenix, NextStep, MSDOS
  2384. features:    + direct access to many system calls
  2385.         + structures, safe pointers, floating point
  2386.         + simple, non-indexed built in database
  2387.         + terminal-based windowing library
  2388. contact:    ?
  2389. portability:    high
  2390. status:        actively developed.
  2391. updated:    1992/11/10
  2392.  
  2393. language:    Icon
  2394. package:    icon
  2395. version:    8.7 (8.5, 8.0 depending on platform)
  2396. parts:        interpreter, compiler (some platforms), library (v8.8)
  2397. author:        Ralph Griswold <ralph@CS.ARIZONA.EDU>
  2398. how to get:    ftp icon/* from cs.arizona.edu
  2399. description:    Icon is a high-level, general purpose programming language that
  2400.         contains many features for processing nonnumeric data,
  2401.         particularly for textual material consisting of string of
  2402.         characters.
  2403.         - no packages, one name-space
  2404.         - no exceptions
  2405.         + object oiented features
  2406.         + records, sets, lists, strings, tables
  2407.         + unlimited line length
  2408.         - unix interface is primitive
  2409.         + co-expressions
  2410. references:    "The Icon Programmming Language", Ralph E. Griswold and 
  2411.         Madge T. Griswold, Prentice Hall, seond edition, 1990.
  2412.         "The Implementation of the Icon Programmming Language", 
  2413.         Ralph E. Griswold and Madge T. Griswold, Princeton 
  2414.         University Press 1986
  2415. ports:        Amiga, Atari, CMS, Macintosh, Macintosh/MPW, MSDOS, MVS, OS/2,
  2416.         Unix (most variants), VMS, Acorn
  2417. discussion:    comp.lang.icon
  2418. contact:    icon-project@cs.arizona.edu
  2419. updated:    1992/08/21
  2420.  
  2421. language:    IDL (Project DOE's Interface Definition Language)
  2422. package:    SunSoft OMG IDL CFE
  2423. version:    1.0
  2424. parts:        compiler front end, documentation
  2425. author:        SunSoft Inc.
  2426. how to get:    ftp pub/OMG_IDL_CFE_1.0 from omg.org
  2427. description:    OMG's (Object Management Group) CORBA 1.1 (Common
  2428.         Object Request Broker Architecture) specification
  2429.         provides the standard interface definition between
  2430.         OMG-compliant objects.    IDL (Interface Definition
  2431.         Language) is the base mechanism for object
  2432.         interaction.  The SunSoft OMG IDL CFE (Compiler Front
  2433.         End) provides a complete framework for building CORBA
  2434.         1.1-compliant preprocessors for OMG IDL.  To use
  2435.         SunSoft OMG IDL CFE, you must write a back-end; full
  2436.         instructions are included.  No problem.     A complete
  2437.         compiler of IDL would translate IDL into client side
  2438.         and server side routines for remote communication in
  2439.         the same manner as the currrent Sun RPCL compiler. The
  2440.         additional degree of freedom that the IDL compiler
  2441.         front end provides is that it allows integration of new
  2442.         back ends which can translate IDL to various
  2443.         programming languages. Locally at Sun we are working on
  2444.         a back end that will produce C and C++, and we know of
  2445.         companies (members of OMG) that are interested in other
  2446.         target languages such as Pascal or Lisp.
  2447. contact:    idl-cfe@sun.com
  2448. updated:    1992/10/23
  2449.  
  2450. language:    IFP (Illinois Functional Programming)
  2451. package:    ifp
  2452. version:    0.5
  2453. parts:        interpreter
  2454. author:        Arch D. Robison <robison@shell.com>
  2455. how to get:    comp.sources.unix archive volume 10
  2456. description:    A variant of Backus' "Functional Programming" language
  2457.         with a syntax reminiscent of Modula-2.    The interpreter
  2458.         is written in portable C.
  2459. references:    [1] Arch D. Robison, "Illinois Functional Programming: A
  2460.         Tutorial," BYTE, (February 1987), pp. 115--125.
  2461.         [2] Arch D. Robison, "The Illinois Functional
  2462.         Programming Interpreter," Proceedings of 1987 SIGPLAN
  2463.         Conference on Interpreters and Interpretive Techniques,
  2464.         (June 1987), pp. 64-73
  2465. ports:        UNIX, MS-DOS, CTSS (Cray)
  2466. updated:    ?
  2467.  
  2468. language:    INTERCAL
  2469. package:    ?
  2470. version:    ?
  2471. how to get:    archie?
  2472. description:    ?
  2473. contact:    ?
  2474. updated:    ?
  2475.  
  2476. language:    J
  2477. package:    J-mode
  2478. what:        add on to J
  2479. parts:        emacs macros
  2480. how to get:    ftp pub/j/gmacs/j-interaction-mode.el from think.com
  2481. updated:    1991/03/04
  2482.  
  2483. language:    J
  2484. package:    J from ISI
  2485. version:    6
  2486. parts:        interpreter, tutorial
  2487. author:        Kenneth E. Iverson and Roger Hui <hui@yrloc.ipsa.reuter.com>
  2488. how to get:    ftp languages/apl/j/* from watserv1.waterloo.edu
  2489. description:     J was designed and developed by Ken Iverson and Roger Hui.  It
  2490.         is similar to the language APL, departing from APL in using
  2491.         using the ASCII alphabet exclusively, but employing a spelling
  2492.         scheme that retains the advantages of the special alphabet
  2493.         required by APL. It has added features and control structures
  2494.         that extend its power beyond standard APL.  Although it can be
  2495.         used as a conventional procedural programming language, it can
  2496.         also be used as a pure functional programming language.
  2497. ports:        Dec, NeXT, SGI, Sun-3, Sun-4, VAX, RS/6000, MIPS, Mac, Acorn
  2498.         IBM-PC, Atari, 3b1, Amiga
  2499. updated:    1992/10/31
  2500.  
  2501. language:    Janus
  2502. package:    qdjanus
  2503. version:    1.3
  2504. parts:        translator(prolog)
  2505. author:        Saumya Debray <debray@cs.arizona.edu>
  2506. how to get:    ftp janus/qdjanus/* from cs.arizona.edu
  2507. conformance:    mostly compliant with "Programming in Janus" by 
  2508.         Saraswat, Kahn, and Levy.
  2509. description:    janus is a janus-to-prolog compiler meant to be used 
  2510.         with Sicstus Prolog
  2511. updated:    1992/05/18
  2512.  
  2513. language:    Janus
  2514. package:    jc
  2515. version:    1.50 alpha
  2516. parts:        translator(C)
  2517. author:        David Gudeman <gudeman@cs.arizona.edu>
  2518. how to get:    ftp janus/jc/* from cs.arizona.edu
  2519. description:    jc is a janus-to-C compiler (considerably faster than qdjanus).
  2520.         jc is a _sequential_ implementation of a _concurrent_ language.
  2521. status:        jc is an experimental system, undergoing rapid development.  
  2522.         It is in alpha release currently.
  2523. bugs:        jc-bugs@cs.arizona.edu
  2524. discussion:    janusinterest-request@parc.xerox.com
  2525. ports:        sun-4, sun-3, Sequent Symmetry
  2526. updated:    1992/06/09
  2527.  
  2528. language:    Kevo
  2529. package:    kevo
  2530. version:    0.9b2
  2531. parts:        ?, demo programs, user's guid, papers
  2532. author:        Antero Taivalsaari <antero@csr.uvic.ca>
  2533. how to get:    ftp /ursa/kevo/* from ursamajor.uvic.ca
  2534. description:    Experimental prototype-based object-oriented system.
  2535.         Although the Kevo system has been built to experiment
  2536.         with ideas which are somewhat irrelevant from the
  2537.         viewpoint of Forth, the system does bear some
  2538.         resemblance to Forth; in particular, the system
  2539.         executes indirect threaded code, and a great deal
  2540.         of the primitives are similar to those of Forth's.
  2541. ports:        Macintosh ('020 or better)
  2542. contact:    kevo-interest@ursamajor.uvic.ca
  2543. updated:    1992/09/21
  2544.  
  2545. language:    PCN
  2546. package:    PCN
  2547. version:    2.0
  2548. parts:        compiler?, runtime, linker, libraries, tools, debugger, 
  2549.         profiler, tracer
  2550. author:        Ian Foster <foster@mcs.anl.gov>, Steve Tuecke
  2551.         <tuecke@mcs.anl.gov>, and others
  2552. how to get:    ftp pub/pcn/pcn_v2.0.tar.Z from info.mcs.anl.gov
  2553. description:    PCN is a parallel programming system designed to improve
  2554.         the productivity of scientists and engineers using parallel
  2555.         computers.  It provides a simple language for specifying
  2556.         concurrent algorithms, interfaces to Fortran and C, a
  2557.         portable toolkit that allows applications to be developed
  2558.         on a workstation or small parallel computer and run
  2559.         unchanged on supercomputers, and integrated debugging and
  2560.         performance analysis tools.  PCN was developed at Argonne
  2561.         National Laboratory and the California Institute of
  2562.         Technology.  It has been used to develop a wide variety of
  2563.         applications, in areas such as climate modeling, fluid
  2564.         dynamics, computational biology, chemistry, and circuit
  2565.         simulation.
  2566. ports:        (workstation nets): Sun4, NeXT, RS/6000, SGI
  2567.         (multicomputers): iPSC/860, Touchstone DELTA
  2568.         (shared memory multiprocessors): Symmetry/Dynix
  2569. contact:    <pcn@mcs.anl.gov>
  2570. updated:    1993/02/12
  2571.  
  2572. language:    RLaB language (math manipulation - MATLAB-like)
  2573. package:    RLaB
  2574. version:    0.50 - first public release, still alpha
  2575. parts:        interpreter, libraries, documentation
  2576. author:        Ian Searle <ians@eskimo.com>
  2577. how to get:    ftp pub/alpha/RLaB from evans.ee.adfa.oz.au
  2578. description:    RLaB is a "MATLAB-like" matrix-oriented programming
  2579.         language/toolbox.  RLaB focuses on creating a good experimental
  2580.         environment (or laboratory) in which to do matrix math
  2581.         Currently RLaB has numeric scalars and matrices (real and
  2582.         complex), and string scalars, and matrices. RLaB also contains
  2583.         a list variable type, which is a heterogeneous associative
  2584.         array.
  2585. restriction:    GNU General Public License
  2586. requires:    GNUPLOT, lib[IF]77.a (from f2c)
  2587. ports:        many unix, OS/2, Amiga
  2588. bugs:        Ian Searle <ians@eskimo.com>
  2589. updated:    1993/02/16
  2590.  
  2591. language:    FUDGIT language (math manipulation)
  2592. package:    FUDGIT
  2593. version:    2.27
  2594. parts:        interpreter
  2595. author:        Thomas Koenig <ig25@rz.uni-karlsruhe.de> ??
  2596. how to get:    ftp /pub/linux/sources/usr.bin/fudgit-* from tsx-11.mit.edu ??
  2597. description:    FUDGIT is a double-precision multi-purpose fitting program.  It
  2598.         can manipulate complete columns of numbers in the form of
  2599.         vector arithmetic. FUDGIT is also an expression language
  2600.         interpreter understanding most of C grammar except pointers.
  2601.         Morever, FUDGIT is a front end for any plotting program
  2602.         supporting commands from stdin. It is a nice mathematical
  2603.         complement to GNUPLOT, for example.
  2604. requires:    GNUPLOT
  2605. ports:        AIX, HPUX, Linux, IRIX, NeXT, SunOS, Ultrix
  2606. updated:    1993/02/22
  2607.  
  2608. language:    Unix BC (arbitrary-precision arithmetic language)
  2609. package:    GNU BC
  2610. version:    1.02
  2611. parts:        interpreter?
  2612. author:        ?
  2613. how to get:    ftp bc-1.02.tar.Z from a GNU archive site
  2614. description:    Bc is an arbitrary precision numeric processing language.  Its
  2615.         syntax in similar to C but differs in many substantial areas.
  2616.         This version was written to be a POSIX compliant bc processor
  2617.         with several extensions to the draft standard.  This version
  2618.         does not use the historical method of having bc be a compiler
  2619.         for the dc calculator.  This version has a single executable
  2620.         that both compiles the language and runs the resulting "byte
  2621.         code".  The "byte code" is NOT the dc language.
  2622. bugs:        ?
  2623. updated:    ?
  2624.  
  2625. language:    Calc?  (symbolic math calculator)
  2626. package:    Calc
  2627. version:    2.02
  2628. parts:        interpreter, emacs mode
  2629. author:        ?
  2630. how to get:    ftp calc-2.02.tar.z from a GNU archive site
  2631. description:    Calc is an extensible, advanced desk calculator and
  2632.         mathematical tool written in Emacs Lisp that runs as part of
  2633.         GNU Emacs.  It is accompanied by the "Calc Manual", which
  2634.         serves as both a tutorial and a reference.  If you wish, you
  2635.         can use Calc as only a simple four-function calculator, but it
  2636.         also provides additional features including choice of algebraic
  2637.         or RPN (stack-based) entry, logarithms, trigonometric and
  2638.         financial functions, arbitrary precision, complex numbers,
  2639.         vectors, matrices, dates, times, infinities, sets, algebraic
  2640.         simplification, differentiation, and integration.
  2641. bugs:        ?
  2642. updated:    ?
  2643.  
  2644. language:    lex
  2645. package:    flex
  2646. version:    2.3.7
  2647. parts:        scanner generator
  2648. how to get:    ftp flex-2.3.7.tar.Z from a GNU archive site or ftp.ee.lbl.gov
  2649. author:        Vern Paxson <vern@ee.lbl.gov>
  2650. updated:    1992/10/20
  2651.  
  2652. language:    LIFE (Logic, Inheritance, Functions, and Equations)
  2653. package:    Wild_LIFE
  2654. version:    first-release
  2655. parts:        interpreter, manual, tests, libraries, examples
  2656. author:        Paradise Project, DEC Paris Research Laboratory.
  2657. how to get:    ftp pub/plan/Life.tar.Z from gatekeeper.dec.com.
  2658. description:    LIFE is an experimental programming language with a
  2659.         powerful facility for structured type inheritance.  It
  2660.         reconciles styles from functional programming, logic
  2661.         programming, and object-oriented programming.  LIFE
  2662.         implements a constraint logic programming language with
  2663.         equality (unification) and entailment (matching)
  2664.         constraints over order-sorted feature terms.  The
  2665.         Wild_LIFE interpreter has a comfortable user interface
  2666.         with incremental query extension ability.  It contains
  2667.         an extensive set of built-in operations as well as an X
  2668.         Windows interface.
  2669. conformance:    semantic superset of LOGIN and LeFun.  Syntax is similar
  2670.         to prolog.
  2671. discussion:    life-request@prl.dec.com
  2672. bugs:        life-bugs@prl.dec.com
  2673. contact:    Peter Van Roy <vanroy@prl.dec.com>
  2674. ports:        MIPS-Ultrix
  2675. portability:    good in theory
  2676. updated:    1992/12/14
  2677.  
  2678. language:    lisp
  2679. package:    RefLisp
  2680. version:    2.67
  2681. parts:        interpreter, documentation, examples, profiler
  2682. author:        Bill Birch <bbirch@hemel.bull.co.uk>
  2683. how to get:    ftp implementations/reflisp/* from the directory 
  2684.         /afs/cs.cmu.edu/user/mkant/Public/Lisp on ftp.cs.cmu.edu
  2685. description:    The interpreter is a shallow-binding (i.e., everything has
  2686.         dynamic scope), reference counting design making it suitable
  2687.         for experimenting with real-time and graphic user interface
  2688.         programming. Common Lisp compatibility macros are provided, and
  2689.         most of the examples in "Lisp" by Winston & Horn have been run
  2690.         on RefLisp.  RefLisp makes no distinction between symbol-values
  2691.         and function-values, so a symbol can be either but not both.
  2692.         There are Lisp modules for lexical scope and for running
  2693.         indefinite extent Scheme programs.
  2694. status:        "Last Update for a While," author is emigrating to Australia
  2695. ports:        MSDOS (CGA/EGA/VGA), Unix (AIX)
  2696. updated:    1993/02/09
  2697.  
  2698. language:    lisp
  2699. package:    xlisp
  2700. version:    2.1
  2701. parts:        interpreter
  2702. author:        David Micheal Betz <dbetz@apple.com>
  2703. how to get:    ftp pub/xlisp* from wasp.eng.ufl.edu
  2704.     usmail:    contact Tom Almy <toma@sail.labs.tek.com>
  2705.     windows:    ftp util/wxlslib.zip from ftp.cica.indiana.edu
  2706.     version2.0: ftp pub/xlisp/* from cs.orst.edu
  2707. description:    XLISP is an experimental programming language
  2708.         combining some of the features of Common Lisp with an
  2709.         object-oriented extension capability.  It was
  2710.         implemented to allow experimentation with
  2711.         object-oriented programming on small computers.
  2712. conformance:    subset of Common Lisp with additions of Class and Object
  2713. portability:    very high: just needs a C compiler
  2714. ports:        unix, amiga, atari, mac, MSDOS
  2715. restriction:    ? no commercial use ?
  2716. updated:    1992/05/26 (unix), 1987/12/16 (other platforms)
  2717.  
  2718. language:    lisp
  2719. package:    "LISP, Objects, and Symbolic Programming"
  2720. version:    ? 
  2721. parts:        book with compiler included
  2722. author:        Robert R. Kessler and Amy R. Petajan
  2723. publisher:    Scott, Foresman and Company, Glenview, IL
  2724. how to get:    bookstore...
  2725. updated:    1988
  2726.  
  2727. language:    lisp
  2728. package:    franz lisp
  2729. version:    ?
  2730. how to get:    [does anyone know where you get franz lisp??? --muir]
  2731. author:        ?
  2732. discussion:    franz-friends-request@berkeley.edu
  2733. updated:    ?
  2734.  
  2735. language:    lisp (WOOL - Window Object Oriented Language)
  2736. package:    GWM (Generic Window Manager)
  2737. version:    ?
  2738. parts:        interpreter, examples
  2739. author:        ?
  2740. how to get:    ftp contrib/gwm/* from export.lcs.mit.edu
  2741.     france:    ftp pub/gwm/* from avahi.inria.fr
  2742. description:    Gwm is an extensible window manager for X11.  It is
  2743.         based on a WOOL kernel, and interpreted dialect of lisp 
  2744.         with specific winow management primitives.
  2745. discussion:    gwm-talk@???
  2746. contact:    ?
  2747. updated:    ?
  2748.  
  2749. language:    lisp (elisp - Emacs Lisp)
  2750. package:    GNU Emacs
  2751. version:    18.59
  2752. parts:        editor, interpreter, documentation
  2753. author:        Richard Stallman <rms@gnu.ai.mit.edu> and others
  2754. description:    An editor that is almost an operating system.  Quite
  2755.         programmable.  [someone want to say something better? --muir]
  2756. discussion:    alt.religion.emacs, gnu.emacs.sources
  2757. announcements:    gnu.emacs.announce
  2758. bugs:        gnu.emacs.bug
  2759. help:        gnu.emacs.help
  2760. ports:        Unix, VMS, ?
  2761. updated:    ?
  2762.  
  2763. language:    Logo
  2764. package:    logo
  2765. version:    4
  2766. parts:        interpreter
  2767. author:        ?
  2768. how to get:    comp.sources.unix archive volume 10
  2769. description:    ?
  2770. updated:    ?
  2771.  
  2772. language:    Logo
  2773. package:    Berkeley Logo
  2774. version:    2.9 - alpha
  2775. parts:        interpreter
  2776. author:        Brian Harvey <bh@anarres.CS.Berkeley.EDU>
  2777. how to ge:    ftp pub/*logo* from anarres.cs.berkeley.edu
  2778. description:    + Logo programs are compatible among Unix, PC, and Mac.
  2779.         + "richer" than MswLogo
  2780.         - pretty slow.
  2781.         - doesn't do anything fancy about graphics.  (One turtle.)
  2782. ports:        unix, pc, mac
  2783. updated:    1993/03/01
  2784.  
  2785. language:    Logo
  2786. package:    MswLogo
  2787. version:    3.2
  2788. parts:        interpreter
  2789. author:        George Mills <mills@athena.lkg.dec.com>
  2790. how to get:    ftp pd1:<msdos.log>/MSW*.ZIP from OAK.Oakland.Edu
  2791. description:    A windows front-end for Berkeley Logo
  2792. status:        activly developed
  2793. bugs:        George Mills <mills@athena.lkg.dec.com>
  2794. ports:        MS Windows 3.x
  2795. updated:    1992/10/17
  2796.  
  2797. language:    Lolli (logic programming)
  2798. package:    Lolli
  2799. parts:        ?
  2800. how to get:    ftp pub/Lolli/Lolli-07.tar.Z. from ftp.cis.upenn.edu
  2801. author:        ? Josh Hodas <hodas@saul.cis.upenn.edu> ?
  2802. description:    Lolli is an interpreter for logic programming based 
  2803.         on linear logic principles.
  2804.         Lolli can be viewed as a refinement of the the
  2805.         Hereditary Harrop formulas of Lambda-Prolog. All the
  2806.         operators (though not the higher order unification) of
  2807.         Lambda-Prolog are supported, but with the addition of
  2808.         linear variations. Thus a Lolli program distinguishes
  2809.         between clauses which can be used as many, or as few,
  2810.         times as desired, and those that must be used exactly
  2811.         once.
  2812. requires:    ML
  2813. updated:    1992/11/08
  2814.  
  2815. language:    LOOPN
  2816. package:    LOOPN
  2817. version:    ?
  2818. parts:        compiler?, simulator
  2819. how to get:    ftp departments/computer_sci*/loopn.tar.Z from ftp.utas.edu.au
  2820. description:    I wish to announce the availability of a compiler, simulator
  2821.         and associated source control for an object-oriented petri net
  2822.         language called LOOPN.  In LOOPN, a petri net is an extension
  2823.         of coloured timed petri nets.  The extension means firstly that
  2824.         token types are classes.  In other words, they consist of both
  2825.         data fields and functions, they can be declared by inheriting
  2826.         from other token types, and they can be used polymorphically.
  2827.         The object-oriented extensions also mean that module or subnet
  2828.         types are classes.  LOOPN has been developed over a period of
  2829.         about 5 years at the University of Tasmania, where it has been
  2830.         used in teaching computer simulation and the modelling of
  2831.         network protocols.  A petri net is a directed, bipartite graph;
  2832.         nodes are either places (represented by circles) or transitions
  2833.         (represented by rectangles).  A net is marked by placing tokens
  2834.         on places.  When all the places pointing to a transition (the
  2835.         input places) have a token, the net may be fired by removing a
  2836.         token from each input place and adding a token to each place
  2837.         pointed to by the transition (the output places).  Petri nets
  2838.         are used to model concurrent systems, particularly in the
  2839.         network protocol area.
  2840. contact:    Charles Lakos <charles@probitas.cs.utas.edu.au>
  2841. updated:    1992/12/20
  2842.  
  2843. language:    MeldC (MELD, C)
  2844. package:    MeldC
  2845. version:    2.0
  2846. parts:        microkernel, compiler, debugger, manual, examples
  2847. author:        MELD Project,  Programming Systems Laboratory at 
  2848.         Columbia University
  2849. how to get:    obtain license from <MeldC@cs.columbia.edu>
  2850. restriction:    must sign license, cannot use for commercial purposes
  2851. description:    MeldC 2.0: A Reflective Object-Oriented Coordination
  2852.         Programming Language MELDC  is    a C-based, concurrent,
  2853.         object-oriented language built on a reflective
  2854.         architecture.     The  core  of    the  architecture  is
  2855.         a micro-kernel    (the MELDC kernel), which encapsulates
  2856.         a minimum set of entities that cannot be modeled as
  2857.         objects.  All  components  outside of        the
  2858.         kernel    are  implemented  as objects in MELDC itself
  2859.         and are modularized in the MELDC libraries.  MELDC is
  2860.         reflective in three  dimensions:       structural,
  2861.         computational and  architectural.  The structural
  2862.         reflection indicates that classes and meta-classes are
  2863.         objects,  which     are       written  in    MELDC.      The
  2864.         computational  reflection means that object behaviors
  2865.         can be computed and extended at runtime.  The
  2866.         architectural reflection indicates that new
  2867.         features/properties  (e.g.,  persistency  and
  2868.         remoteness) can be constructed in MELDC.
  2869. ports:        Sun4/SunOS4.1 Mips/Ultrix4.2
  2870. contact:    <MeldC@cs.columbia.edu>
  2871. updated:    1992/12/15
  2872.  
  2873. language:    ML
  2874. package:    LML
  2875. version:    ?
  2876. parts:        compiler(?), interactive environment
  2877. how to get:    ftp ? from animal.cs.chalmers.se
  2878. description:    lazy, completely functional variant of ML.
  2879. ports:        ?
  2880. contact:    ?
  2881. updated:    1992/07/06
  2882.  
  2883. langauge:    m4
  2884. package:    GNU m4
  2885. version:    1.0
  2886. parts:        interperter, ?
  2887. how to get:    ftp m4-1.0.tar.Z from a GNU archive site
  2888. author:        ?
  2889. description:    A macro preprocessor language, somewhat flexible.
  2890. conformance:    ?
  2891. ports:        ?
  2892. updated:    1991/10/25
  2893.  
  2894. language:    Modula-2, Pascal
  2895. package:    m2
  2896. version:    ? 7/2/92 ?
  2897. parts:        ? compiler ?
  2898. history:    The compiler was designed and built by Michael L.
  2899.         Powell, and originally released in 1984.  Joel
  2900.         McCormack sped the compiler up, fixed lots of bugs, and
  2901.         swiped/wrote a User's Manual.  Len Lattanzi ported the
  2902.         compiler to the MIPS.
  2903. description:    A modula-2 compiler for VAX and MIPS.  A Pascal
  2904.         compiler for VAX is also included.  The Pascal compiler
  2905.         accepts a language that is almost identical to Berkeley
  2906.         Pascal.
  2907. conformance:    extensions:    
  2908.         + foreign function and data interface
  2909.         + dynamic array variables
  2910.         + subarray parameters
  2911.         + multi-dimensional open array parameters
  2912.         + inline proceedures
  2913.         + longfloat type
  2914.         + type-checked interface to C library I/O routines
  2915. how to get:    ftp pub/DEC/Modula-2/m2.tar.Z from gatekeeper.dec.com
  2916. restriction:    must pass changes back to Digital
  2917. ports:        vax (ultrix, bsd), mips (ultrix)
  2918. contact:    modula-2@decwrl.pa.dec.com
  2919. updated:    1992/07/06
  2920.  
  2921. language:    Modula-2
  2922. package:    mtc
  2923. parts:        translator(C)
  2924. how to get:    ftp soft/unixtools/compilerbau/mtc.tar.Z 
  2925.         from rusmv1.rus.uni-stuttgart.de 
  2926. author:        ?
  2927. description:    ?
  2928. ports:        ?
  2929. updated:    1991/10/25
  2930.  
  2931. language:    Modula-2, Modula-3
  2932. package:    M2toM3 ?
  2933. version:    ?
  2934. parts:        translator(Modula-2 -> Modula-3), ?
  2935. author:        ?
  2936. how to get:    ftp pub/DEC/Modula-3/contrib/M2toM3 from gatekeeper.dec.com
  2937. description:    ?
  2938. requires:    ?
  2939. updated:    ?
  2940.  
  2941. language:    Modula-2
  2942. package:    PRAM emulator and parallel modula-2 compiler ??
  2943. version:    ?
  2944. parts:        compiler, emulator
  2945. how to get:    ftp pub/pram/* from cs.joensuu.fi
  2946. description:    A software emulator for parallel random access machine (PRAM)
  2947.         and a parallel modula-2 compiler for the emulator.  A PRAM
  2948.         consists of P processors, an unbounded shared memory, and a
  2949.         common clock. Each processor is a random access machine (RAM)
  2950.         consisting of R registers, a program counter, and a read-only
  2951.         signature register. Each RAM has an identical program, but the
  2952.         RAMs can branch to different parts of the program. The RAMs
  2953.         execute the program synchronously one instruction in one clock
  2954.         cycle.
  2955.         pm2 programming language is Modula-2/Pascal mixture having
  2956.         extensions for parallel execution in a PRAM. Parallelism is
  2957.         expressed by pardo-loop- structure. Additional features include
  2958.         privat/shared variables, two synchronization strategies, load
  2959.         balancing and parallel dynamic memory allocation.
  2960. contact:    Simo Juvaste <sjuva@cs.joensuu.fi>
  2961. updated:    1993/02/17
  2962.  
  2963. language:    Modula-3
  2964. package:    SRC Modula-3
  2965. version:    2.11
  2966. parts:        translator(C), runtime, library, documentation
  2967. how to get:    ftp pub/DEC/Modula-3/m3-*.tar.Z from gatekeeper.dec.com
  2968. description:    The goal of Modula-3 is to be as simple and safe as it
  2969.         can be while meeting the needs of modern systems
  2970.         programmers.  Instead of exploring new features, we
  2971.         studied the features of the Modula family of languages
  2972.         that have proven themselves in practice and tried to
  2973.         simplify them into a harmonious language.  We found
  2974.         that most of the successful features were aimed at one
  2975.         of two main goals: greater robustness, and a simpler,
  2976.         more systematic type system.  Modula-3 retains one of
  2977.         Modula-2's most successful features, the provision for
  2978.         explicit interfaces between modules.  It adds objects
  2979.         and classes, exception handling, garbage collection,
  2980.         lightweight processes (or threads), and the isolation
  2981.         of unsafe features.
  2982. conformance:    implements the language defined in SPwM3.
  2983. ports:        i386/AIX 68020/DomainOS Acorn/RISCiX MIPS/Ultrix 68020/HP-UX
  2984.         RS6000/AIX IBMRT/4.3 68000/NextStep i860/SVR4 SPARC/SunOS
  2985.         68020/SunOS sun386/SunOS Multimax/4.3 VAX/Ultrix
  2986. contact:    Bill Kalsow <kalsow@src.dec.com>
  2987. discussion:    comp.lang.modula3
  2988. updated:    1992/02/09
  2989.  
  2990. language:    Modula-3
  2991. package:    m3pc
  2992. parts:        ?
  2993. author:        ?
  2994. how to get:    ftp pub/DEC/Modula-3/contrib/m3pc* from gatekeeper.dec.com
  2995. description:    an implementation of Modula-3 for PCs.
  2996.         [Is this SRC Modula-3 ported? --muir]
  2997. updated:    ?
  2998.  
  2999. language:    Motorola DSP56001 assembly
  3000. package:    a56
  3001. version:    1.1
  3002. parts:        assembler
  3003. author:        Quinn C. Jensen <jensenq@qcj.icon.com>
  3004. how to get:    alt.sources archive
  3005. updated:    1992/08/10
  3006.  
  3007. language:    natural languages
  3008. package:    proof
  3009. parts:        parser, documentation
  3010. author:        Craig R. Latta <latta@xcf.Berkeley.EDU>
  3011. how to get:    ftp src/local/proof/* from scam.berkeley.edu
  3012. description:    a left-associative natural language grammar scanner
  3013. bugs:        proof@xcf.berkeley.edu
  3014. discussion:    proof-request@xcf.berkeley.edu ("Subject: add me")
  3015. ports:        Decstation3100 Sun-4
  3016. updated:    1991/09/23
  3017.  
  3018. language:    NewsClip ?
  3019. package:    NewsClip
  3020. version:    1.01
  3021. parts:        translator(NewsClip->C), examples, documentation
  3022. author:        Looking Glass Software Limited but distributed by 
  3023.         ClariNet Communications Corp.
  3024. description:    NewsClip is a very high level language designed for
  3025.         writing netnews filters.  It translates into C.
  3026.         It includes support for various newsreaders.
  3027. restriction:    Cannot sell the output of the filters.  Donation is hinted at.
  3028. status:        supported for ClariNet customers only
  3029. contact:    newsclip@clarinet.com
  3030. updated:    1992/10/25
  3031.  
  3032. language:    Oaklisp
  3033. package:    oaklisp
  3034. version:    1.2
  3035. parts:        interface, bytecode compiler, runtime system, documentation
  3036. author:        Barak Pearlmutter, Kevin Lang
  3037. how to get:    ftp /afs/cs.cmu.edu/user/bap/oak/ftpable/* from f.gp.cs.cmu.edu
  3038. description:    Oaklisp is a Scheme where everything is an object.  It 
  3039.         provides multiple inheritence, a strong error system,
  3040.         setters and locators for operations, and a facility for
  3041.         dynamic binding.
  3042. status:        actively developed?
  3043. contact:    Pearlmutter-Barak@CS.Yale.Edu ?
  3044. updated:    1992/05 ?
  3045.  
  3046. language:    Oberon
  3047. package:    Oberon from ETH Zurich
  3048. version:    2.2 (msdos: 1.0)
  3049. parts:        compiler, programming environment, libraries, documenation
  3050. how to get:    ftp Oberon/* from neptune.inf.ethz.ch
  3051.     MSDOS:    ftp Oberon/DOS386/* from neptune.inf.ethz.ch
  3052.     macintosh:    ??? same package or different ??? ftp 
  3053.         /mac/development/languages/macoberon2.40.sit.hqx 
  3054.         from archive.umich.edu
  3055. author:        Josef Templ <templ@inf.ethz.ch>
  3056. conformance:    superset (except Mac)
  3057. ports:        DECstation/MIPS/Ultrix/X11 Macintosh/68020/MacOS/QuickDraw
  3058.         IBM/RS6000/AIX/X11 Sun-4/SunOS4/X11 Sun-4/SunOS4/pixrect
  3059.         MSDOS
  3060. contact:    Leuthold@inf.ethz.ch
  3061. updated:    1992/07/20
  3062.  
  3063. language:    Oberon2
  3064. package:    Oberon-2 LEX/YACC definition 
  3065. version:    1.4
  3066. parts:        parser(yacc), scanner(lex)
  3067. how to get:    mail bevan@cs.man.ac.uk with Subject "b-server-request~ and
  3068.         body "send oberon/oberon_2_p_v1.4.shar"
  3069. author:        Stephen J Bevan <bevan@cs.man.ac.uk>
  3070. parts:        scanner(lex) parser(yacc)
  3071. status:        un-officially supported
  3072. updated:    1992/07/06
  3073.  
  3074. language:    OPS5
  3075. package:    PD OPS5
  3076. version:    ?
  3077. parts:        interpreter
  3078. how to get:    ftp /afs/cs.cmu.edu/user/mkant/Public/Lisp/ops5* from 
  3079.         ftp.cs.cmu.edu
  3080. author:        Written by Charles L. Forgy and ported to Common Lisp by 
  3081.         George Wood and Jim Kowalski. 
  3082. description:    Public domain implementation of an OPS5 interpreter. OPS5 is
  3083.         a programming language for production systems.     ??????
  3084. contact:    ? Mark Kantrowitz <mkant+@cs.cmu.edu> ?
  3085. requires:    Common Lisp
  3086. updated:    1992/10/17
  3087.  
  3088. language:    Parallaxis
  3089. package:    parallaxis
  3090. version:    2.0
  3091. parts:        ?, simulator, x-based profiler
  3092. author:        ?
  3093. how to get:    ftp pub/parallaxis from ftp.informatik.uni-stuttgart.de
  3094. description:    Parallaxis is a procedural programming language based
  3095.         on Modula-2, but extended for data parallel (SIMD) programming.
  3096.         The main approach for machine independent parallel programming 
  3097.         is to include a description of the virtual parallel machine 
  3098.         with each parallel algorithm.
  3099. ports:        MP-1, CM-2, Sun-3, Sun-4, DECstation, HP 700, RS/6000
  3100. contact:    ? Thomas Braunl <braunl@informatik.uni-stuttgart.de> ?
  3101. updated:    1992/10/23
  3102.  
  3103. language:    Parlog
  3104. package:    SPM System (Sequential Parlog Machine)
  3105. version:    ?
  3106. parts:        ?, documenation
  3107. author:        ?
  3108. how to get:    ? ftp lang/Parlog.tar.Z from nuri.inria.fr
  3109. description:    a logic programming language ?
  3110. references:    Steve Gregory, "Parallel Logic Programming in PARLOG", 
  3111.         Addison-Wesely, UK, 1987
  3112. ports:        Sun-3 ?
  3113. restriction:    ? no source code ?
  3114. updated:    ??
  3115.  
  3116. language:    Pascal
  3117. package:    p2c
  3118. version:    1.20
  3119. parts:        translator(Pascal->C)
  3120. author:        Dave Gillespie <daveg@synaptics.com>
  3121. how to get:    ftp ? from csvax.cs.caltech.edu
  3122. conformance:    supports ANSI/ISO standard Pascal as well as substantial 
  3123.         subsets of HP, Turbo, VAX, and many other Pascal dialects.
  3124. ports:        ?
  3125. updated:    1990/04/13
  3126.  
  3127. language:    Pascal
  3128. package:    ? iso_pascal ?
  3129. version:    ?
  3130. parts:        scanner(lex), parser(yacc)
  3131. author:        ?
  3132. how to get:    comp.sources.unix archive volume 13
  3133. description:    ?
  3134. updated:    ?
  3135.  
  3136. language:    Pascal, Lisp, APL, Scheme, SASL, CLU, Smalltalk, Prolog
  3137. package:    Tim Budd's C++ implementation of Kamin's interpreters
  3138. version:    ?
  3139. parts:        interpretors, documentation
  3140. author:        Tim Budd <budd@cs.orst.edu>
  3141. how to get:    ? ftp pub/budd/kamin/*.shar from cs.orst.edu ?
  3142. description:    a set of interpretors written as subclasses based on
  3143.         "Programming Languages, An Interpreter-Based Approach",
  3144.         by Samuel Kamin.
  3145. requires:    C++
  3146. status:        ? 
  3147. contact:    Tim Budd <budd@fog.cs.orst.edu>
  3148. updated:    1991/09/12
  3149.  
  3150. language:    Pascal
  3151. package:    ? frontend ?
  3152. version:    Alpha
  3153. parts:        frontend (lexer, parser, semantic analysis)
  3154. author:        Willem Jan Withagen <wjw@eb.ele.tue.nl>
  3155. how to get:    ftp pub/src/pascal/front* from ftp.eb.ele.tue.nl
  3156. description:    a new version of the PASCAL frontend using the Cocktail 
  3157.         compiler tools.
  3158. updated:    1993/02/24
  3159.  
  3160. language:    Pascal
  3161. package:    ptc
  3162. version:    ?
  3163. parts:        translator(Pacal->C)
  3164. how to get:    ftp languages/ptc from uxc.sco.uiuc.edu ?  (use archie?)
  3165. description:    ?
  3166. contact:    ?
  3167. updated:    ?
  3168.  
  3169. language:    Turbo Pascal, Turbo C
  3170. package:    tptc
  3171. version:    ?
  3172. parts:        translator(Turbo Pascal->Turbo C)
  3173. how to get:    ftp mirrors/msdos/turbopas/tptc17*.zip from wuarchive.wustl.edu
  3174. description:    (It does come with full source and a student recently used it
  3175.         as a start for a language that included stacks and queues as a
  3176.         built-in data type.
  3177. contact:    ?
  3178. updated:    ?
  3179.  
  3180. language:    Perl (Practical Extraction and Report Language)
  3181. package:    perl
  3182. version:    4.0 patchlevel 36
  3183. parts:        interpreter, debugger, libraries, tests, documentation
  3184. how to get:    ftp pub/perl.4.0/* from jpl-devvax.jpl.nasa.gov 
  3185.     OS/2 port:    ftp pub/os2/all/unix/prog*/perl4019.zip from hobbes.nmsu.edu
  3186.     Mac port:    ftp software/mac/src/mpw_c/Mac_Perl_405_* from nic.switch.ch
  3187.     Amiga port: ftp perl4.035.V010.* from wuarchive.wustl.edu
  3188.     VMS port:    ftp software/vms/perl/* from ftp.pitt.edu
  3189.     Atari port: ftp amiga/Languages/perl* from atari.archive.umich.edu
  3190.     DOS port:    ftp pub/msdos/perl/* from ftp.ee.umanitoba.ca
  3191. author:        Larry Wall <lwall@netlabs.com>
  3192. description:    perl is an interpreted language optimized for scanning 
  3193.         arbitrary text files, extracting information from those text
  3194.         files, and printing reports based on that information.    It's
  3195.         also a good language for many system management tasks.    
  3196. features:    + very-high semantic density becuase of powerful operators
  3197.         like regular expression substitution
  3198.         + exceptions, provide/require
  3199.         + associative array can be bound to dbm files
  3200.         + no arbitrary limits
  3201.         + direct access to almost all system calls
  3202.         + can access binary data
  3203.         + many powerful common-task idioms
  3204.         - three variable types: scalar, array, and hash table
  3205.         - unappealing syntax
  3206. references:    "Programming Perl" by Larry Wall and Randal L. Schwartz,
  3207.         O'Reilly & Associates, Inc.  Sebastopol, CA.
  3208.         ISBN 0-93715-64-1
  3209. discussion:    comp.lang.perl
  3210. bugs:        comp.lang.perl; Larry Wall <lwall@netlabs.com>
  3211. ports:        almost all unix, MSDOS, Mac, Amiga, Atari, OS/2, VMS
  3212. portability:    very high for unix, not so high for others
  3213. updated:    1993/02/07
  3214.  
  3215. language:    perl, awk, sed, find
  3216. package:    a2p, s2p, find2perl
  3217. parts:        translators(perl)
  3218. author:        Larry Wall
  3219. how to get:    comes with perl
  3220. description:    translators to turn awk, sed, and find into perl.
  3221.  
  3222. language:    perl, yacc
  3223. package:    perl-byacc
  3224. version:    1.8.2
  3225. parts:        parser-generator(perl)
  3226. how to get:    ftp local/perl-byacc.tar.Z from ftp.sterling.com
  3227. author:        Rick Ohnemus <rick@IMD.Sterling.COM>
  3228. description:    A modified version of byacc that generates perl code.  Has '-p'
  3229.         switch so multiple parsers can be used in one program (C or
  3230.         perl).
  3231. portability:    Should work on most (?) UNIX systems.  Also works with 
  3232.         SAS/C 6.x on AMIGAs.
  3233. updated:    1993/01/24
  3234.  
  3235. language:    Postscript
  3236. package:    Ghostscript
  3237. version:    2.5.2
  3238. parts:        interpreter, ?
  3239. author:        L. Peter Deutsch <ghost%ka.cs.wisc.edu@cs.wisc.edu>
  3240. how to get:    ftp pub/GNU/ghostscript* from a GNU archive site
  3241. description:    ?
  3242. updated:    1992/10/07
  3243.  
  3244. language:    Postscript, Common Lisp
  3245. package:    PLisp
  3246. version:    ?
  3247. parts:        translator(Postscript), programming environment(Postscript)
  3248. description:    ?
  3249. author:        John Peterson <peterson-john@cs.yale.edu>
  3250. updated:    ?
  3251.  
  3252. language:    Prolog
  3253. package:    SB-Prolog
  3254. version:    3.1 ?
  3255. author:        interpreter
  3256. how to get:    ftp pub/sbprolog from sbcs.sunysb.edu
  3257. description:    ?
  3258. contact:    ? warren@sbcs.sunysb.edu ?
  3259. restriction:    GNU General Public License
  3260. updated:    ?
  3261.  
  3262. langauge:    Prolog
  3263. package:    Modular SB-Prolog
  3264. version:    ?
  3265. parts:        interpreter
  3266. how to get:    ftp pub/dts/mod-prolog.tar.Z from ftp.dcs.ed.ac.uk
  3267. description:    SB-Prolog version 3.1 plus modules
  3268. ports:        Sparc
  3269. contact:    Brian Paxton <mprolog@dcs.ed.ac.uk>
  3270. restriction:    GNU General Public License
  3271. updated:    ?
  3272.  
  3273. language:    ALF [prolog variant]
  3274. package:    alf (Algebraic Logic Functional programming language) 
  3275. version:    ?
  3276. parts:        runtime, compiler(Warren Abstract Machine)
  3277. author:        Rudolf Opalla <opalla@julien.informatik.uni-dortmund.de>
  3278. how to get:    ftp pub/programming/languages/LogicFunctional from
  3279.         ftp.germany.eu.net
  3280. description:    ALF is a language which combines functional and
  3281.         logic programming techniques.  The foundation of
  3282.         ALF is Horn clause logic with equality which consists
  3283.         of predicates and Horn clauses for logic programming,
  3284.         and functions and equations for functional programming.
  3285.         Since ALF is an integration of both programming
  3286.         paradigms, any functional expression can be used
  3287.         in a goal literal and arbitrary predicates can
  3288.         occur in conditions of equations.
  3289. updated:    1992/10/08
  3290.  
  3291. language:    CLP (Constraint Logic Programming language) [Prolog variant]
  3292. package:    CLP(R)
  3293. version:    1.2
  3294. parts:        runtime, compiler(byte-code), contstraint solver
  3295. author:        IBM
  3296. how to get:    mail to Joxan Jaffar <joxan@watson.ibm.com>
  3297. description:    CLP(R) is a constraint logic programming language
  3298.         with real-arithmetic constraints.  The implementation
  3299.         contains a built-in constraint solver which deals
  3300.         with linear arithmetic and contains a mechanism
  3301.         for delaying nonlinear constraints until they become
  3302.         linear.     Since CLP(R) subsumes PROLOG, the system
  3303.         is also usable as a general-purpose logic programming
  3304.         language.  There are also powerful facilities for
  3305.         meta programming with constraints.  Significant
  3306.         CLP(R) applications have been published in diverse
  3307.         areas such as molecular biology, finance, physical
  3308.         modelling, etc.     We are distributing CLP(R) in order 
  3309.         to help widen the use of constraint programming, and 
  3310.         to solicit feedback on the system
  3311. restriction:    free for academic and research purposes only
  3312. contact:    Roland Yap <roland@bruce.cs.monash.edu.au>, Joxan Jaffar
  3313. ports:        unix, msdos, OS/2
  3314. updated:    1992/10/14
  3315.  
  3316. language:    Prolog (variant)
  3317. package:    Aditi
  3318. version:    Beta Release
  3319. parts:        interpreter, database
  3320. author:        Machine Intelligence Project, Univ. of Melbourne, Australia
  3321. how to get:    send email to aditi@cs.mu.oz.au
  3322. description:    The Aditi Deductive Database System is a multi-user
  3323.         deductive database system.  It supports base relations
  3324.         defined by facts (relations in the sense of relational
  3325.         databases) and derived relations defined by rules that
  3326.         specify how to compute new information from old
  3327.         information.  Both base relations and the rules
  3328.         defining derived relations are stored on disk and are
  3329.         accessed as required during query evaluation.  The
  3330.         rules defining derived relations are expressed in a
  3331.         Prolog-like language, which is also used for expressing
  3332.         queries.  Aditi supports the full structured data
  3333.         capability of Prolog.  Base relations can store
  3334.         arbitrarily nested terms, for example arbitrary length
  3335.         lists, and rules can directly manipulate such terms.
  3336.         Base relations can be indexed with B-trees or
  3337.         multi-level signature files.  Users can access the
  3338.         system through a Motif-based query and database
  3339.         administration tool, or through a command line
  3340.         interface.  There is also in interface that allows
  3341.         NU-Prolog programs to access Aditi in a transparent
  3342.         manner.     Proper transaction processing is not supported
  3343.         in this release.
  3344. ports:        Sparc/SunOS4.1.2 Mips/Irix4.0
  3345. contact:    <aditi@cs.mu.oz.au>
  3346. updated:    1992/12/17
  3347.  
  3348. language:    Lambda-Prolog
  3349. package:    Prolog/Mali (PM)
  3350. version:    ? 6/23/92 ?
  3351. parts:        translator(C), linker, libraries, runtime, documentation
  3352. how to get:    ftp pm/* from ftp.irisa.fr
  3353. author:        Pascal Brisset <brisset@irisa.fr>
  3354. description:    Lambda-Prolog, a logic programming language defined by
  3355.         Miller, is an extension of Prolog where terms are
  3356.         simply typed $\lambda$terms and clauses are higher
  3357.         order hereditary Harrop formulas. The main novelties
  3358.         are universal quantification on goals and implication.
  3359. references:    + Miller D.A. and Nadathur G. "Higher-order logic 
  3360.         programming", 3rd International Conference on Logic 
  3361.         Programming, pp 448-462, London 1986.
  3362.         + Nadathur G. "A Higher-Order Logic as a Basis for Logic
  3363.         Programming", Thesis, University of Pennsylvania, 1987.     
  3364. requires:    MALI-V06 abstract memory. MALI is available by anonymous ftp 
  3365.         from ftp.irisa.fr
  3366. ports:        unix
  3367. discussion:    prolog-mali-request@irisa.fr
  3368. contact:    pm@irisa.fr
  3369. updated:    1992/07/06
  3370.  
  3371. language:    Prolog (variant)
  3372. package:    CORAL
  3373. version:    ?
  3374. parts:        interpreter, interface(C++), documentation
  3375. author:        ?
  3376. how to get:    ftp ? from ftp.cs.wisc.edu
  3377. description:    The CORAL deductive database/logic programming system was
  3378.         developed at the University of Wisconsin-Madison.  The CORAL
  3379.         declarative language is based on Horn-clause rules with
  3380.         extensions like SQL's group-by and aggregation operators, and
  3381.         uses a Prolog-like syntax.  * Many evaluation techniques are
  3382.         supported, including bottom-up fixpoint evaluation and top-down
  3383.         backtracking.  * A module mechanism is available.  Modules are
  3384.         separately compiled; different evaluation methods can be used
  3385.         in different modules within a single program.  * Disk-resident
  3386.         data is supported via an interface to the Exodus storage
  3387.         manager.  * There is an on-line help facility
  3388. requires:    AT&T C++ 2.0 (G++ soon)
  3389. ports:        Decstation, Sun4
  3390. updated:    1993/01/29
  3391.  
  3392. language:    Prolog
  3393. package:    BinProlog
  3394. version:    1.39
  3395. parts:        compiler?
  3396. how to get:    ftp BinProlog/* from clement.info.umoncton.ca
  3397. description:    ?
  3398. ports:        IBM-PC/386, Sun-4, Sun-3
  3399. contact:    Paul Tarau <tarau@info.umoncton.ca>
  3400. updated:    ?
  3401.  
  3402. language:    prolog
  3403. package:    SWI-Prolog
  3404. version:    1.6.12
  3405. author:        Jan Wielemaker <jan@swi.psy.uva.nl>
  3406. how to get:    ftp pub/SWI-Prolog from swi.psy.uva.nl 
  3407.     OS/2:    ftp pub/toolw/SWI/* from mpii02999.ag2.mpi-sb.mpg.de
  3408. conformance:    superset
  3409. features:    "very nice Ed. style prolog, best free one I've seen"
  3410. ports:        Sun-4, Sun-3 (complete); Linux, DEC MIPS (done but 
  3411.         incomplete, support needed); RS6000, PS2/AIX, Atari ST,
  3412.         Gould PN, NeXT, VAX, HP-UX (known problems, support needed);
  3413.         MSDOS (status unknown), OS/2
  3414. restriction:    GNU General Public License
  3415. status:        activly developed
  3416. discussion:    prolog-request@swi.psy.uva.nl
  3417. contact:    (OS/2) Andreas Toenne <atoenne@mpi-sb.mpg.de>
  3418. updated:    1993/03/05
  3419. -- 
  3420. Send compilers articles to compilers@iecc.cambridge.ma.us or
  3421. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  3422.  
  3423.  
  3424. From compilers Thu Apr  1 07:00:48 EST 1993
  3425. Xref: iecc comp.compilers:4463 comp.lang.misc:9658 comp.sources.d:4723 comp.archives.admin:883 news.answers:6794
  3426. Newsgroups: comp.compilers,comp.lang.misc,comp.sources.d,comp.archives.admin,news.answers
  3427. Path: iecc!compilers-sender
  3428. From: David Muir Sharnoff <muir@idiom.berkeley.ca.us>
  3429. Subject: Catalog of compilers, interpreters, and other language tools [p3of3]
  3430. Message-ID: <free3-Apr-93@comp.compilers>
  3431. Followup-To: comp.archives.admin
  3432. Summary: montly posting of free language tools that include source code
  3433. Keywords: tools, FTP, administrivia
  3434. Sender: compilers-sender@iecc.cambridge.ma.us
  3435. Supersedes: <free3-Mar-93@comp.compilers>
  3436. Reply-To: muir@idiom.berkeley.ca.us
  3437. Organization: University of California, Berkeley
  3438. References: <free2-Apr-93@comp.compilers>
  3439. Date: Thu, 1 Apr 1993 12:00:42 GMT
  3440. Approved: compilers@iecc.cambridge.ma.us
  3441. Expires: Sat, 1 May 1993 23:59:00 GMT
  3442.  
  3443. Archive-name: free-compilers/part3
  3444. Last-modified: 1993/03/24
  3445. Version: 3.2
  3446.  
  3447.  
  3448. language:    Prolog
  3449. package:    Frolic
  3450. version:    ?
  3451. how to get:    ftp pub/frolic.tar.Z from cs.utah.edu
  3452. requires:    Common Lisp
  3453. contact:    ?
  3454. updated:    1991/11/23
  3455.  
  3456. language:    Prolog
  3457. package:    ? Prolog package from the University of Calgary ?
  3458. version:    ?
  3459. how to get:    ftp pub/prolog1.1/prolog11.tar.Z from cpsc.ucalgary.ca
  3460. description:    + delayed goals
  3461.         + interval arithmetic
  3462. requires:    Scheme
  3463. portability:    reliese on continuations
  3464. contact:    ?
  3465. updated:    ?
  3466.  
  3467. language:    Prolog
  3468. package:    ? slog ?
  3469. version:    ?
  3470. parts:        translator(Prolog->Scheme)
  3471. author:        dorai@cs.rice.edu
  3472. how to get:    ftp public/slog.sh from titan.rice.edu
  3473. description:    macros expand syntax for clauses, elations etc, into Scheme
  3474. ports:        Chez Scheme
  3475. portability:    reliese on continuations
  3476. updated:    ?
  3477.  
  3478. language:    Prolog
  3479. package:    LM-PROLOG
  3480. version:    ?
  3481. parts:        ?
  3482. author:        Ken Kahn and Mats Carlsson
  3483. how to get:    ftp archives/lm-prolog.tar.Z from sics.se
  3484. requires:    ZetaLisp
  3485. contact:    ?
  3486. updated:    ?
  3487.  
  3488. language:    Prolog
  3489. package:    Open Prolog
  3490. version:    ?
  3491. parts:        ?
  3492. host to get:    ftp languages/open-prolog/* from grattan.cs.tcd.ie
  3493. description:    ?
  3494. ports:        Macintosh
  3495. contact:    Michael Brady <brady@cs.tcd.ie>
  3496. updated:    ?
  3497.  
  3498. language:    Prolog
  3499. package:    UPMAIL Tricia Prolog
  3500. version:    ?
  3501. parts:        ?
  3502. how to get:    ftp pub/Tricia/README from ftp.csd.uu.se
  3503. description:    ?
  3504. contact:    <tricia-request@csd.uu.se>
  3505. updated:    ?
  3506.  
  3507. language:    Prolog
  3508. package:    ?; ? (two systems)
  3509. version:    ?; ?
  3510. parts:        ?; ?
  3511. how to get:    ftp ai.prolog/Contents from aisun1.ai.uga.edu
  3512. description:    ?; ?
  3513. contact:    Michael Covington <mcovingt@uga.cc.uga.edu>
  3514. ports:        MSDOS, Macintosh; MSDOS
  3515. updated:    ?; ?
  3516.  
  3517. language:    Prolog
  3518. package:    XWIP (X Window Interface for Prolog)
  3519. version:    0.6
  3520. parts:        library
  3521. how to get:    ftp contrib/xwip-0.6.tar.Z from export.lcs.mit.edu
  3522. description:    It is a package for Prologs following the Quintus foreign
  3523.         function interface (such as SICStus). It provides a (low-level)
  3524.         Xlib style interface to X. The current version was developed
  3525.         and tested on SICStus 0.7 and MIT X11 R5 under SunOS 4.1.1.
  3526. portability:    It is adaptable to many other UNIX configurations.
  3527. contact:    xwip@cs.ucla.edu
  3528. updated:    1993/02/25
  3529.  
  3530. language:    Prolog
  3531. package:    PI
  3532. version:    ?
  3533. parts:        library
  3534. how to get:    ftp pub/prolog/ytoolkit.tar.Z from ftp.ncc.up.pt
  3535. description:    PI is a interface between Prolog applications and XWindows that
  3536.         aims to be independent from the Prolog engine, provided that it
  3537.         has a Quintus foreign function interface (such as SICStus,
  3538.         YAP).  It is mostly written in Prolog and is divided in two
  3539.         libraries: Edipo - the lower level interface to the Xlib
  3540.         functions; and Ytoolkit - the higher level user interface
  3541.         toolkit
  3542. contact:    Ze' Paulo Leal <zp@ncc.up.pt>
  3543. updated:    1993/03/02
  3544.  
  3545. language:    Prolog
  3546. package:    ISO draft standard
  3547. parts:        language definition
  3548. how to get:    ftp ? from ftp.th-darmstadt.de
  3549. updated:    1992/07/06
  3550.  
  3551. langauge:    BABYLON (Prolog variant???)
  3552. package:    BABYLON
  3553. version:    ?
  3554. parts:        development environment
  3555. how to get:    ftp gmd/ai-research/Software/* from gmdzi.gmd.de
  3556. description:    BABYLON is a development environment for expert systems. It
  3557.         includes frames, constraints, a prolog-like logic formalism, 
  3558.         and a description language for diagnostic applications. 
  3559. requires:    Common Lisp
  3560. ports:        many ?
  3561. contact:    ?
  3562. updated:    ?
  3563.  
  3564. language:    Python
  3565. package:    Python
  3566. version:    0.9.8
  3567. parts:        interpeter, libraries, documentation, emacs macros
  3568. how to get:    ftp pub/python* from ftp.cwi.nl
  3569.     america:    ftp pub/? from wuarchive.wustl.edu
  3570. author:        Guido van Rossum <guido@cwi.nl>
  3571. description:    Python is a simple, yet powerful programming language
  3572.         that bridges the gap between C and shell programming,
  3573.         and is thus ideally suited for rapid prototyping.  Its
  3574.         syntax is put together from constructs borrowed from a
  3575.         variety of other languages; most prominent are
  3576.         influences from ABC, C, Modula-3 and Icon.  Python is
  3577.         object oriented and is suitable for fairly large programs.
  3578.         + packages
  3579.         + exceptions
  3580.         + good C interface
  3581.         + dynamic loading of C modules
  3582.         - arbitrary restrictions
  3583. discussion:    python-list-request@cwi.nl
  3584. ports:        unix and Macintosh
  3585. updated:    1993/01/09
  3586.  
  3587. language:    Ratfor
  3588. package:    ? ratfor ?
  3589. version:    ?
  3590. parts:        translator(Ratfor->Fortran IV)
  3591. author:        Brian Kernighan and P.J. Plauger (wrote the book anyway)
  3592. how to get:    comp.sources.unix archives volume 13
  3593. description:    Ratfor is a front end langauge for Fortran.  It was designed
  3594.         to give structured control structures to Fortran.  It is
  3595.         mainly of historical significance.
  3596. updated:    ?
  3597.  
  3598. language:    Y (cross between C and Ratfor)
  3599. package:    y+po
  3600. version:    ?
  3601. parts:        compiler
  3602. author:        Jack W. Davidson and Christopher W. Fraser
  3603. how to get:    ftp pub/y+po.tar.Z from ftp.cs.princeton.edu
  3604. description:    Davidson/Fraser peephole optimizer PO [1-3] [where the GCC RTL
  3605.         idea and other optimization ideas came from] along with the Y
  3606.         compiler [cross between C+ratfor] is ftpable from
  3607.         ftp.cs.princeton.edu: /pub/y+po.tar.Z.  It is a copy of the
  3608.         original distribution from the University of Arizona during the
  3609.         early 80's, totally unsupported, almost forgotten [do not bug
  3610.         the authors] old code, possibly of interest to
  3611.         compiler/language hackers.
  3612. references:    Jack W. Davidson and Christopher W. Fraser, "The Design and
  3613.         Application of a Retargetable Peephole Optimizer", TOPLAS, Apr.
  3614.         1980.
  3615.         Jack W. Davidson, "Simplifying Code Through Peephole
  3616.         Optimization" Technical Report TR81-19, The University of
  3617.         Arizona, Tucson, AZ, 1981.
  3618.         Jack W. Davidson and Christopher W. Fraser, "Register
  3619.         Allocation and Exhaustive Peephole Optimization"
  3620.         Software-Practice and Experience, Sep. 1984.
  3621. status:        history
  3622.  
  3623. langauge:    Relation Grammar
  3624. package:    rl
  3625. version:    ?
  3626. how to get:    fto rl/* from flash.bellcore.com
  3627. author:        Kent Wittenburg <kentw@bellcore.com>
  3628. description:    The RL files contain code for defining Relational
  3629.         Grammars and using them in a bottom-up parser to
  3630.         recognize and/or parse expressions in Relational
  3631.         Languages.  The approach is a simplification of that
  3632.         described in Wittenburg, Weitzman, and Talley (1991),
  3633.         Unification-Based Grammars and Tabular Parsing for
  3634.         Graphical Languages, Journal of Visual Languages and
  3635.         Computing 2:347-370.
  3636.         This code is designed to support the definition and
  3637.         parsing of Relational Languages, which are
  3638.         characterized as sets of objects standing in
  3639.         user-defined relations.     Correctness and completeness
  3640.         is independent of the order in which the input is given
  3641.         to the parser.    Data to be parsed can be in many forms
  3642.         as long as an interface is supported for queries and
  3643.         predicates for the relations used in grammar
  3644.         productions.  To date, this software has been used to
  3645.         parse recursive pen-based input such as math
  3646.         expressions and flowcharts; to check for data integrity
  3647.         and design conformance in databases; to automatically
  3648.         generate constraints in drag-and-drop style graphical
  3649.         interfaces; and to generate graphical displays by
  3650.         parsing relational data and generating output code.
  3651. ports:        Allegro Common Lisp 4.1, Macintosh Common Lisp 2.0
  3652. requires:    Common Lisp
  3653. updated:    1992/10/31
  3654.  
  3655. language:    REXX
  3656. package:    Regina ?
  3657. version:    0.03d
  3658. author:        Anders Christensen <anders@pvv.unit.no>
  3659. how to get:    ftp andersrexx/rexx-0.03d.tar.Z from rexx.uwaterloo.ca
  3660.         or ftp ? from flipper.pvv.unit.no
  3661. ports:        unix
  3662. discussion:    comp.lang.rexx
  3663. updated:    ?
  3664.  
  3665. language:    REXX
  3666. package:    ?
  3667. version:    102
  3668. author:        ? al ? 
  3669. how to get:    ftp alrexx/rx102.tar.Z from rexx.uwaterloo.ca
  3670.         or ftp ? from tony.cat.syr.edu
  3671. requires:    C++
  3672. ports:        unix
  3673. discussion:    comp.lang.rexx
  3674. contact:    ?
  3675. updated:    1992/05/13
  3676.  
  3677. language:    REXX
  3678. package:    imc
  3679. version:    1.3
  3680. parts:        ?
  3681. how to get:    ftp pub/freerexx/imc/rexx-imc-1.3.tar.Z from rexx.uwaterloo.ca
  3682. ports:        SunOS
  3683. updated:    ?
  3684.  
  3685. language:    S/SL (Syntax Semantic Language)
  3686. package:    ssl
  3687. version:    ?
  3688. author:        Rick Holt, Jim Cordy <cordy@qucis.queensu.ca> (language), 
  3689.         Rayan Zachariassen <rayan@cs.toronto.edu> (C implementation)
  3690. parts:        parser bytecode compiler, runtime
  3691. how to get:    ftp pub/ssl.tar.Z from neat.cs.toronto.edu
  3692. description:    A better characterization is that S/SL is a language 
  3693.         explicitly designed for making efficient recusive-descent 
  3694.         parsers.  Unlike most other languages, practicially the 
  3695.         LEAST expensive thing you can do in S/SL is recur.  A
  3696.         small language that defines input/output/error token
  3697.         names (& values), semantic operations (which are really
  3698.         escapes to a programming language but allow good
  3699.         abstration in the pseudo-code), and a pseudo-code
  3700.         program that defines a grammar by the token stream the
  3701.         program accepts.  Alternation, control flow, and
  3702.         1-symbol lookahead constructs are part of the
  3703.         language.  What I call an S/SL "implementation", is a
  3704.         program that compiles this S/SL pseudo-code into a
  3705.         table (think byte-codes) that is interpreted by the
  3706.         S/SL table-walker (interpreter).  I think the pseudo-code 
  3707.         language is LR(1), and that the semantic mechanisms turn it
  3708.         into LR(N) relatively easily.
  3709.         + more powerful and cleaner than yac
  3710.         - slower than yacc
  3711. reference:    + Cordy, J.R. and Holt, R.C. [1980] Specification of S/SL:
  3712.         Syntax/Semantic Language, Computer Systems Research
  3713.         Institute, University of Toronto.  
  3714.         + "An Introduction to S/SL: Syntax/Semantic Language" by 
  3715.         R.C. Holt, J.R.     Cordy, and D.B. Wortman, in ACM Transactions 
  3716.         on Programming Languages and Systems (TOPLAS), Vol 4, No.
  3717.         2, April 1982, Pages 149-178.
  3718. updated:    1989/09/25
  3719.  
  3720. language:    Sather
  3721. package:    Sather programming language and environment
  3722. version:    0.2i
  3723. parts:        translator(C), debugger, libraries, documentation, emacs macros
  3724. author:        International Computer Science Institute in Berkeley, CA
  3725. how to get:    ftp pub/sather/sa-0.2i.tar.Z from ftp.icsi.berkeley.edu
  3726.     europe:    ftp pub/Sather/* from ftp.gmd.de
  3727.     aus:    ftp pub/sather/* from lynx.csis.dit.csiro.au
  3728.     japan:    ftp pub/lang/sather/* from sra.co.jp
  3729. conformance:    reference implemantation
  3730. description:    Sather is a new object-oriented computer language
  3731.         developed at the International Computer Science
  3732.         Institute. It is derived from Eiffel and attempts to
  3733.         retain much of that language's theoretical cleanliness
  3734.         and simplicity while achieving the efficiency of C++.
  3735.         It has clean and simple syntax, parameterized classes,
  3736.         object-oriented dispatch, multiple inheritance, strong
  3737.         typing, and garbage collection. The compiler generates
  3738.         efficient and portable C code which is easily
  3739.         integrated with existing code.    
  3740.     package:    A variety of development tools including a debugger and browser
  3741.         based on gdb and a GNU Emacs development environment
  3742.         have also been developed. There is also a class library
  3743.         with several hundred classes that implement a variety
  3744.         of basic data structures and numerical, geometric,
  3745.         connectionist, statistical, and graphical abstractions.
  3746.         We would like to encourage contributions to the library
  3747.         and hope to build a large collection of efficient,
  3748.         well-written, well-tested classes in a variety of areas
  3749.         of computer science.
  3750. ports:        Sun-4 HP9000/300 Decstation5000 MIPS SonyNews3000 Sequent/Dynix
  3751.         SCO SysVR3.2 NeXT (from others: RS6000 SGI)
  3752. portability:    high
  3753. discussion:    sather-request@icsi.berkeley.edu
  3754. bugs:        sather-admin@icsi.berkeley.edu
  3755. status:        actively developed.
  3756. updated:    1992/07/02
  3757.  
  3758. language:    Scheme
  3759. package:    Schematik
  3760. version:    1.1.5.2
  3761. parts:        programming environment
  3762. author:        Chris Kane, Max Hailperin <max@nic.gac.edu>
  3763. how to get:    ftp /pub/next/scheme/* from ftp.gac.edu
  3764.     europe:    ftp /pub/next/ProgLang from ftp.informatik.uni-muenchen.de
  3765. description:    Schematik is a NeXT front-end to MIT Scheme for
  3766.         the NeXT.  It provides syntax-knowledgeable text
  3767.         editing, graphics windows, and user-interface to
  3768.         an underlying MIT Scheme process. It comes packaged
  3769.         with MIT Scheme 7.1.3 ready to install on the NeXT.
  3770. ports:        NeXT, MIT Scheme 7.1.3
  3771. portability:    requires NeXTSTEP
  3772. contact:    schematik@gac.edu
  3773. updated:    1993/03/11
  3774.  
  3775. language:    Scheme
  3776. package:    T
  3777. version:    3.1
  3778. parts:        compiler
  3779. author:        ?
  3780. how to get:    ftp pub/systems/t3.1 from ftp.ai.mit.edu
  3781. description:    a Scheme-like language developed at Yale.  T is
  3782.         written in itself and compiles to efficient native
  3783.         code.
  3784.         (A multiprocessing version of T is available from
  3785.         masala.lcs.mit.edu:/pub/mult)
  3786. ports:        Decstation, Sparc, sun-3, Vax(unix), Encore, HP, Apollo,
  3787.         Mac (A/UX)
  3788. contact:    t-project@cs.yale.edu.
  3789. bugs:        t3-bugs@cs.yale.edu
  3790. updated:    1991/11/26
  3791.  
  3792. language:    Scheme
  3793. package:    scm
  3794. version:    4b4
  3795. parts:        interpreter, conformance test, documentation
  3796. author:        Aubrey Jaffer <jaffer@zurich.ai.mit.edu>
  3797. conformance:    superset of Revised^3.99 Report on the Algorithmic 
  3798.         Language Scheme and the IEEE P1178 specification.
  3799. how to get:    ftp archive/scm/* from altdorf.ai.mit.edu
  3800.     canada:    ftp pub/oz/scheme/new from nexus.yorku.ca
  3801. restriction:    GNU General Public License
  3802. contributions:    send $$$ to Aubrey Jaffer, 84 Pleasant St., Wakefield, MA 01880
  3803. ports:        unix, amiga, atari, mac, MSDOS, nos/ve, vms
  3804. updated:    1993/02/18
  3805.  
  3806. language:    Scheme
  3807. package:    Scheme Library (slib)
  3808. version:    1d0
  3809. parts:        library, documentation
  3810. how to get:    ftp archive/scm/slib1b*.tar.Z from altdorf.ai.mit.edu
  3811. description:    SLIB is a portable scheme library meant to provide 
  3812.         compatibiliy and utility functions for all standard scheme 
  3813.         implementations.
  3814. ports:        Scm4b, Chez, ELK 1.5, GAMBIT, MITScheme, Scheme->C, 
  3815.         Scheme48, T3.1.
  3816. status:        actively developed
  3817. contact:    Aubrey Jaffer <jaffer@zurich.ai.mit.edu>
  3818. updated:    1993/03/03
  3819.  
  3820. language:    Scheme
  3821. package:    Hobbit
  3822. version:    release 1
  3823. parts:        translator(->C), documentation
  3824. author:        Tanel Tammet <tammet@cs.chalmers.se>
  3825. how to get:    ftp archive/scm/hobbit1.tar.Z from altdorf.ai.mit.edu
  3826. description:    The main aim of hobbit is to produce maximally fast C programs
  3827.         which would retain most of the original Scheme program
  3828.         structure, making the output C program readable and modifiable.
  3829.         Hobbit is written in Scheme and is able to self-compile.
  3830.         Hobbit release 1 works together with the scm release scm4b3. 
  3831.         Future releases of scm and hobbit will be coordinated.
  3832. requires:    scm 4b3
  3833. updated:    1993/02/07
  3834.  
  3835. language:    Scheme
  3836. package:    siod (Scheme In One Day, or Scheme In One Defun)
  3837. version:    2.9
  3838. author:        George Carrette <gjc@paradigm.com>
  3839. how to get:    ftp src/lisp/siod-v2.8-shar from world.std.com
  3840. description:    Small scheme implementation in C arranged as a set of
  3841.         subroutines that can be called from any main program
  3842.         for the purpose of introducing an interpreted extension
  3843.         language.  Compiles to ~20K bytes of executable.  Lisp
  3844.         calls C and C calls Lisp transparently.
  3845. ports:        VAX/VMS, VAX UNIX, Sun3, Sun4, Amiga, Macintosh, MIPS, Cray
  3846. updated:    1992/09/01
  3847.  
  3848. language:    Scheme
  3849. package:    MIT Scheme (aka C-Scheme)
  3850. version:    7.2
  3851. parts:        interpreter, large runtime library, emacs macros, 
  3852.         native-code compiler, emacs-like editor, source-level debugger
  3853. author:        MIT Scheme Team (primarily Chris Hanson, Jim Miller, and
  3854.         Bill Rozas, but also many others)
  3855. how to get:    ftp archive/scheme-7.2 from altdorf.ai.mit.edu 
  3856.         DOS floppies ($95) and Unix tar tapes ($200) from 
  3857.         Scheme Team / c/o Prof. Hal Abelson / MIT AI Laboratory /
  3858.         545 Technology Sq. / Cambridge, MA 02139
  3859. description:    Scheme implementation with rich set of utilities.
  3860. conformance:    full compatibility with Revised^4 Report on Scheme, 
  3861.         one known incompatibility with IEEE Scheme standard
  3862. ports:        68k (hp9000, sun3, NeXT), MIPS (Decstation, Sony, SGI), 
  3863.         HP-PA (600, 700, 800), Vax (Ultrix, BSD), Alpha (OSF), 
  3864.         i386 (DOS/Windows, various Unix)
  3865. bugs:        bug-cscheme@zurich.ai.mit.edu
  3866. discussion:    info-cscheme@zurich.ai.mit.edu 
  3867.         (cross-posted to comp.lang.scheme.c)
  3868. status:        activly developed
  3869. updated:    1992/08/24
  3870.  
  3871. language:    Scheme
  3872. package:    Scheme->C
  3873. version:    15mar93
  3874. parts:        translator(C)
  3875. author:        Digital Western Research Laboratory; Joel Bartlett
  3876. how to get:    ftp pub/DEC/Scheme-to-C/* from gatekeeper.dec.com
  3877. description:    Translates Revised**4 Scheme to C that is then compiled
  3878.         by the native C compiler for the target machine.  This
  3879.         design results in a portable system that allows either
  3880.         stand-alone Scheme programs or programs written in both
  3881.         compiled and interpreted Scheme and other languages.
  3882. documentation:    send Subject "help" to WRL-Techreports@decwrl.dec.com
  3883.         for technical report.  Other documentation in
  3884.         Scheme-to-C directory on gatekeeper.
  3885. conformance:    superset of Revised**4
  3886.         + "expansion passing style" macros
  3887.         + foreign function call capability
  3888.         + interfaces to Xlib (Ezd & Scix)
  3889.         + records
  3890. ports:        VAX/ULTRIX, DECstation ULTRIX, Alpha AXP OSF/1,
  3891.         Microsoft Windows 3.1, Apple Macintosh 7.1,
  3892.         HP 9000/300, HP 9000/700, Sony News, SGI Iris and
  3893.         Harris Nighthawk and other UNIX-like m88k systems.
  3894.         The 01nov91 version is also available on Amiga, SunOS,
  3895.         NeXT, and Apollo systems.
  3896. status:        actively developed, contributed ports welcomed
  3897. updated:    1993/03/15
  3898.  
  3899. language:    Scheme
  3900. package:    PC-Scheme
  3901. version:    3.03
  3902. parts:        compiler, debugger, profiler, editor, libraries
  3903. author:        Texas Instruments
  3904. how to get:    ftp archive/pc-scheme/* from altdorf.ai.mit.edu
  3905. description:    Written by Texas Instruments. Runs on MS-DOS 286/386 IBM PCs
  3906.         and compatibles.  Includes an optimizing compiler, an
  3907.         emacs-like editor, inspector, debugger, performance testing,
  3908.         foreign function interface, window system and an
  3909.         object-oriented subsystem.  Also supports the dialect used in
  3910.         Abelson and Sussman's SICP.  
  3911. conformance:    Revised^3 Report, also supports dialect used in SICP.
  3912. ports:        MSDOS
  3913. restriction:    official version is $95, contact rww@ibuki.com
  3914. updated:    1992/02/23
  3915.  
  3916. language:    Scheme
  3917. package:    PCS/Geneva
  3918. version;    ?
  3919. parts:        compiler, debugger, profiler, editor, libraries
  3920. how to get:    send email to schemege@uni2a.unige.ch
  3921. description:    PCS/Geneva is a cleaned-up version of Texas Instrument's PC
  3922.         Scheme developed at the University of Geneva. The main
  3923.         extensions to PC Scheme are 486 support, BGI graphics, LIM-EMS
  3924.         pagination support, line editing, and assmebly-level
  3925.         interfacing.
  3926. contact:    schemege@uni2a.unige.ch
  3927. updated:    ?
  3928.  
  3929. language:    Scheme
  3930. package:    Gambit Scheme System
  3931. version:    1.8.2
  3932. parts:        interpreter, compiler, linker
  3933. author:        Marc Feeley <feeley@iro.umontreal.ca>
  3934. how to get:    ftp pub/gambit1.7.1/* from trex.iro.umontreal.ca
  3935. description:    Gambit is an optimizing Scheme compiler/system.
  3936. conformance:    IEEE Scheme standard and `future' construct.
  3937. restriction:    Mac version of compiler & source costs $40.
  3938. ports:        68k: unix, sun3, hp300, bbn gp100, NeXT, Macintosh
  3939. updated:    1992/07/01
  3940.  
  3941. language:    Scheme
  3942. package:    Elk (Extension Language Kit)
  3943. version:    2.0
  3944. parts:        interpreter
  3945. how to get:    ftp pub/elk/elk-2.0.tar.Z from tub.cs.tu-berlin.de
  3946.     usa:    ftp contrib/elk-2.0.tar.Z from export.lcs.mit.edu
  3947. author:        Oliver Laumann <net@cs.tu-berlin.de>, Carsten Bormann
  3948.         <cabo@cs.tu-berlin.de> ?
  3949. description:    Elk is a Scheme interpreter designed to be used as a 
  3950.         general extension language.
  3951.         + interfaces to Xlib, Xt, and various widget sets.
  3952.         + dynamic loading of extensions
  3953.         + almost all artificial limitations removed
  3954. conformance:    Mostly R3RS compatable.
  3955. ports:        unix, ultrix, vax, sun3, sun4, 68k, i386, mips, ibm rt, 
  3956.         rs6000, hp700, sgi, sony
  3957. updated:    1992/11/30
  3958.  
  3959. language:    Scheme
  3960. package:    XScheme
  3961. version:    0.28
  3962. parts:        ?
  3963. author:        David Betz <dbetz@apple.com>
  3964. how to get:    ftp pub/scheme/* from nexus.yorku.ca
  3965. description:    ?
  3966. discussion:    comp.lang.lisp.x
  3967. contact:    ?
  3968. updated:    1992/02/02
  3969.  
  3970. language:    Scheme
  3971. package:    Fools' Lisp
  3972. version:    1.3.2
  3973. author:        Jonathan Lee <jonathan@scam.berkeley.edu>
  3974. how to get:    ftp src/local/fools.tar.Z from scam.berkeley.edu
  3975. description:    a small Scheme interpreter that is R4RS conformant.
  3976. ports:        Sun-3, Sun-4, Decstation, Vax (ultrix), Sequent, Apollo
  3977. updated:    1991/10/31
  3978.  
  3979. language:    Scheme
  3980. package:    Scheme84
  3981. version:    ?
  3982. parts:        ?
  3983. how to get:    Send a tape w/return postage to: Scheme84 Distribution /
  3984.         Nancy Garrett / c/o Dan Friedman / Department of Computer
  3985.         Science / Indiana University / Bloomington, Indiana.  Call
  3986.         1-812-335-9770.
  3987. description:    ?
  3988. requires:    VAX, Franz Lisp, VMS or BSD
  3989. contact:    nlg@indiana.edu
  3990. updated:    ?
  3991.  
  3992. language:    Scheme
  3993. package:    Scheme88
  3994. version:    ?
  3995. parts:        ?
  3996. how to get:    ftp pub/scheme/* from nexus.yorku.ca
  3997. contact:    ?
  3998. updated:    ?
  3999.  
  4000. language:    Scheme
  4001. package:    UMB Scheme
  4002. version:    ?
  4003. parts:        ?, editor, debugger
  4004. author:        William Campbell <bill@cs.umb.edu>
  4005. how to get:    ftp pub/scheme/* from nexus.yorku.ca
  4006. conformance:    R4RS Scheme
  4007. ports:        ?
  4008. updated:    ?
  4009.  
  4010. language:    Scheme
  4011. package:    PseudoScheme
  4012. version:    2.8
  4013. parts:        translator(Common Lisp)
  4014. author:        Jonathan Rees <jar@cs.cornell.edu>
  4015. conformance:    R3RS except call/cc.
  4016. requires:    Common Lisp
  4017. ports:        Lucid, Symbolics CL, VAX Lisp, Explorer CL
  4018. announcements:    info-clscheme-request@mc.lcs.mit.edu
  4019. updated:    ?
  4020.  
  4021. language:    Scheme
  4022. package:    Similix
  4023. version:    ?
  4024. parts:        partial evaulator, debugger
  4025. how to get:    ftp misc/Similix.tar.Z from ftp.diku.dk
  4026. description:    Similix is an autoprojector (self-applicable partial 
  4027.         evaluator) for a higher order subset of the strict functional 
  4028.         language Scheme.  Similix handles programs with user defined 
  4029.         primitive abstract data type operators which may process 
  4030.         global variables (such as input/output operators).
  4031. conformance:    subset
  4032. contact:    Anders Bondorf <anders@diku.dk>
  4033. requires:    Scheme
  4034. ports:        Chez Scheme, T
  4035. updated:    1991/09/09
  4036.  
  4037. language:    Scheme
  4038. package:    ? syntax-case ?
  4039. version:    2.1
  4040. parts:        macro system, documentation
  4041. how to get:    ftp pub/scheme/syntax-case.tar.Z from iuvax.cs.indiana.edu
  4042. author:        R. Kent Dybvig <dyb@cs.indiana.edu>
  4043. description:    We have designed and implemented a macro system that is
  4044.         vastly superior to the low-level system described in
  4045.         the Revised^4 Report; in fact, it essentially
  4046.         eliminates the low level altogether.  We also believe
  4047.         it to be superior to the other proposed low-level
  4048.         systems as well, but each of you can judge that for
  4049.         yourself.  We have accomplished this by "lowering the
  4050.         level" of the high-level system slightly, making
  4051.         pattern variables ordinary identifiers with essentially
  4052.         the same status as lexical variable names and macro
  4053.         keywords, and by making "syntax" recognize and handle
  4054.         references to pattern variables.
  4055. references:    + Robert Hieb, R. Kent Dybvig, and Carl Bruggeman "Syntactic
  4056.         Abstraction in Scheme", IUCS TR #355, 6/92 (revised 7/3/92)
  4057.         + R. Kent Dybvig, "Writing Hygienic Macros in Scheme with
  4058.         Syntax-Case", IUCS TR #356, 6/92 (revised 7/3/92).
  4059. ports:        Chez Scheme
  4060. updated:    1992/07/06
  4061.  
  4062. language:    Scheme
  4063. package:    x-scm
  4064. version:    ?
  4065. parts:        ?
  4066. author:        Larry Campbell <campbell@redsox.bsw.com>
  4067. how to get:    alt.sources archive
  4068. description:    x-scm is a bolt-on accessory for the "scm" Scheme interpreter 
  4069.         that provides a handy environment for building Motif and 
  4070.         OpenLook applications.    (There is some support as well for raw 
  4071.         Xlib applications, but not enough yet to be useful.)
  4072. requires:    scm, X
  4073. ports:        ?
  4074. updated:    1992/08/10
  4075.  
  4076. language:    Scheme, Prolog
  4077. package:    "Paradigms of AI Programming"
  4078. version:    ?
  4079. parts:        book with interpreters and compilers in Common Lisp
  4080. author:        Peter Norvig
  4081. how to get:    bookstore, and ftp pub/norvig/* from unix.sri.com
  4082. updated:    ?
  4083.  
  4084. language:    Scheme
  4085. package:    PSD (Portable Scheme Debugger)
  4086. version:    1.0
  4087. parts:        debugger
  4088. author:        Kellom{ki Pertti <pk@cs.tut.fi>
  4089. how to get:    ftp /pub/src/languages/schemes/psd.tar.Z from cs.tut.fi
  4090. description:    source code debugging from emacs
  4091. requires:    R4RS compliant Scheme, GNU Emacs.
  4092. restriction:    GNU GPL
  4093. updated:    1992/07/10
  4094.  
  4095. language:    Scheme
  4096. package:    Tiny Clos
  4097. version:    first release
  4098. how to get:    ftp pub/mops/* from parcftp.xerox.com
  4099. description:    A core part of CLOS (Common Lisp Object System) ported to
  4100.         Scheme and rebuilt using a MOP (Metaobject Protocol).
  4101.         This should be interesting to those who want to use MOPs
  4102.         without using a full Common Lisp or Dylan.
  4103. ports:        MIT Scheme 11.74
  4104. discussion:    mailing list: mops, administered by gregor@parc.xerox.com
  4105. contact:    Gregor Kiczales <gregor@parc.xerox.com>
  4106. updated:    1992/12/14
  4107.  
  4108. langauge:    Scheme
  4109. package:    VSCM
  4110. version:    93Jan26
  4111. parts:        runtime, bytecode compiler
  4112. author:        Matthias Blume <blume@kastle.Princeton.EDU> ?
  4113. how to get:    ftp pub/scheme/imp/vscm93Jan26.tar.Z from nexus.yorku.cs
  4114. description:    VSCM is an implementation of Scheme based on a virtual machine
  4115.         written in ANSI C.
  4116. conformance:    conforms to the R4RS report except non-integral number types
  4117. portability:    very high
  4118. udated:        1993/01/26
  4119.  
  4120. language:    Scheme
  4121. package:    PSI
  4122. version:    pre-release
  4123. parts:        interpreter, virtual machine
  4124. author:        Ozan Yigit <oz@ursa.sis.yorku.ca>, David Keldsen, Pontus Hedman
  4125. how to get:    from author
  4126. description:    I am looking for a few interested language hackers to play with
  4127.         and comment on a scheme interpreter. I would prefer those who
  4128.         have been hacking portable [non-scheme] interpreters for many
  4129.         years.    The interpreter is PSI, a portable scheme interpreter
  4130.         that includes a simple dag compiler and a virtual machine.  It
  4131.         can be used as an integrated extension interpreter in other
  4132.         systems, allows for easy addition of new primitives, and it
  4133.         embodies some other interesting ideas. There are some unique[2]
  4134.         code debug/trace facilities, as well, acceptable performance
  4135.         resulting from a fairly straight-forward implementation.
  4136.         Continuations are fully and portably supported, and perform
  4137.         well.  PSI is based on the simple compilers/vm in Kent 
  4138.         Dbyvig's thesis.
  4139. compliance:    R^4RS compatible with a number of useful extensions.
  4140. updated:    1993/02/19
  4141.  
  4142. language:    sed
  4143. package:    GNU sed
  4144. version:    1.11
  4145. parts:        interpreter, ?
  4146. author:        ?
  4147. how to get:    ftp sed-1.11.tar.z from a GNU archive site
  4148. contact:    ?
  4149. updated:    1992/05/31
  4150.  
  4151. language:    Self
  4152. package:    Self
  4153. version:    2.0
  4154. parts:        ?, compiler?, debugger, browser
  4155. author:        The Self Group at Sun Microsystems & Stanford University
  4156. how to get:    ftp ? from self.stanford.edu
  4157.         The Self Group at Sun Microsystems Laboratories,
  4158.         Inc., and Stanford University is pleased to announce
  4159.         Release 2.0 of the experimental object-oriented
  4160.         exploratory programming language Self.
  4161.         Release 2.0 introduces full source-level debugging
  4162.         of optimized code, adaptive optimization to shorten
  4163.         compile pauses, lightweight threads within Self,
  4164.         support for dynamically linking foreign functions,
  4165.         changing programs within Self, and the ability to
  4166.         run the experimental Self graphical browser under
  4167.         OpenWindows.
  4168.         Designed for expressive power and malleability,
  4169.         Self combines a pure, prototype-based object model
  4170.         with uniform access to state and behavior. Unlike
  4171.         other languages, Self allows objects to inherit
  4172.         state and to change their patterns of inheritance
  4173.         dynamically. Self's customizing compiler can generate
  4174.         very efficient code compared to other dynamically-typed
  4175.         object-oriented languages.
  4176. discussion:    self-request@self.stanford.edu
  4177. ports:        Sun-3 (no optimizer), Sun-4
  4178. contact:    ?
  4179. updated:    1992/08/13
  4180.  
  4181. language:    SGML (Standardized Generalized Markup Language)
  4182. package:    sgmls
  4183. version:    1.1
  4184. parts:        parser
  4185. author:        James Clark <jjc@jclark.com> and Charles Goldfarb
  4186. how to get:    ftp pub/text-processing/sgml/sgmls-1.0.tar.Z from ftp.uu.net
  4187.     uk:        ftp sgmls/sgmls-1.1.tar.Z from ftp.jclark.com
  4188. description:    SGML is a markup language standardized in ISO 8879.
  4189.         Sgmls is an SGML parser derived from the ARCSGML
  4190.         parser materials which were written by Charles
  4191.         Goldfarb.  It outputs a simple, easily parsed, line
  4192.         oriented, ASCII representation of an SGML document's
  4193.         Element Structure Information Set (see pp 588-593
  4194.         of ``The SGML Handbook'').  It is intended to be
  4195.         used as the front end for structure-controlled SGML
  4196.         applications.  SGML is an important move in the
  4197.         direction of separating information from its
  4198.         presentation, i.e. making different presentations
  4199.         possible for the same information.
  4200. bugs:        James Clark <jjc@jclark.com>
  4201. ports:        unix, msdos
  4202. updated:    1993/02/22
  4203.  
  4204. language:    Korn Shell
  4205. package:    SKsh
  4206. version:    2.1
  4207. author:        Steve Koren <koren@hpfcogv.fc.hp.com>
  4208. parts:        interpreter, utilities
  4209. how to get:    ftp pub/amiga/incom*/utils/SKsh021.lzh from hubcap.clemson.edu
  4210. description:    SKsh is a Unix ksh-like shell which runs under AmigaDos.
  4211.         it provides a Unix like environment but supports many
  4212.         AmigaDos features such as resident commands, ARexx, etc.
  4213.         Scripts can be written to run under either ksh or SKsh,
  4214.         and many of the useful Unix commands such as xargs, grep,
  4215.         find, etc. are provided.
  4216. ports:        Amiga
  4217. updated:    1992/12/16
  4218.  
  4219. language:    Korn Shell 
  4220. package:    bash (Bourne Again SHell)
  4221. version:    1.12
  4222. parts:        parser(yacc), interpreter, documentation
  4223. how to get:    ftp bash-1.12.tar.Z from a GNU archive site
  4224. author:        Brian Fox <bfox@vision.ucsb.edu>
  4225. description:     Bash is a Posix compatable shell with full Bourne shell syntax,
  4226.         and some C-shell commands built in.  The Bourne Again Shell
  4227.         supports emacs-style command-line editing, job control,
  4228.         functions, and on-line help.  
  4229. restriction:    GNU General Public License
  4230. bugs:        gnu.bash.bug
  4231. updated:    1992/01/28
  4232.  
  4233. language:    Korn Shell
  4234. package:    pd-ksh
  4235. version:    4.8
  4236. author:        Simon J. Gerraty <sjg@zen.void.oz.au>
  4237. how to get:    ?
  4238. description:    ?
  4239. contact:    Simon J Gerraty <sjg@melb.bull.oz.au> (zen.void.oz.au is down)
  4240. updated:    ?
  4241.  
  4242. language:    csh (C-Shell)
  4243. package:    tcsh
  4244. version:    6.03
  4245. parts:        interpreter
  4246. author:        Christos Zoulas <christos@ee.cornell.edu>
  4247. how to get:    ftp ? from ftp.spc.edu
  4248. description:    a modified C-Shell with history editing
  4249. ports:        unix, OpenVMS
  4250. updated:    1992/12/16
  4251.  
  4252. language:    rc (Plan 9 shell)
  4253. package:    rc
  4254. version:    1.4
  4255. parts:        interpretor
  4256. author:        Byron Rakitzis <byron@netapp.com>
  4257. how to get:    comp.sources.misc volume 30; or ftp pub/shells/* from 
  4258.         ftp.white.toronto.edu
  4259. description:    a free implementation of the Plan 9 shell.
  4260. discussion:    rc-request@hawkwind.utcs.toronto.edu
  4261. updated:    1992/05/26
  4262.  
  4263. language:    es (a functional shell)
  4264. package:    es
  4265. version:    0.8
  4266. parts:        interpreter
  4267. author:        Byron Rakitzis <byron@netapp.com>, Paul Haahr <haahr@adobe.com>
  4268. how to get:    ftp ftp.white.toronto.edu:/pub/es/es-0.8.tar.Z
  4269. description:    shell with higher order functions
  4270. updated:    1993/03/22
  4271.  
  4272. language:    Simula
  4273. package:    Lund Simula
  4274. version:    4.07
  4275. author:        ?
  4276. how to get:    ftp misc/mac/programming/+_Simula/* from rascal.ics.utexas.edu
  4277. description:    ?
  4278. contact:    Lund Software House AB / Box 7056 / S-22007 Lund, Sweden
  4279. updated:    1992/05/22
  4280.  
  4281. language:    Simula
  4282. package:    Cim
  4283. version:    1.10
  4284. parts:        translator(->C), ?
  4285. author:        Sverre Johansen, Stenk Krogdahl and Terje Mjos
  4286. how to get:    ftp cim/* from ftp.ifi.uio.no 
  4287. description:    Cim is a compiler for the programming language Simula. 
  4288.         from Department of informatics, University of Oslo 
  4289.         It offers a class concept, separate compilation with 
  4290.         full type checking, interface to external C-routines,
  4291.         an application package for process simulation
  4292.         and a coroutine concept. 
  4293.         Cim is a Simula compiler whose portability is based on
  4294.         the C programming language. The compiler and the
  4295.         run-time system is written in C, and the compiler
  4296.         produces C-code, that is passed to a C-compiler for
  4297.         further processing towards machine code.
  4298. conformance:    except unspecified parameters to formal or virtual procedures
  4299. ports:          Vax (Ultrix,VMS), 68020/30 (SunOS,Next,HPUX), sparc (Sunos), 
  4300.         mips (SGI,Dec,CD), 9000s705 (HPUX), alpha (OSF/1), 
  4301.         m88k (Triton,Aviion), Apollo, Cray (YMP), Encore Multimax,
  4302.         9000s800 (HPUX), 386/486 (LINUX,SCO,Interactive),
  4303.         Atari (MINIX) and Comodore Amiga (AmigaDos), 
  4304. contact:    cim@ifi.uio.no
  4305. updated:    1993/02/25
  4306.  
  4307. language:    SISAL 1.2
  4308. package:    The Optimizing SISAL Compiler
  4309. version:    12.0
  4310. parts:        compiler?, manuals, documentation, examples, debugger,...
  4311. author:        David C. Cann <cann@sisal.llnl.gov>
  4312. how to get:    ftp pub/sisal from sisal.llnl.gov
  4313. description:    Sisal is a functional language designed to be competitive with
  4314.         Fortran, and other imperative languages for scientific jobs.  
  4315.         In particualar, OSC uses advanced optimizing techniques to 
  4316.         achieve fast speeds for computation intensive programs.  
  4317.         It also features routines for making efficient use
  4318.         of parallel processors, such as that on the Cray.
  4319. ports:        ?
  4320. updated:    ?
  4321.  
  4322. language:    Smalltalk
  4323. package:    Little Smalltalk
  4324. version:    3
  4325. author:        Tim Budd <budd@cs.orst.edu> ?
  4326. how to get:    ftp pub/budd/? from cs.orst.edu
  4327. ports:        unix, pc, atari, vms
  4328. status:        ?
  4329. updated:    ?
  4330.  
  4331. language:    Smalltalk
  4332. package:    GNU Smalltalk
  4333. version:    1.1.1
  4334. parts:        ?
  4335. author:        Steven Byrne <sbb@eng.sun.com>
  4336. how to get:    ftp smalltalk-1.1.1.tar.Z from a GNU archive site
  4337. description:    ?
  4338. discussion:    ?
  4339. bugs:        gnu.smalltalk.bug
  4340. contact:    ?
  4341. updated:    1991/09/15
  4342.  
  4343. language:    Smalltalk
  4344. package:    msgGUI
  4345. version:    1.0
  4346. parts:        library
  4347. author:        Mark Bush <bush@ecs.ox.ac.uk>
  4348. how to get:    ftp pub/Packages/mst/mstGUI-1.0.tar.Z from ftp.comlab.ox.ac.uk
  4349. description:    GUI for GNU Smalltalk.    This this package contains the basics 
  4350.         for creating window applications in the manner available in 
  4351.         other graphical based Smalltalk implementations.
  4352. updated:    1992/12/14
  4353.  
  4354. language:    Smalltalk
  4355. package:    Mei
  4356. version:    0.50
  4357. parts:        interpreters(Lisp,Prolog), examples, libraries, tools, editor,
  4358.         browser
  4359. author:        Atsushi Aoki <aoki@sra.co.jp> and others
  4360. how to get:    ftp pub/goodies/misc/Mei.tar.Z from mushroom.cs.man.ac.uk
  4361.     us:        ftp pub/MANCHESTER/misc/Mei from st.cs.uiuc.edu
  4362.     jp:        ftp pub/lang/smalltalk/mei/Mei0.50.tar.Z from srawgw.sra.co.jp
  4363. description:    Mei is a set of class libraries for Objectworks Smalltalk
  4364.         Release 4.1.  it includes:   1.     Grapher Library (useful for
  4365.         drawing diagrams);  2. Meta Grapher Library (grapher to develop
  4366.         grapher);  3. Drawing tools and painting tools (structured
  4367.         diagram editors and drawing editors);  4. GUI editor (graphical
  4368.         user interface builder);  5. Lisp interpreter;    6. Prolog
  4369.         interpreter;  7. Pluggable gauges;  8. Extended browser;
  4370.         (package, history, recover, etc.)
  4371. restriction:    GNU General Public License
  4372. requires:    Objectworks Smalltalk Release 4.1
  4373. contact:    Watanabe Katsuhiro <katsu@sran14.sra.co.jp>
  4374. updated:    1993/01/20
  4375.  
  4376. language:    Snobol4
  4377. package:    SIL (Macro Implementation of SNOBOL4)
  4378. version:    3.11
  4379. how to get:    ftp snobol4/* from cs.arizona.edu
  4380. contact:    snobol4@arizona.edu
  4381. updated:    1986/07/29
  4382.  
  4383. language:    Snobol4
  4384. package:    vinilla
  4385. version:    ?
  4386. author:        Catspaw, Inc.
  4387. how to get:    ftp snobol4/vanilla.arc from cs.arizona.edu
  4388. contact:    ?
  4389. ports:        MSDOS
  4390. updated:    1992/02/05
  4391.  
  4392. language:    SR (Synchronizing Resources)
  4393. package:    sr
  4394. version:    2.0 
  4395. parts:        ?, documentation, tests
  4396. how to get:    ftp sr/sr.tar.Z from cs.arizona.edu
  4397. description:    SR is a language for writing concurrent programs.
  4398.         The main language constructs are resources and
  4399.         operations.  Resources encapsulate processes and
  4400.         variables they share; operations provide the primary
  4401.         mechanism for process interaction.  SR provides a novel
  4402.         integration of the mechanisms for invoking and
  4403.         servicing operations.  Consequently, all of local and
  4404.         remote procedure call, rendezvous, message passing,
  4405.         dynamic process creation, multicast, and semaphores are
  4406.         supported.
  4407. reference:    "The SR Programming Language: Concurrency in Practice", 
  4408.         by Gregory R. Andrews and Ronald A. Olsson, Benjamin/Cummings 
  4409.         Publishing Company, 1993, ISBN 0-8053-0088-0
  4410. contact:    sr-project@cs.arizona.edu
  4411. discussion:    info-sr-request@cs.arizona.edu
  4412. ports:        Sun-4, Sun-3, Decstation, SGI Iris, HP PA, HP 9000/300,
  4413.         NeXT, Sequent Symmetry, DG AViiON, RS/6000, Multimax,
  4414.         Apollo, and others.
  4415. updated:    1992/09/01
  4416.  
  4417. language:    Standard ML
  4418. package:    SML/NJ (Standard ML of New Jersey)
  4419. version:    0.93
  4420. parts:        compiler, libraries, extensions, interfaces, documentation,
  4421.         build facility
  4422. author:        D. B. MacQueen <dbm@research.att.com>, Lal George 
  4423.         <george@research.att.com>, AJ. H. Reppy <jhr@research.att.com>,
  4424.         A. W. Appel <appel@princeton.edu>
  4425. how to get:    ftp dist/ml/* from research.att.com
  4426. description:    Standard ML is a modern, polymorphically typed, (impure)
  4427.         functional language with a module system that supports flexible
  4428.         yet secure large-scale programming.  Standard ML of New Jersey
  4429.         is an optimizing native-code compiler for Standard ML that is
  4430.         written in Standard ML.     It runs on a wide range of
  4431.         architectures.    The distribution also contains:
  4432.         + an extensive library - The Standard ML of New Jersey Library,
  4433.         including detailed documentation.
  4434.         + CML - Concurrent ML
  4435.         + eXene - an elegant interface to X11 (based on CML)
  4436.         + SourceGroup - a separate compilation and "make" facility
  4437. ports:        M68K, SPARC, MIPS, HPPA, RS/6000, I386/486
  4438. updated:    1993/02/18
  4439.  
  4440. language:    Concurrent ML
  4441. package:    Concurrent ML
  4442. version:    0.9.8
  4443. parts:        extension
  4444. how to get:    ftp pub/CML* from ftp.cs.cornell.edu or get SML/NJ
  4445. description:    Concurrent ML is a concurrent extension of SML/NJ, supporting
  4446.         dynamic thread creation, synchronous message passing on
  4447.         synchronous channels, and first-class synchronous operations.
  4448.         First-class synchronous operations allow users to tailor their
  4449.         synchronization abstractions for their application.  CML also
  4450.         supports both stream I/O and low-level I/O in an integrated
  4451.         fashion.
  4452. bugs:        sml-bugs@research.att.com
  4453. requires:    SML/NJ 0.75 (or later)
  4454. updated:    1993/02/18
  4455.  
  4456. language:    Standard ML
  4457. package:    sml2c
  4458. version:    ?
  4459. parts:        translator(C), documentation, tests
  4460. how to get:    ftp /usr/nemo/sml2c/sml2c.tar.Z from dravido.soar.cs.cmu.edu
  4461.     linux:    ftp pub/linux/smlnj-0.82-linux.tar.Z from ftp.dcs.glasgow.ac.uk
  4462. author:        School of Computer Science, Carnegie Mellon University 
  4463. conformance:    superset
  4464.         + first-class continuations,
  4465.         + asynchronous signal handling
  4466.         + separate compilation 
  4467.         + freeze and restart programs
  4468. history:    based on SML/NJ version 0.67 and shares front end and
  4469.         most of its runtime system.
  4470. description:    sml2c is a Standard ML to C compiler.  sml2c is a batch
  4471.         compiler and compiles only module-level declarations,
  4472.         i.e. signatures, structures and functors.  It provides
  4473.         the same pervasive environment for the compilation of
  4474.         these programs as SML/NJ.  As a result, module-level
  4475.         programs that run on SML/NJ can be compiled by sml2c
  4476.         without any changes.  It does not support SML/NJ style
  4477.         debugging and profiling.
  4478. ports:        IBM-RT Decstation3100 Omron-Luna-88k Sun-3 Sun-4 386(Mach)
  4479. portability:    easy, easier than SML/NJ
  4480. contact:    david.tarditi@cs.cmu.edu anurag.acharya@cs.cmu.edu 
  4481.         peter.lee@cs.cmu.edu
  4482. updated:    1991/06/27
  4483.  
  4484. langauge:    Standard ML
  4485. package:    The ML Kit
  4486. version:    1
  4487. parts:        interprter, documentation
  4488. author:        Nick Rothwell, David N. Turner, Mads Tofte <tofte@diku.dk>,
  4489.         and Lars Birkedal at Edinburgh and Copenhagen Universities.
  4490. how to get:    ftp diku/users/birkedal/* from ftp.diku.dk
  4491.     uk:        ftp export/ml/mlkit/* from lfcs.ed.ac.uk
  4492. description:    The ML Kit is a straight translation of the Definition of
  4493.         Standard ML into a collection of Standard ML modules.  For
  4494.         example, every inference rule in the Definition is translated
  4495.         into a small piece of Standard ML code which implements it. The
  4496.         translation has been done with as little originality as
  4497.         possible - even variable conventions from the Definition are
  4498.         carried straight over to the Kit.  The Kit is intended as a
  4499.         tool box for those people in the programming language community
  4500.         who may want a self-contained parser or type checker for full
  4501.         Standard ML but do not want to understand the clever bits of a
  4502.         high-performance compiler. We have tried to write simple code
  4503.         and modular interfaces.
  4504. updated:    1993/03/12
  4505.  
  4506. language:    TCL (Tool Command Language)
  4507. package:    TCL
  4508. version:    6.6
  4509. parts:        interpreter, libraries, tests, documentation
  4510. how to get:    ftp tcl/tcl6.6.tar.Z from sprite.berkeley.edu
  4511.     msdos:    ftp ? from cajal.uoregon.edu
  4512.     macintosh:    ftp pub/ticl from bric-a-brac.apple.com
  4513.     examples:    ftp tcl/* from barkley.berkeley.edu
  4514. author:        John Ousterhout <ouster@cs.berkeley.edu>
  4515. description:    TCL started out as a small language that could be
  4516.         embedded in applications.  It has now been extended
  4517.         into more of a general purpose shell type programming
  4518.         language.  TCL is like a text-oriented Lisp, but lets
  4519.         you write algebraic expressions for simplicity and to
  4520.         avoid scaring people away.
  4521.         + may be used as an embedded interpreter
  4522.         + exceptions, packages (called libraries)
  4523.         - only a single name-space
  4524.         + provide/require
  4525.         - no dynamic loading ability
  4526.         ? - arbitrary limits ?
  4527.         - three variable types: strings, lists, associative arrays
  4528. bugs:        ?
  4529. discussion:    comp.lang.tcl
  4530. ports:        ?
  4531. updated:    1993/02/23
  4532.  
  4533. language:    TCL
  4534. package:    BOS - The Basic Object System
  4535. version:    1.31
  4536. parts:        library
  4537. author:        Sean Levy <Sean.Levy@cs.cmu.edu>
  4538. how to get:    ftp tcl/? from barkley.berkeley.edu
  4539. description:    BOS is a C-callable library that implements the
  4540.         notion of object and which uses Tcl as its interpreter
  4541.         for interpreted methods (you can have "compiled"
  4542.         methods in C, and mix compiled and interpreted
  4543.         methods in the same object, plus lots more stuff).
  4544.         I regularly (a) subclass and (b) mixin existing
  4545.         objects using BOS to extend, among other things,
  4546.         the set of tk widgets (I have all tk widgets wrapped
  4547.         with BOS "classes"). BOS is a class-free object
  4548.         system, also called a prototype-based object system;
  4549.         it is modeled loosely on the Self system from
  4550.         Stanford.
  4551. updated:    1992/08/21
  4552.  
  4553. language:    TCL
  4554. package:    Wafe
  4555. version:    0.94
  4556. parts:        interface
  4557. author:        Gustaf Neumann <neumann@dec4.wu-wien.ac.at>
  4558. how to get:    ftp pub/src/X11/wafe/wafe-0.94.tar.Z from ftp.wu-wien.ac.at
  4559. description:    Wafe (Widget[Athena]front end) is a package that implements
  4560.         a symbolic interface to the Athena widgets (X11R5) and
  4561.         OSF/Motif.  A typical Wafe application consists of two
  4562.         parts: a front-end (Wafe) and an application program which
  4563.         runs typically as a separate process.  The distribution
  4564.         contains sample application programs in Perl, GAWK, Prolog,
  4565.         TCL, C and Ada talking to the same Wafe binary.
  4566. discussion:    send "subscribe Wafe <Your Name>" to listserv@wu-wien.ac.at
  4567. updated:    1993/02/13
  4568.  
  4569. language:    TCL
  4570. package:    Cygnus Tcl Tools
  4571. version:    Release-930124
  4572. author:        david d 'zoo' zuhn <zoo@cygnus.com>
  4573. how to get:    ftp pub/tcltools-* from cygnus.com
  4574. description:    A rebundling of Tcl and Tk into the Cyngus GNU build 
  4575.         framework with 'configure'.
  4576. updated:    1993/01/24
  4577.  
  4578. language:    Tiny
  4579. package:    Omega test, Extended Tiny
  4580. version:    3.0.0
  4581. parts:        translator(fortran->tiny), tiny interpreter?, analysis tools
  4582. author:        William Pugh <pugh@cs.umd.edu> and others
  4583. how to get:    ftp pub/omega from ftp.cs.umd.edu
  4584. description:    The Omega test is implemented in an extended version of
  4585.         Michael Wolfe's tiny tool, a research/educational tool
  4586.         for examining array data dependence algorithms and
  4587.         program transformations for scientific computations.
  4588.         The extended version of tiny can be used as a
  4589.         educational or research tool.  The Omega test: A system
  4590.         for performing symbolic manipulations of conjunctions
  4591.         of linear constraints over integer variables.  The
  4592.         Omega test dependence analyzer: A system built on top
  4593.         of the Omega test to analyze array data dependences.
  4594. contact:    omega@cs.umd.edu
  4595. updated:    1992/12/14
  4596.  
  4597. Language:    Extended Tiny
  4598. Package:    Extended Tiny
  4599. Version:    3.0 (Dec 12th, 1992)
  4600. parts:        programming environment, dependence tester, tests
  4601.         translator(Fortran->tiny), documentation, tech. reports
  4602. author:        original author: Michael Wolfe <cse.ogi.edu>,
  4603.         extended by William Pugh et al. <pugh@cs.umd.edu>
  4604. how to get:    ftp pub/omega from cs.umd.edu
  4605. description:    A research/educational tool for experimenting with
  4606.         array data dependence tests and reordering transformations.
  4607.         It works with a language tiny, which does not have procedures,
  4608.         goto's, pointers, or other features that complicate dependence
  4609.         testing. The original version of tiny was written by Michael
  4610.         Wolfe, and has been extended substantially by a research group
  4611.         at the University of Maryland. Michael Wolfe has made further
  4612.         extensions to his version of tiny.
  4613. contact:    Omega test research group <omega@cs.umd.edu>
  4614. ports:        Any unix system (xterm helpful but not required)
  4615. updated:    1993/01/23
  4616.  
  4617. language:    troff, nroff, eqn, tbl, pic, refer, Postscript, dvi
  4618. package:    groff
  4619. version:    1.07
  4620. parts:        document formatter, documentation
  4621. author:        James Clark <jjc@jclark.com>
  4622. how to get:    ftp groff-1.07.tar.z from a GNU archive site
  4623. description:    [An absolutely fabulous troff --muir]
  4624. restriction:    GNU General Public License
  4625. requires:    C++
  4626. updated:    1993/03/03
  4627.  
  4628. language:    UNITY
  4629. package:    MasPar Unity
  4630. version:    ?
  4631. parts:        ?
  4632. author:        ?
  4633. how to get:    ftp pub/maspar/maspar_unity* from SanFrancisco.ira.uka.de
  4634. contact:    Lutz Prechelt <prechelt@ira.uka.de> ?
  4635. updated:    ?
  4636.  
  4637. language:    UNITY
  4638. package:    HOL-UNITY
  4639. version:    2.1
  4640. parts:        verification tool
  4641. how to get:    ?
  4642. contact:    Flemming Andersen <fa@tfl.dk> ?
  4643.  
  4644. language:    Verilog, XNF
  4645. package:    XNF to Verilog Translator
  4646. version:    ?
  4647. parts:        translator(XNF->Verilog)
  4648. author:        M J Colley <martin@essex.ac.uk>
  4649. how to get:    ftp pub/dank/xnf2ver.tar.Z from punisher.caltech.edu
  4650. description:    This program was written by a postgraduate student as part
  4651.         of his M.Sc course, it was designed to form part a larger
  4652.         system operating with the Cadence Edge 2.1 framework. This
  4653.         should be bourne in mind when considering the construction
  4654.         and/or operation of the program.
  4655. updated:    ?
  4656.  
  4657. language:    VHDL
  4658. package:    ALLIANCE
  4659. version:    1.1
  4660. parts:        compiler, simulator, tools and environment, documentation
  4661. how to get:    ftp pub/cao-vlsi/alliance from ftp-masi.ibp.fr
  4662. description:    ALLIANCE 1.1 is a complete set of CAD tools for teaching
  4663.         Digital CMOS VLSI Design in Universities. It includes VHDL
  4664.         compiler and simulator, logic synthesis tools, automatic place
  4665.         and route, etc...  ALLIANCE is the result of a ten years effort
  4666.         at University Pierre et Marie Curie (PARIS VI, France).
  4667. ports:        Sun4, also not well supported: Mips/Ultrix, 386/SystemV
  4668. discussion:    alliance-request@masi.ibp.fr
  4669. contact:    cao-vlsi@masi.ibp.fr
  4670. updated:    1993/02/16
  4671.  
  4672. language:    Web
  4673. package:    web2c
  4674. version:    5-851d
  4675. parts:        translator(C)
  4676. how to get:    ftp TeX/web2c.tar.Z from ics.uci.edu
  4677.     de:        ftp pub/tex/src/web2c/web2c.tar.Z from ftp.th-darmstadt.de
  4678. description:    
  4679. contact:    Karl Berry <karl@claude.cs.umb.edu>
  4680. updated:    1993/02/22
  4681.  
  4682. language:    Web
  4683. package:    Web
  4684. version:    ?
  4685. parts:        translator(Pascal)
  4686. author:        Donald Knuth
  4687. how to get:    ftp ? from labrea.stanford.edu
  4688. description:    Donald Knuth's programming language where you
  4689.         write the source and documentation together.
  4690. contact:    ?
  4691. updated:    ?
  4692.  
  4693. -------------------------------------------------------------------------------
  4694. ------------------------------ archives ---------------------------------------
  4695. -------------------------------------------------------------------------------
  4696.  
  4697. language:    Ada
  4698. package:    AdaX
  4699. description:    an archive of X libraries for Ada.  Includes Motif
  4700.         [note, I chose this server out of many somewhat randomly.
  4701.         Use archie to find others --muir]
  4702. how to get:    ftp pub/AdaX/* from falcon.stars.rosslyn.unisys.com
  4703. contact:    ?
  4704.  
  4705. language:    APL, J
  4706. package:    APL, J, and other APL Software at Waterloo
  4707. how to get:    ftp languages/apl/index from watserv1.waterloo.edu
  4708. contact:    Leroy J. (Lee) Dickey <ljdickey@math.waterloo.edu>
  4709.  
  4710. language:    C, C++, Objective C, yacc, lex, postscript, 
  4711.         sh, awk, smalltalk, sed
  4712. package:    the GNU archive sites
  4713. description:    There are many sites which mirror the master gnu archives
  4714.         which live on prep.ai.mit.edu.    Please do not use 
  4715.         the master archive without good reason.
  4716. how to get:    ftp pub/gnu/* from prep.ai.mit.edu
  4717.     USA:    ftp mirrors4/gnu/* from wuarchive.wustl.edu
  4718.         ftp pub/src/gnu/* from ftp.cs.widener.edu
  4719.         ftp gnu/* from uxc.cso.uiuc.edu
  4720.         ftp mirrors/gnu/* from col.hp.com
  4721.         ftp pub/GNU/* from gatekeeper.dec.com
  4722.         ftp packages/gnu/* from ftp.uu.net
  4723.     Japan:    ftp ? from ftp.cs.titech.ac.jp
  4724.         ftp ftpsync/prep/* from utsun.s.u-tokyo.ac.jp
  4725.     Australia:    ftp gnu/* from archie.au
  4726.     Europe:    ftp gnu/* from src.doc.ic.ac.uk
  4727.         ftp pub/GNU/*/* from ftp.informatik.tu-muenchen.de [re-org'ed]
  4728.         ftp pub/gnu/* from ftp.informatik.rwth-aachen.de
  4729.         ftp pub/gnu/* from nic.funet.fi
  4730.         ftp pub/gnu/* from ugle.unit.no
  4731.         ftp pub/gnu/* from isy.liu.se
  4732.         ftp pub/gnu/* from ftp.stacken.kth.se
  4733.         ftp pub/gnu/* from sunic.sunet.se [re-org'ed]
  4734.         ftp pub/gnu/* from ftp.win.tue.nl
  4735.         ftp pub/gnu/* from ftp.diku.dk
  4736.         ftp software/gnu/* from ftp.eunet.ch
  4737.         ftp gnu/* from archive.eu.net [re-org'ed]
  4738. note:        Many gnu files are now compressed with gzip.  You can
  4739.         tell a gzip'ed file because it has a lower-case .z rather
  4740.         than the capital .Z that compress uses.  Gzip is available
  4741.         from these same archives
  4742.  
  4743. language:    lisp
  4744. package:    MIT AI Lab archives
  4745. description:    archive of lisp extensions, utilities, and libraries
  4746. how to get:    ftp pub/* from ftp.ai.mit.edu
  4747. contact:    ?
  4748.  
  4749. language:    lisp
  4750. package:    Lisp Utilities collection
  4751. how to get:    ftp /afs/cs.cmu.edu/user/mkant/Public/Lisp from ftp.cs.cmu.edu
  4752. contact:    cl-utilities-request@cs.cmu.edu
  4753.  
  4754. language:    Scheme
  4755. package:    The Scheme Repository
  4756. description:    an archive of scheme material including a bibliography, 
  4757.         the R4RS report, sample code, utilities, and implementations.
  4758. how to get:    ftp pub/scheme/* from nexus.yorku.ca
  4759. contact:    Ozan S. Yigit <scheme@nexus.yorku.ca>
  4760.  
  4761. language:    Smalltalk
  4762. package:    Manchester Smalltalk Goodies Library
  4763. description:    a large collection of libraries for smalltalk.
  4764.         Created by Alan Wills, administered by Mario Wolczko.
  4765. how to get:    ftp uiuc/st*/* from st.cs.uiuc.edu
  4766.     uk:        ftp uiuc/st*/* from mushroom.cs.man.ac.uk
  4767. contact:    goodies-lib@cs.man.ac.uk
  4768.  
  4769. language:    Tcl
  4770. package:    Tcl/Tk Contrib Archive
  4771. description:    An archive of Tcl/tk things.  
  4772. how to get:    ftp tcl/* from barkley.berkeley.edu
  4773. contact:    Jack Hsu <tcl-archive@barkley.berkeley.edu>
  4774.  
  4775. -------------------------------------------------------------------------------
  4776. ----------------------------- references --------------------------------------
  4777. -------------------------------------------------------------------------------
  4778.  
  4779. name:        Catalog of embeddable Languages.
  4780. author:        Colas Nahaboo <colas@bagheera.inria.fr>
  4781. how to get:    posted to comp.lang.misc,comp.lang.tcl
  4782. description:    Descriptions of languages from the point of view of 
  4783.         embedding them.
  4784. version:    2
  4785. updated:    1992/07/09
  4786.  
  4787. name:        Compilers bibliography
  4788. author:        Cheryl Lins <lins@apple.com>
  4789. how to get:    ftp pub/oberon/comp_bib_1.4.Z from ftp.apple.com
  4790. description:    It includes all the POPLs, PLDIs, Compiler Construction, 
  4791.         TOPLAS, and LOPAS.  Plus various articles and papers from 
  4792.         other sources on compilers and related topics
  4793. version:    1.4
  4794. updated:    1992/10/31
  4795.  
  4796. name:        Language List
  4797. author:        Bill Kinnersley <billk@hawk.cs.ukans.edu>
  4798. how to get:    posted regularly to comp.lang.misc; ftp from 
  4799.         primost.cs.wisc.edu or idiom.berkeley.ca.us
  4800. description:    Descriptions of almost every computer langauge there is.
  4801.         Many references to available source code.
  4802. version:    1.7 ?
  4803. updated:    1992/04/05
  4804.  
  4805. name:        The Lisp FAQs
  4806. author:        Mark Kantrowitz <mkant+@cs.cmu.edu>
  4807. how to get:    posted regularly to comp.lang.lisp,news.answers,comp.answers
  4808. description:    details of many lisps and systems written in lisps 
  4809.         including many languages not elsewhere.
  4810. version:    1.30
  4811. updated:    1993/02/08
  4812.  
  4813. name:        Survey of Interpreted Languages
  4814. author:        Terrence Monroe Brannon <tb06@CS1.CC.Lehigh.ED>
  4815. how to get:    Posted to comp.lang.tcl,comp.lang.misc,comp.lang.perl,
  4816.         gnu.emacs.help,news.answers; or ftp 
  4817.         pub/gnu/emacs/elisp-ar*/pack*/Hy*Act*F*/survey-inter*-languages
  4818.         from archive.cis.ohio-state.edu.
  4819. description:    Detailed comparision of a few interpreters: Emacs Lisp, 
  4820.         Perl, Python, and Tcl.
  4821. version:    ?
  4822. updated:    ?
  4823.  
  4824. name:        The Apple II Programmer's Catalog of Languages and Toolkits
  4825. author:        Larry W. Virden <lvirden@cas.org>
  4826. description:    a survey of language tools available for the Apple ][.
  4827. how to get:    posted to comp.sys.apple2, comp.lang.misc; ftp from
  4828.         idiom.berkeley.ca.us
  4829. version:    2.0
  4830. updated:    1993/02/12
  4831. -- 
  4832. Send compilers articles to compilers@iecc.cambridge.ma.us or
  4833. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  4834.  
  4835.  
  4836. From compilers Thu Apr  1 15:38:23 EST 1993
  4837. Newsgroups: comp.compilers
  4838. Path: iecc!compilers-sender
  4839. From: assmann@karlsruhe.gmd.de (Uwe Assmann)
  4840. Subject: Theory on loop transformations
  4841. Message-ID: <93-04-006@comp.compilers>
  4842. Keywords: theory, optimize
  4843. Sender: compilers-sender@iecc.cambridge.ma.us
  4844. Organization: GMD Forschungsstelle an der Universitaet Karlsruhe
  4845. Date: Thu, 1 Apr 1993 08:20:25 GMT
  4846. Approved: compilers@iecc.cambridge.ma.us
  4847.  
  4848. I remember that M. Wolfe (and probably others) have tried to develop a
  4849. theory on loop transformations that looked at the loop transformation as a
  4850. matrix. Whenever a transformation is performed this amounts to a matrix
  4851. operation over the loop. Does anybody have references or new information?
  4852.  
  4853. In general, I am interested in a general theory on loop transformations.
  4854.  
  4855. --
  4856. Uwe Assmann
  4857. GMD Forschungsstelle an der Universitaet Karlsruhe
  4858. Vincenz-Priessnitz-Str. 1
  4859. 7500 Karlsruhe GERMANY
  4860. Email: assmann@karlsruhe.gmd.de Tel: 0721/662255 Fax: 0721/6622968
  4861. -- 
  4862. Send compilers articles to compilers@iecc.cambridge.ma.us or
  4863. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  4864.  
  4865.  
  4866. From compilers Thu Apr  1 15:39:31 EST 1993
  4867. Newsgroups: comp.compilers
  4868. Path: iecc!compilers-sender
  4869. From: mwolfe@dat.cse.ogi.edu (Michael Wolfe)
  4870. Subject: High Performance Compilers Summer Courses
  4871. Message-ID: <93-04-007@comp.compilers>
  4872. Keywords: courses
  4873. Sender: compilers-sender@iecc.cambridge.ma.us
  4874. Organization: Oregon Graduate Institute - Computer Science & Engineering
  4875. Date: Thu, 1 Apr 1993 17:32:08 GMT
  4876. Approved: compilers@iecc.cambridge.ma.us
  4877.  
  4878. Once again, the Oregon Graduate Institute is offering
  4879.  
  4880. Summer Intensive Workshops on High Performance Compilers
  4881.  
  4882. Analysis and Optimization for Modern Architectures
  4883. Monday-Friday, August 16-20, 1993
  4884.  
  4885. Advanced Analysis and Optimizing for Parallelism
  4886. Monday-Friday, August 23-27, 1993
  4887.  
  4888. with Michael Wolfe
  4889. Hotel Vintage Plaza
  4890. Portland, Oregon
  4891.  
  4892. The past two years' courses have been well attended and received.  This
  4893. year's offerings build on previous courses, but are updated and expanded.
  4894.  
  4895. The full details of these courses are available electronically
  4896. via anonymous ftp at:
  4897.  
  4898.     % ftp cse.ogi.edu        [or ftp 129.95.40.2]
  4899.     Name: anonymous
  4900.     Password: myname@where.am.i
  4901.     ftp> cd pub
  4902.     ftp> cd HPC
  4903.     ftp> get brochure
  4904.     ftp> quit
  4905.     %
  4906.  
  4907. Or send email to
  4908.     mwolfe@cse.ogi.edu (for technical inquiries)
  4909.     lpease@admin.ogi.edu (for registration of a printed brochure)
  4910.  
  4911. What follows is the (lengthy) course outline for the two courses.
  4912.  
  4913. ==================================================================
  4914.  
  4915. ANALYSIS AND OPTIMIZATION FOR MODERN ARCHITECTURES
  4916. Monday-Friday, August 16-20, 1993
  4917.  
  4918. Course Outline:
  4919.  
  4920. MONDAY:
  4921.  
  4922. 1. Pipelined Processor Architecture
  4923. . Architectural Options
  4924.   - pipelined functional units
  4925.   - large register file (usually)
  4926.   - vector instruction set
  4927.   - cache memory
  4928. . Control Unit Options
  4929.   - register windows
  4930.   - VLIW/super-scalar control unit
  4931.   - register renaming
  4932.   - multithreading
  4933. . Representative Architectures
  4934.   Multiflow Trace/300, Cydrome Cydra 5, IBM RS/6000, Intel i860,
  4935.   Cray C90, Digital Alpha, Hewlett Packard PA-RISC
  4936.  
  4937. 2. Compiler Framework
  4938.   - front end
  4939.   - high-level optimizations
  4940.   - back-end optimizations
  4941.   - code generation
  4942.   - peephole optimizations
  4943.   - basic blocks, control flow graph
  4944. . Basic Data Structures
  4945.   - tuple, list, tree, graph
  4946.  
  4947. 3. Data Flow Analysis
  4948. . Dataflow Problems
  4949.   - live variables
  4950.   - reaching definitions
  4951.   - dominators
  4952. . Applications
  4953.   - dead code elimination
  4954.   - use-def chains, constant propagation
  4955.   - loop discovery
  4956. . Dataflow Framework
  4957.   - lattice framework
  4958.   - iterative algorithm
  4959. . Complications
  4960.   - aliasing (pointers, reference formals)
  4961.   - volatile variables
  4962. . Other Dataflow Solution Methods
  4963.   - syntax-based elimination methods
  4964.   - interval analysis
  4965.   - slotwise analysis
  4966.  
  4967. 4. Dominator Analysis
  4968.   - dominator trees
  4969.   - more details on loop discovery
  4970.   - unreachable code elimination
  4971.  
  4972. TUESDAY:
  4973.  
  4974. 5. Machine Independent Optimizations
  4975.   - constant propagation
  4976.   - constant folding
  4977.   - copy propagation
  4978.   - constant conditional elimination
  4979.   - common subexpression elimination
  4980.  
  4981. 6. Loop Optimizations
  4982.   - code floating
  4983.   - strength reduction (induction variables)
  4984.   - linear test replacement
  4985.   - partial redundancy elimination
  4986.  
  4987. 7. Procedure Optimizations
  4988.   - leaf procedures
  4989.   - tail recursion, tail calls
  4990.  
  4991. 8. Improving Optimizations
  4992.   - loop rotation
  4993.   - code replication (tracing)
  4994.   - procedure integration
  4995.  
  4996. WEDNESDAY:
  4997.  
  4998. 9. Local Register Allocation
  4999.   - minimizing register utilization
  5000.  
  5001. 10. Register Allocation via Coloring
  5002.   - spill heuristics
  5003.   - coloring algorithms
  5004.   - allocating register pairs
  5005.   - register coalescing
  5006.   - splitting live ranges
  5007.  
  5008. 11. Other Register Allocation Heuristics
  5009.   - hierarchical allocation
  5010.   - vector register allocation
  5011.   - register allocation in loops
  5012.  
  5013. THURSDAY:
  5014.  
  5015. 12. Instruction Scheduling
  5016.   - basic block scheduling
  5017.   - extended basic block formation
  5018.   - filling delay slots
  5019.  
  5020. 13. Scheduling in Loops
  5021.   - software pipelining
  5022.   - polycyclic scheduling
  5023.   - loop unrolling, peeling
  5024.   - register assignment in loops
  5025.   - vector instruction scheduling, chaining
  5026.  
  5027. FRIDAY:
  5028.  
  5029. 14. Peephole Optimizations
  5030.   - tail merging
  5031.   - jump optimizations
  5032.   - optimizing for branch prediction
  5033.   - instruction placement
  5034.  
  5035. 15. Interacting with Debuggers
  5036.   - currency of values in registers
  5037.   - currency of values in memory
  5038.   - reporting values of variables
  5039.   - reporting position
  5040.  
  5041. 16. Instruction Selection
  5042.   - hand-written code generators
  5043.   - table-driven code generators
  5044.  
  5045. 17. Engineering a Real Compiler
  5046.   - software engineering
  5047.   - time to market
  5048.   - managing data structures
  5049.   - interactive data structure browser
  5050.   - graphical display of data structures
  5051.   - 'source-level' debugging
  5052.  
  5053. ==================================================================
  5054.  
  5055. ADVANCED ANALYSIS AND OPTIMIZING FOR PARALLELISM
  5056. Monday-Friday, August 23-27, 1993
  5057.  
  5058. Course Outline:
  5059.  
  5060. MONDAY:
  5061.  
  5062. 1. Parallel Computer Architecture
  5063. . Architectural Options
  5064.   - vector instruction sets
  5065.   - multiple CPUs sharing memory
  5066.   - multiple operations per instruction
  5067.   - super-scalar control unit
  5068.   - super-pipelined data unit
  5069.   - cache memory organization
  5070.   - cache coherence mechanisms
  5071.   - massively parallel SIMD and MIMD
  5072.   - message passing systems
  5073.   - latency tolerating systems
  5074.   - locality-based systems
  5075. . Current Examples
  5076.   Intel i860, IBM RS/6000, Multiflow Trace/300, Cray C-90, Alliant FX/80,
  5077.   Intel iPSC/860, Thinking Machines CM-2 and CM-5, MasPar MP-2
  5078.  
  5079. 2. Compiler Framework
  5080. . Compiler Structure
  5081.   - front end
  5082.   - high-level optimizations
  5083.   - back-end optimizations
  5084.   - code generation
  5085.   - peephole optimizations
  5086. . Internal Data Structures
  5087.   - basic blocks, control flow graph
  5088.  
  5089. 3. Basic Data Structures and Concepts
  5090.   - lists, trees, graphs
  5091.   - formal introduction into graphs
  5092.   - graph algorithms (traversal, spanning trees, cycles)
  5093.  
  5094. 4. Dataflow Problems in a Lattice Context
  5095.   - monotone dataflow framework
  5096.   - reaching definitions, live variables
  5097.   - iterative solution
  5098.  
  5099. 5. Control Flow Analysis
  5100.   - dominators
  5101.   - control dependence
  5102.   - identifying loops
  5103.  
  5104. 6. Static Single Assignment (Factored Use-Def Chains)
  5105.   - conversion to static single assignment
  5106.   - conditional constant propagation
  5107.   - induction variable identification
  5108.   - comparison to classical methods
  5109.   - handling parallel language extensions
  5110.  
  5111. 7. Sparse Dataflow Evaluation Graphs
  5112.   - constructing the sparse graph
  5113.  
  5114. TUESDAY:
  5115.  
  5116. 8. Data Dependence Analysis Techniques
  5117. . Introduction
  5118.   - types: flow, anti, output dependence
  5119.   - abstractions: distance, direction vectors
  5120. . Subscript Analysis
  5121.   - formulating a dependence equation
  5122.   - handling symbolic variables
  5123. . Solving the Dependence Equation
  5124.   - single variable exact test
  5125.   - Banerjee's inequalities,
  5126.   - Stanford sieve
  5127.   - Lambda, Delta, Omega, Power tests
  5128. . Complications
  5129.   - I/O dependence
  5130.   - aliasing, EQUIVALENCE, COMMON
  5131.   - structure aliasing
  5132. . Beyond Classical Methods
  5133.   - array kill analysis
  5134.   - pointers, dynamic aliasing
  5135.   - argument aliasing
  5136. . Program Dependence Graph
  5137.  
  5138. WEDNESDAY:
  5139.  
  5140. 9. Non-Loop Parallelism
  5141. . Hierarchical Task Graph
  5142.  
  5143. 10. Program Restructuring for Shared Memory
  5144.   - parallelization
  5145.   - scheduling parallel code
  5146.   - induction variables, temporaries, etc.
  5147.   - distribution
  5148.   - alignment
  5149.   - index set splitting
  5150.   - synchronization
  5151.   - interchanging
  5152.   - optimizing for memory locality
  5153.   - linear index set transformations
  5154.   - privatization
  5155.   - performance modeling
  5156.  
  5157. 11. Restructuring for Vector Computers
  5158.   - vectorization
  5159.   - scalar expansion
  5160.   - reductions
  5161.   - strip mining
  5162.  
  5163. 12. Restructuring for SIMD Computers
  5164.   - strip mining, combing
  5165.   - scalarization, fusion
  5166.  
  5167. 13. Restructuring for Scalar Computers
  5168.   - tiling for cache locality
  5169.   - stride sensitivity
  5170.   - handling nontightly nested loops
  5171.  
  5172. 14. Other Restructuring Transformation
  5173.   - loop fusion
  5174.   - loop rotation
  5175.   - handling nontightly nested loops
  5176.  
  5177. THURSDAY:
  5178.  
  5179. 15. Interprocedural Analysis
  5180. . Summarizing the Effects of Procedures
  5181.   - flow insensitive USE and MOD information
  5182.   - summarizing USE and MOD of arrays
  5183. . Interprocedural Constant Propagation
  5184. . Interprocedural Alias Analysis
  5185.  
  5186. 16. High Performance Fortran Language
  5187. . Parallelism
  5188.   - array assignment, FORALL
  5189. . Data Distribution
  5190.   - Align, Distribute, Template
  5191. . Expected Behavior
  5192. . Complications
  5193.   - pointer assignments
  5194.   - dynamic realignment
  5195.   - inherited alignments
  5196.  
  5197. 17. Local HPF Analysis
  5198. . Conformance
  5199. . Alignment Analysis
  5200.  
  5201. 18. HPF Code Generation
  5202. . Generate a Node Program
  5203.   - local vs. global index sets and indices
  5204.   - local data allocation
  5205. . Communication
  5206.   - where to place communication
  5207.   - communication vectorization
  5208.  
  5209. FRIDAY:
  5210.  
  5211. 19. Optimizing HPF Node Programs
  5212. . Index Set Calculation
  5213.   - recovering induction variables
  5214.   - finite state machine analysis
  5215.   - guard regions
  5216.   - overlapping communication
  5217.  
  5218. 20. Interprocedural Analysis for HPF
  5219. . Reaching Distributions
  5220.   - procedure cloning
  5221. . Guard Region Analysis
  5222.  
  5223. 21. Other Parallel Languages
  5224. . Dataparallel C
  5225.   - front-end/back-end model
  5226.   - communication classification
  5227. . SISAL
  5228.   - sequentialize to reduce data copying
  5229.   - dynamic task scheduling
  5230. . Crystal
  5231.   - automatic data alignment
  5232.   - parallel code generation
  5233.   - elimination of temporal domain storage
  5234.  
  5235. 22. Current Research
  5236. . Extensions to SSA model
  5237.   - better handling of aliases
  5238. . Data Restructuring
  5239.   - sparse array implementation
  5240.   - influencing sparse array representation
  5241.   - compression of sparse index sets
  5242. . Low Level Extensions to HPF
  5243.   - MetaMP extensions
  5244.   - interface to HPF
  5245.   - optimize MetaMP portion of program
  5246. . C++ Optimizations
  5247.   - achieve performance of Fortran from C++
  5248.   - expose C++ methods to optimizations
  5249.  
  5250. 23. Engineering a Real Compiler
  5251.   - software engineering
  5252.   - time to market
  5253.   - managing data structures
  5254.   - interactive data structure browser
  5255.   - graphical display of data structures
  5256.   - 'source-level' debugging
  5257. -- 
  5258. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5259. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5260.  
  5261.  
  5262. From compilers Thu Apr  1 23:27:17 EST 1993
  5263. Newsgroups: comp.compilers
  5264. Path: iecc!compilers-sender
  5265. From: cosc19py@jane.uh.edu (93S07005)
  5266. Subject: Semantic actions in LR parser
  5267. Message-ID: <93-04-008@comp.compilers>
  5268. Keywords: LR(1), parse, question, comment
  5269. Sender: compilers-sender@iecc.cambridge.ma.us
  5270. Organization: University of Houston
  5271. Date: Fri, 2 Apr 1993 02:45:00 GMT
  5272. Approved: compilers@iecc.cambridge.ma.us
  5273.  
  5274. Hi,
  5275.  
  5276. I am just wondering if we have to put all semantic actions on the tail
  5277. parts of some productions for LR grammar instead of any positions in LL
  5278. grammar?
  5279.  
  5280. e.g. A -> b B c d C D e {semantic action}
  5281.  
  5282. Are there some kind LR parsers exists without this restriction? In yacc,
  5283. it allows no restriction but transforms those productions into many pseudo
  5284. productions which seems unnatural. In addition to this approach, Are there
  5285. any parsers can achieve it?
  5286.  
  5287. Any pointers would be appreciated.
  5288.  
  5289. Sue
  5290. [I can't see how an LR parser can execute the action until the entire
  5291. RHS has been read, since before that it doesn't know what rule it's going
  5292. to recognize. -John]
  5293. -- 
  5294. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5295. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5296.  
  5297.  
  5298. From compilers Fri Apr  2 15:35:36 EST 1993
  5299. Newsgroups: comp.compilers
  5300. Path: iecc!compilers-sender
  5301. From: jjan@cs.rug.nl (Beeblebrox)
  5302. Subject: Re: Theory on loop transformations
  5303. Message-ID: <93-04-009@comp.compilers>
  5304. Keywords: theory, optimize
  5305. Sender: compilers-sender@iecc.cambridge.ma.us
  5306. Organization: Dept. of Computing Science, Groningen University
  5307. References: <93-04-006@comp.compilers>
  5308. Date: Fri, 2 Apr 1993 14:31:41 GMT
  5309. Approved: compilers@iecc.cambridge.ma.us
  5310.  
  5311.   From: assmann@karlsruhe.gmd.de (Uwe Assmann)
  5312. > ... M. Wolfe (and probably others) have tried to develop a theory on loop
  5313. >transformations that looked at the loop transformation as a matrix.
  5314.  
  5315. Yep. I found it in ACM SIGPLAN'91 Conference: p.30-45,
  5316. authors Michael E. Wolf (not Wolfe) and Monica S. Lam (Stanford Uni.)
  5317. --
  5318. Jan Jongejan                            email: jjan@cs.rug.nl
  5319. Dept. Comp.Sci.,
  5320. Univ. of Groningen,
  5321. Netherlands.
  5322. -- 
  5323. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5324. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5325.  
  5326.  
  5327. From compilers Fri Apr  2 15:39:59 EST 1993
  5328. Newsgroups: comp.compilers
  5329. Path: iecc!compilers-sender
  5330. From: roy@prism.gatech.edu (Roy Mongiovi)
  5331. Subject: Re: Semantic actions in LR parser
  5332. Message-ID: <93-04-010@comp.compilers>
  5333. Keywords: LR(1), parse
  5334. Sender: compilers-sender@iecc.cambridge.ma.us
  5335. Organization: Georgia Institute of Technology
  5336. References: <93-04-008@comp.compilers>
  5337. Date: Fri, 2 Apr 1993 15:01:24 GMT
  5338. Approved: compilers@iecc.cambridge.ma.us
  5339.  
  5340. LR parsers can only perform semantic actions when the recognize a handle
  5341. (right-hand side).  You can either split up the right-hand sides into
  5342. pieces so that the pieces end where you need the semantic actions, or you
  5343. can stick in epsilon productions whose only purpose is to cause semantic
  5344. actions.
  5345. --
  5346. Roy J. Mongiovi   Systems Support Specialist        Information Technology
  5347. Georgia Institute of Technology, Atlanta, Georgia  30332-0715
  5348. roy@prism.gatech.edu
  5349. -- 
  5350. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5351. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5352.  
  5353.  
  5354. From compilers Fri Apr  2 15:48:13 EST 1993
  5355. Newsgroups: comp.compilers
  5356. Path: iecc!compilers-sender
  5357. From: dsehr@gomez.intel.com (David Sehr)
  5358. Subject: Re: Theory on loop transformations
  5359. Message-ID: <93-04-011@comp.compilers>
  5360. Keywords: optimize, theory
  5361. Sender: compilers-sender@iecc.cambridge.ma.us
  5362. Organization: Architecture & Software Technology, Intel Corp, Santa Clara, CA
  5363. References: <93-04-006@comp.compilers>
  5364. Date: Fri, 2 Apr 1993 16:31:04 GMT
  5365. Approved: compilers@iecc.cambridge.ma.us
  5366.  
  5367. Uwe Assmann (assmann@karlsruhe.gmd.de) wrote:
  5368. > I remember that M. Wolfe (and probably others) have tried to develop a
  5369. > theory on loop transformations that looked at the loop transformation as a
  5370. > matrix. 
  5371.  
  5372. A colleague here at Intel has been working on exactly that problem for
  5373. several years.  His name is Utpal Banerjee, and he has recently
  5374. published a book describing the approach you mention (using unimodular
  5375. matrices for dependence testing and transformation).  The full info:
  5376.     Loop Transformations for Restructuring Compilers: the Foundations
  5377.     Utpal Banerjee
  5378.     Kluwer Academic Publishers
  5379.     ISBN: 0-7923-9318-X
  5380.  
  5381. Other possibilities to pursue are the recent papers of William Pugh of
  5382. the University of Maryland (pugh@cs.umd.edu), and Paul Feautrier of the
  5383. University of P. et M. Curie (feautrier@masi.ibp.fr).
  5384.  
  5385. Hope this helps.
  5386.  
  5387. David
  5388. --
  5389. David C. Sehr, Intel Corporation
  5390. 2200 Mission College Blvd., M/S RN6-18
  5391. Santa Clara, CA 95052-8119
  5392. -- 
  5393. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5394. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5395.  
  5396.  
  5397. From compilers Fri Apr  2 15:49:23 EST 1993
  5398. Newsgroups: comp.compilers
  5399. Path: iecc!compilers-sender
  5400. From: colas@opossum.inria.fr (Colas Nahaboo)
  5401. Subject: Regexps from shell wilcards
  5402. Message-ID: <93-04-012@comp.compilers>
  5403. Keywords: lex, question
  5404. Sender: compilers-sender@iecc.cambridge.ma.us
  5405. Organization: Koala Project, Bull Research France
  5406. Date: Fri, 2 Apr 1993 16:31:24 GMT
  5407. Approved: compilers@iecc.cambridge.ma.us
  5408.  
  5409. Is there an algorithm to convert shell-expressions into regular
  5410. expressions?  (i.e. generate the string ".*[.]c" from the input "*.c")
  5411.  
  5412. In the same vein, is there an algorithm to generate case-independent
  5413. regular expressions from nomal ones?  (i.e. generate the string
  5414. "[aA][bB][cC][eEfFgG]*" from the input "abc[efg]*")
  5415. --
  5416. Colas Nahaboo, Koala (Bull Research). colas@koala.inria.fr
  5417. -- 
  5418. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5419. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5420.  
  5421.  
  5422. From compilers Fri Apr  2 15:55:17 EST 1993
  5423. Xref: iecc comp.object:9759 comp.arch:27570 comp.compilers:4471
  5424. Newsgroups: comp.object,comp.arch,comp.compilers
  5425. Path: iecc!compilers-sender
  5426. From: "Steven A. Moyer" <sam2y@koa.cs.virginia.edu>
  5427. Subject: Re: non-caching load and GC
  5428. Message-ID: <93-04-013@comp.compilers>
  5429. Keywords: architecture, GC
  5430. Sender: compilers-sender@iecc.cambridge.ma.us
  5431. Organization: University of Virginia Computer Science Department
  5432. References: <C4ppA5.BLx.1@cs.cmu.edu>
  5433. Date: Fri, 2 Apr 1993 18:53:03 GMT
  5434. Approved: compilers@iecc.cambridge.ma.us
  5435.  
  5436. monnier+@cs.cmu.edu (Stefan Monnier) writes:
  5437. >I have the impression that it could be interesting for a GC to use loads
  5438. >that don't necessarily bring the data in the cache (like the
  5439. >pipelined-float-load of the i860) in order not to completely flush the
  5440. >cache while garbage collecting (this seems most interesting when sweeping,
  5441. >but could be useful for copying collectors also).
  5442. >
  5443. >I haven't found any paper discussing this kind of 'optimisation'.
  5444. >
  5445. >Does such a paper exist ? Or is the idea just dumb ?
  5446. >Which processors have such a load ?
  5447.  
  5448. I'll address these questions in reverse order:
  5449.  
  5450. 1) Currently the only microprocessor with such an instruction is the i860.
  5451.  
  5452. 2) Utilizing a non-caching load instruction in a manner complementary to
  5453.    caching is in fact a good idea and can significantly improve effective
  5454.    memory bandwidth for many computations.
  5455.  
  5456. 3) My very recently completed dissertation develops a family of compiler
  5457.    optimizations, called 'access ordering', that exploit a non-caching
  5458.    load instruction. These algorithms are applicable to stream-oriented
  5459.    computations (loosely, vectorizable) and are derived in the context of
  5460.    scientific computing.  Essentially, one would like to apply blocking
  5461.    techniques to cache multiply-referenced data items and then use non-caching
  5462.    load instructions to reference single-visit items.
  5463.  
  5464.      Note: the technique is also very useful for implementing the
  5465.            'copy optimization' by using non-caching loads to reference
  5466.            items to be copied to the contiguous memory region.
  5467.  
  5468.    Applying non-caching loads in such a fashion requires much more than
  5469.    simply replacing load instructions that reference single-visit items
  5470.    with non-caching loads; one must then consider the effect of the
  5471.    observed reference sequence on the other side of the cache.  Access
  5472.    ordering algorithms perform loop unrolling and reorder non-caching
  5473.    loads to exploit the underlying memory system characteristics (eg
  5474.    architecture and component type).
  5475.  
  5476.    The work presented in my dissertation focuses on reordering algorithms
  5477.    for a number of common architecture/component pairs; performance models
  5478.    are derived for the resulting sequences of non-caching accesses.
  5479.    Combining caching and non-caching accesses is discussed in a general
  5480.    way, but is not formalized (hey, ya got to draw the line somewhere :-)
  5481.  
  5482.    Papers on access ordering have not reached print yet, but if you are
  5483.    interested in obtaining further information you can get two pertinent
  5484.    techreports via anonymous ftp to uvacs.cs.virginia.edu; the reports
  5485.    are the compressed postscript files:
  5486.  
  5487.      pub/techreports/IPC-92-02.ps.Z (single module architecture)
  5488.      pub/techreports/IPC-92-12.ps.Z (interleaved architecture)
  5489.  
  5490.    Warning: these reports contain old (and not particularly well done, I'll
  5491.             admit) notation; all the notation in the actual dissertation
  5492.             has been significantly altered and matured and results have a
  5493.             much greater degree of formality. Furthermore, by altering
  5494.             notation many of the equations simplified significantly.
  5495.  
  5496.             Therefore, if you find this optimization to be useful for your
  5497.             work, it is recommended you contact me to receive a copy
  5498.             of the complete (and *much* improved) dissertaton text.
  5499.  
  5500. I hope this helps in addressing your question.  I'm afraid I'm not that
  5501. familiar with the state of the art in GC algorithms, but from your
  5502. description it sounds as if access ordering techniques may be helpful.
  5503.  
  5504. Steve
  5505. --
  5506. Steve Moyer
  5507. Computer Science Department
  5508. University of Virginia
  5509. -- 
  5510. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5511. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5512.  
  5513.  
  5514. From compilers Sat Apr  3 20:09:49 EST 1993
  5515. Newsgroups: comp.compilers
  5516. Path: iecc!compilers-sender
  5517. From: karsten@tfl.dk (Karsten Nyblad)
  5518. Subject: Re: Semantic actions in LR parser
  5519. Message-ID: <93-04-014@comp.compilers>
  5520. Keywords: LR(1), parse
  5521. Sender: compilers-sender@iecc.cambridge.ma.us
  5522. Organization: TFL
  5523. References: <93-04-008@comp.compilers> <93-04-010@comp.compilers>
  5524. Date: Sat, 3 Apr 1993 09:37:19 GMT
  5525. Approved: compilers@iecc.cambridge.ma.us
  5526.  
  5527. roy@prism.gatech.edu (Roy Mongiovi) writes:
  5528.  
  5529. >LR parsers can only perform semantic actions when the recognize a handle
  5530. >(right-hand side).  You can either split up the right-hand sides into
  5531. >pieces so that the pieces end where you need the semantic actions, or you
  5532. >can stick in epsilon productions whose only purpose is to cause semantic
  5533. >actions.
  5534.  
  5535. Hi,
  5536.  
  5537. That is wrong.  When there is only one item in the kernel of a state, the
  5538. production of that item will always be reduced at a later point.  So, you
  5539. can allow for actions to be executed when you push a terminal or
  5540. nonterminal and that brings you to a state that has only one item in
  5541. kernel.
  5542.  
  5543. Even that can be generalized.  All items of the kernel of a state has the
  5544. same symbol before the . of the item, where the . denotes the point until
  5545. which the parser has accepted the symbols of the production of the item.
  5546. If the same action has been specified on all productions of the items of
  5547. the kernel of a state on pushing the symbol before the ., then that action
  5548. can executed by the parser.
  5549.  
  5550. That can also the generalized.  If the first terminals of the symbols
  5551. following . differs, then that can be used to select the actions to be
  5552. taken.
  5553.  
  5554. Example:
  5555.  
  5556.      Assume the productions A -> A B {action 1} C
  5557.                             B -> B { action 1 } D
  5558.                             C -> B { action 2 } E
  5559.      are part of the productions of a grammar.
  5560.      The actions are to be executed when B is pushed.
  5561.  
  5562.      In a state with the kernel
  5563.  
  5564.                A -> A B . C
  5565.                B -> B . D
  5566.  
  5567.      the action 1 can be taken.
  5568.      In a state with the kernel
  5569.  
  5570.                B -> B . D
  5571.                C -> B . E
  5572.  
  5573.      both action 1 and 2 could be taken and thus the
  5574.      grammar is ambigouos.  That ambiguity can be solved if
  5575.      D and E do not start with the same terminals, e.g.
  5576.      are different terminals.
  5577.  
  5578. Karsten Nyblad
  5579. TFL, A Danish Telecommunication Research Lab.
  5580. karsten@tfl.dk
  5581. -- 
  5582. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5583. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5584.  
  5585.  
  5586. From compilers Sat Apr  3 20:10:25 EST 1993
  5587. Newsgroups: comp.compilers
  5588. Path: iecc!compilers-sender
  5589. From: pugh@cs.umd.edu (Bill Pugh)
  5590. Subject: Re: Theory on loop transformations
  5591. Message-ID: <93-04-015@comp.compilers>
  5592. Keywords: theory, optimize, bibliography
  5593. Sender: compilers-sender@iecc.cambridge.ma.us
  5594. Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
  5595. References: <93-04-006@comp.compilers>
  5596. Date: Sat, 3 Apr 1993 16:43:26 GMT
  5597. Approved: compilers@iecc.cambridge.ma.us
  5598.  
  5599.  
  5600. assmann@karlsruhe.gmd.de (Uwe Assmann) writes:
  5601. >I remember that M. Wolfe (and probably others) have tried to develop a
  5602. >theory on loop transformations ...
  5603. >In general, I am interested in a general theory on loop transformations.
  5604.  
  5605. Actually, it was M. E. Wolf, not M. Wolfe (confusing, isn't it?).
  5606. Here are a couple of references on the subject.
  5607.  
  5608.     Bill Pugh
  5609. ----------
  5610.  
  5611.  
  5612. U. Banerjee.
  5613.  Unimodular transformations of double loops.
  5614.  In {\em Proc. of the 3rd Workshop on Programming Languages and
  5615.   Compilers for Parallel Computing}, Irvine, CA, August 1990.
  5616.  
  5617. Paul Feautrier.
  5618.  Some efficient solutions to the affine scheduling problem, part i,
  5619.   one-dimensional time.
  5620.  Technical Report 92.28, IBP/MASI, April 1992.
  5621.  
  5622. Paul Feautrier.
  5623.  Some efficient solutions to the affine scheduling problem, part ii,
  5624.   multi-dimensional time.
  5625.  Technical Report 92.78, IBP/MASI, Oct 1992.
  5626.  
  5627. Wayne Kelly and William Pugh,
  5628.  Generating Schedules and Code within a
  5629.         Unified Reordering Transformation Framework,
  5630.   Technical Report CS-TR-2995,
  5631.   Dept. of Computer Science, University of Maryland, College Park,
  5632.   November, 1992
  5633.  
  5634.  
  5635. K. G. Kumar, D. Kulkarni, and A. Basu.
  5636.  Deriving good transformations for mapping nested loops on hieracical
  5637.   parallel machines in polynomial time.
  5638.  In {\em Proc. of the 1992 International Conference on
  5639.   Supercomputing}, July 1992.
  5640.  
  5641. Wei Li and Keshav Pingali.
  5642.  A singular loop transformation framework based on non-singular
  5643.   matrices.
  5644.  In {\em 5th Workshop on Languages and Compilers for Parallel
  5645.   Computing}, Yale University, August 1992.
  5646.  
  5647. Lee-Chung Lu.
  5648.  A unified framework for systematic loop transformations.
  5649.  In {\em Proceedings of Third ACM SIGPLAN Symp. on the Principles \&
  5650.   Practice of Parallel Programming}, April 1991.
  5651.  
  5652. William Pugh.
  5653.  Uniform techniques for loop optimization.
  5654.  In {\em 1991 International Conference on Supercomputing}, pages
  5655.   341--352, Cologne, Germany, June 1991.
  5656.  
  5657. J. Ramanujam.
  5658.  Non-unimodular transformations of nested loops.
  5659.  In {\em Supercomputing `92}, November 1992.
  5660.  
  5661. Vivek Sarkar and Radhika Thekkath.
  5662.  A general framework for iteration-reordering loop transformations.
  5663.  In {\em ACM SIGPLAN'92 Conference on Programming Language Design and
  5664.   Implementation}, San Francisco, California, Jun 1992.
  5665.  
  5666. Michael E. Wolf and Monica S. Lam.
  5667.  A data locality optimizing algorithm.
  5668.  In {\em ACM SIGPLAN'91 Conference on Programming Language Design and
  5669.   Implementation}, 1991.
  5670.  
  5671. Michael E. Wolf and Monica S. Lam.
  5672.  A loop transformation theory and an algorithm to maximize
  5673.   parallelism.
  5674.  In {\em IEEE Transactions on Parallel and Distributed Systems}, July
  5675.   1991.
  5676.  
  5677.  
  5678.  
  5679. -- 
  5680. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5681. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5682.  
  5683.  
  5684. From compilers Sat Apr  3 20:11:17 EST 1993
  5685. Newsgroups: comp.compilers
  5686. Path: iecc!compilers-sender
  5687. From: Wei Li <wei@cs.cornell.EDU>
  5688. Subject: Re: Theory on loop transformations
  5689. Message-ID: <93-04-016@comp.compilers>
  5690. Keywords: theory, optimize, bibliography, FTP
  5691. Sender: compilers-sender@iecc.cambridge.ma.us
  5692. Organization: Cornell University, CS Dept., Ithaca, NY
  5693. References:  <93-04-006@comp.compilers>
  5694. Date: Sat, 3 Apr 1993 18:19:48 GMT
  5695. Approved: compilers@iecc.cambridge.ma.us
  5696.  
  5697. assmann@karlsruhe.gmd.de (Uwe Assmann) writes:
  5698. |> In general, I am interested in a general theory on loop transformations.
  5699.  
  5700.  We have a matrix-oriented approach to loop transformations that uses
  5701. non-singular matrices to represent loop transformations. Non-singular
  5702. matrices generalize the unimodular approach (unimodular matrices are a
  5703. special case of non-singular matrices in which the determinant is 1 or
  5704. -1).  Some important transformations such as loop tiling can only be
  5705. modeled by non-singular matrices.  Furthermore, we provide a completion
  5706. algorithm that makes the theory easier to use in practice.  In
  5707. transformations for parallelism and data locality, it is very useful to
  5708. have such completion algorithm.  Our work was presented at the 5th
  5709. Compiler Workshop at Yale last year.  A journal version is to appear soon
  5710. in IJPP.
  5711.  
  5712. We have used the non-singular matrix framework to develop optimizations
  5713. for data locality in our compiler for NUMA parallel machines.  You can
  5714. find how the transformation matrix is constructed automatically.  The
  5715. algorithms are in the paper that appeared in ASPLOS V (ACM SIGPLAN
  5716. Notices, Vol 27, Number 9, Sep.  1992).
  5717.  
  5718. The papers can also be found via ftp from Cornell (ftp.cs.cornell.edu,
  5719. pub/TyphoonCompiler/papers-ps/).
  5720.  
  5721. ---------------------------------------------------------------------------
  5722. file:   framework.ps
  5723.  
  5724.         "A Singular Loop Transformation Framework
  5725.          Based on Non-singular Matrices"
  5726.            by Wei Li and Keshav Pingali
  5727. ---------------------------------------------------------------------------
  5728. file:   asplos92.ps
  5729.  
  5730.         "Access Normalization: Loop Restructuring for NUMA Compilers"
  5731.            by Wei Li and Keshav Pingali
  5732. ---------------------------------------------------------------------------
  5733. file:   pnuma.ps
  5734.  
  5735.         "Loop Transformations for NUMA Machines"
  5736.            by Wei Li and Keshav Pingali
  5737.            SIGPLAN Notices, January 1993
  5738.  
  5739. -- Wei Li
  5740. Department of Computer Science
  5741. Cornell University
  5742. Ithaca, NY 14853
  5743. -- 
  5744. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5745. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5746.  
  5747.  
  5748. From compilers Sat Apr  3 20:13:14 EST 1993
  5749. Newsgroups: comp.compilers
  5750. Path: iecc!compilers-sender
  5751. From: mehrotra@csrd.uiuc.edu (Sharad Mehrotra)
  5752. Subject: Re: Theory on loop transformations
  5753. Message-ID: <93-04-017@comp.compilers>
  5754. Keywords: optimize, theory
  5755. Sender: compilers-sender@iecc.cambridge.ma.us
  5756. Organization: University of Illinois, Center for Supercomputing R&D
  5757. References: <93-04-006@comp.compilers> <93-04-011@comp.compilers>
  5758. Date: Sun, 4 Apr 1993 00:26:53 GMT
  5759. Approved: compilers@iecc.cambridge.ma.us
  5760.  
  5761. >[re references on theory of loop transformations]
  5762.  
  5763. Those are excellent pointers, but unimodular transformations are only one
  5764. aspect of the larger problem of automatic program parallelization. If you
  5765. are just getting started in the area, you might find the following CSRD
  5766. report (also to appear soon in the Proceedings of the IEEE) useful:
  5767.  
  5768.     Banerjee, U., Eigenman, R., Nicolau, A., and Padua, D.,
  5769.     "Automatic Program Parallelization", CSRD TR 1250, November 1992.
  5770.  
  5771. The report contains a timely survey of the field and a bibliography with
  5772. 161 citations.
  5773.  
  5774. Many CSRD Tech Reports are available for anonymous ftp from host
  5775. sp2.csrd.uiuc.edu (128.174.153.4) in directory CSRD_Info/reports. We'll
  5776. try and arrange to put the PostScript for this report there soon. If it's
  5777. not available in a few days, email reinhart@csrd.uiuc.edu, and ask for a
  5778. paper copy by snail mail.
  5779. -- 
  5780. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5781. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5782.  
  5783.  
  5784. From compilers Sun Apr  4 22:19:43 EDT 1993
  5785. Newsgroups: comp.compilers
  5786. Path: iecc!compilers-sender
  5787. From: Warner Losh <imp@Boulder.ParcPlace.COM>
  5788. Subject: Re: Regexps from shell wildcards
  5789. Message-ID: <93-04-018@comp.compilers>
  5790. Keywords: lex
  5791. Sender: compilers-sender@iecc.cambridge.ma.us
  5792. Organization: ParcPlace Boulder
  5793. References:  <93-04-012@comp.compilers>
  5794. Date: Mon, 5 Apr 1993 00:01:56 GMT
  5795. Approved: compilers@iecc.cambridge.ma.us
  5796.  
  5797. >Is there an algorithm to convert shell-expressions into regular
  5798. >expressions?  (i.e. generate the string ".*[.]c" from the input "*.c")
  5799.  
  5800. It is fairly straightforward to do this conversion for /bin/sh.  Just
  5801. change '*' to '.*' and quote all the meta characters that have no special
  5802. meaning in /bin/sh, but do in the regexp package you are using.  However,
  5803. if you wanted to do /bin/csh shell expressions, then you'll find that
  5804. things like "*.{c,C,H,h,cf}" cause problems and cause the output string
  5805. length to grow wildly.
  5806.  
  5807. >In the same vein, is there an algorithm to generate case-independent
  5808. >regular expressions from nomal ones?  (i.e. generate the string
  5809. >"[aA][bB][cC][eEfFgG]*" from the input "abc[efg]*")
  5810.  
  5811. I think this also falls withing the relm of brute force algorithms.  Since
  5812. there are only two states (inside and outside of square brackets), a
  5813. single pass through the string, copying to a dest string should do the
  5814. trick.
  5815.  
  5816. Warner
  5817. -- 
  5818. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5819. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5820.  
  5821.  
  5822. From compilers Mon Apr  5 23:18:03 EDT 1993
  5823. Newsgroups: comp.compilers
  5824. Path: iecc!compilers-sender
  5825. From: kanze@us-es.sel.de (James Kanze)
  5826. Subject: Re: Regexps from shell wildcards
  5827. Message-ID: <93-04-019@comp.compilers>
  5828. Keywords: lex
  5829. Sender: compilers-sender@iecc.cambridge.ma.us
  5830. Organization: Compilers Central
  5831. References:  <93-04-012@comp.compilers> <93-04-018@comp.compilers>
  5832. Date: Mon, 5 Apr 1993 11:21:54 GMT
  5833. Approved: compilers@iecc.cambridge.ma.us
  5834.  
  5835. Warner Losh writes:
  5836.  
  5837. |> >Is there an algorithm to convert shell-expressions into regular
  5838. |> >expressions?  (i.e. generate the string ".*[.]c" from the input "*.c")
  5839.  
  5840. |> It is fairly straightforward to do this conversion for /bin/sh.  Just
  5841. |> change '*' to '.*' and quote all the meta characters that have no special
  5842. |> meaning in /bin/sh, but do in the regexp package you are using.
  5843.  
  5844. Plus, change '.' to '[.]', if not already in []'s, and '?' to '.'.
  5845. (Note that this will require some state to determine whether one is
  5846. already in []'s or not.)
  5847.  
  5848. |> However, if you wanted to do /bin/csh shell expressions, then you'll find
  5849. |> that things like "*.{c,C,H,h,cf}" cause problems and cause the output
  5850. |> string length to grow wildly.
  5851.  
  5852. What's wrong with "*.{c,C,H,h,cf}" becoming ".*[.]([c|C|H|h|cf)".  In
  5853. sum, just replace "{}" with "()", and the commas within it with '|'.
  5854. The output string doesn't grow at all.  (Of course, some of your older
  5855. regexp programs, like grep, can't handle '|'.)
  5856. --
  5857. James Kanze                             email: kanze@us-es.sel.de
  5858. GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
  5859. -- 
  5860. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5861. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5862.  
  5863.  
  5864. From compilers Mon Apr  5 23:19:50 EDT 1993
  5865. Xref: iecc comp.theory:5894 comp.databases:19193 comp.compilers:4478
  5866. Newsgroups: comp.theory,comp.databases,comp.compilers
  5867. Path: iecc!compilers-sender
  5868. From: assmann@karlsruhe.gmd.de (Uwe Assmann)
  5869. Subject: Graphs generated by predicates
  5870. Message-ID: <93-04-020@comp.compilers>
  5871. Followup-To: comp.theory
  5872. Keywords: theory, question
  5873. Sender: compilers-sender@iecc.cambridge.ma.us
  5874. Organization: GMD Forschungsstelle an der Universitaet Karlsruhe
  5875. Date: Mon, 5 Apr 1993 13:28:03 GMT
  5876. Approved: compilers@iecc.cambridge.ma.us
  5877.  
  5878. I wonder whether there is a classification of graphs with different edge
  5879. colors based on the 'generating predicates'.
  5880.  
  5881. By this I mean that a graph with different edge colors is described by its
  5882. vertices and its relations (which represent the edge colors); the
  5883. relations, however, can be described as binary predicates.  Regard the
  5884. famous 'ancestor example' which describes the transitive hull of the 'son'
  5885. relation:
  5886.  
  5887. ancestor(A,D) :- son(A,D).
  5888. ancestor(A,D) :- ancestor(A,A1), son(A1,D).
  5889.  
  5890. That means, that the ancestor-relation (ancestor-edges) can be defined in
  5891. terms of the son-relation, respectively the ancestor-graph in terms of the
  5892. son-graph. Now my question is: is there a classification of graphs that
  5893. takes into account, which form of predicates 'generate which forms of
  5894. graphs?
  5895. --
  5896. Uwe Assmann
  5897. GMD Forschungsstelle an der Universitaet Karlsruhe
  5898. Vincenz-Priessnitz-Str. 1
  5899. 7500 Karlsruhe GERMANY
  5900. Email: assmann@karlsruhe.gmd.de Tel: 0721/662255 Fax: 0721/6622968
  5901. -- 
  5902. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5903. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5904.  
  5905.  
  5906. From compilers Mon Apr  5 23:20:28 EDT 1993
  5907. Newsgroups: comp.compilers
  5908. Path: iecc!compilers-sender
  5909. From: macrakis@osf.org (Stavros Macrakis)
  5910. Subject: Re: Regexps from shell wildcards
  5911. Message-ID: <93-04-021@comp.compilers>
  5912. Keywords: lex
  5913. Sender: compilers-sender@iecc.cambridge.ma.us
  5914. Organization: OSF Research Institute
  5915. References: <93-04-012@comp.compilers> <93-04-018@comp.compilers>
  5916. Date: Mon, 5 Apr 1993 16:39:07 GMT
  5917. Approved: compilers@iecc.cambridge.ma.us
  5918.  
  5919. colas@opossum.inria.fr (Colas Nahaboo) asks for an algorithm to convert
  5920. shell-expressions into regular expressions.
  5921.  
  5922. Warner Losh <imp@Boulder.ParcPlace.COM> answers:
  5923.  
  5924.    Just change '*' to '.*' and quote all the meta characters...
  5925.  
  5926. You also need to "anchor" the beginning and end with "^" and "$", since
  5927. shell patterns must match the whole filename, and Unix regular expressions
  5928. match any substring.
  5929.  
  5930.    ...to do /bin/csh shell expressions, then you'll find that things like
  5931.    "*.{c,C,H,h,cf}" cause problems and cause the output string length
  5932.    to grow wildly.
  5933.  
  5934. "^.*\.(c|C|H|h|cf)$" causes no problems.  Of course, this requires
  5935. full regular expressions (egrep, emacs), not brain-dead subsets (grep,
  5936. ex).
  5937.  
  5938.     -s
  5939. -- 
  5940. Send compilers articles to compilers@iecc.cambridge.ma.us or
  5941. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  5942.  
  5943.  
  5944. From compilers Mon Apr  5 23:21:44 EDT 1993
  5945. Newsgroups: comp.compilers
  5946. Path: iecc!compilers-sender
  5947. From: Paul Robinson <tdarcos@mcimail.com>
  5948. Subject: Serendipitious Compiler Stuff
  5949. Message-ID: <93-04-022@comp.compilers>
  5950. Keywords: tools, FTP
  5951. Sender: compilers-sender@iecc.cambridge.ma.us
  5952. Reply-To: Paul Robinson <tdarcos@mcimail.com>
  5953. Organization: Compilers Central
  5954. Date: Mon, 5 Apr 1993 15:35:42 GMT
  5955. Approved: compilers@iecc.cambridge.ma.us
  5956.  
  5957. The term "serendipity" refers to the finding of something of value when
  5958. looking for something else. (Like striking oil while digging for gold.)
  5959.  
  5960. While looking for something else on Oak.Oakland.Edu (a Unix mirror site
  5961. for wsmr-simtel20.army.mil), I found some other things in the FTP
  5962. directories, which is compiler related.  The following items are ones I
  5963. found of interest (unimportant replies deleted):
  5964.  
  5965. % ftp oak.oakland.edu
  5966. user anonymous
  5967. pass e-mail@address.domain
  5968. ftp> cd pub/unix-c/languages
  5969. ftp> dir
  5970. drwxr-xr-x  2 1716     0             512 Jan 23  1991 ada
  5971. drwxr-xr-x  2 1716     0             512 Jan 23  1991 assembler
  5972. drwxr-xr-x  2 1716     0             512 Jan 23  1991 basic
  5973. drwxr-xr-x  2 1716     0            2560 Jan 23  1991 c
  5974. drwxr-xr-x  2 1716     0             512 Apr 28  1992 cplusplus
  5975. drwxr-xr-x  2 1716     0             512 Jan 23  1991 forth
  5976. drwxr-xr-x  2 1716     0             512 Jan 23  1991 fortran
  5977. drwxr-xr-x  2 1716     0             512 Jan 23  1991 fp
  5978. drwxr-xr-x  2 1716     0             512 Jan 23  1991 icon
  5979. drwxr-xr-x  2 1716     0             512 Jan 23  1991 lisp
  5980. drwxr-xr-x  2 1716     0             512 Jan 23  1991 logo
  5981. drwxr-xr-x  2 1716     0             512 Jan 23  1991 modula-2
  5982. drwxr-xr-x  2 1716     0             512 Jan 23  1991 occam
  5983. drwxr-xr-x  2 1716     0             512 Jan 23  1991 ops5
  5984. drwxr-xr-x  2 1716     0             512 Jan 23  1991 pascal
  5985. drwxr-xr-x  2 1716     0             512 Jan 23  1991 prolog
  5986. drwxr-xr-x  2 1716     0             512 Jan 23  1991 smalltalk
  5987. drwxr-xr-x  2 1716     0             512 Jan 23  1991 sr
  5988. ftp> dir assembler
  5989. -rw-r--r--  1 1716     0           21678 Mar  3  1989 asm80.tar-z
  5990. -rw-r--r--  1 1716     0           22548 Mar  3  1989 cross6502.tar-z
  5991. -rw-r--r--  1 1716     0           29323 Mar  3  1989 cross6809.tar-z
  5992. -rw-r--r--  1 1716     0           13651 Mar  3  1989 dis6502.tar-z
  5993. -rw-r--r--  1 1716     0           38833 Mar  3  1989 dis68000.tar-z
  5994. -rw-r--r--  1 1716     0           60509 Mar  3  1989 dis68k.tar-z
  5995. -rw-r--r--  1 1716     0           36112 Mar  3  1989 dis88.tar-z
  5996. -rw-r--r--  1 1716     0           45217 Mar  3  1989 disasm.tar-z
  5997. -rw-r--r--  1 1716     0           22287 Feb  2  1990 disz80.tar-z
  5998. -rw-r--r--  1 1716     0           40213 Mar  3  1989 genasm.tar-z
  5999. -rw-r--r--  1 1716     0           29053 Mar  3  1989 hp41.tar-z
  6000. -rw-r--r--  1 1716     0           48624 Mar  3  1989 zmac.tar-z
  6001. ftp> dir basic
  6002. -rw-r--r--  1 1716     0          111041 Mar  3  1989 basic.tar-z
  6003. ftp> dir pascal
  6004. -rw-r--r--  1 1716     0            9437 Mar  3  1989 iso-pascal.tar-z
  6005. -rw-r--r--  1 1716     0           18332 Mar  3  1989 karel.tar-z
  6006. -rw-r--r--  1 1716     0          552692 May 17  1990 p2c.tar-z
  6007. -rw-r--r--  1 1716     0           16479 Mar  3  1989 pstrings.tar-z
  6008. -rw-r--r--  1 1716     0          185937 Mar  3  1989 ptoc.tar-z
  6009. -rw-r--r--  1 1716     0           69213 Mar  3  1989 software-tools.tar-z
  6010. -rw-r--r--  1 1716     0           43187 Mar  3  1989 turbo-tools.tar-z
  6011. ftp> dir fortran
  6012. -rw-r--r--  1 1716     0          414721 Oct 30  1990 f2c.tar-z
  6013. -rw-r--r--  1 1716     0          203613 May 17  1990 floppy.tar-z
  6014. -rw-r--r--  1 1716     0            9978 Mar  3  1989 fxref.tar-z
  6015. -rw-r--r--  1 1716     0           49162 Mar  3  1989 prep.tar-z
  6016. -rw-r--r--  1 1716     0           34723 Aug 30  1990 psdraw.tar-z
  6017. -rw-r--r--  1 1716     0           22888 Mar  3  1989 ratfor.tar-z
  6018.  
  6019. The stuff in the "C" directory appears to mostly be libraries for C
  6020. programs.  The "p2c.tar-z" and "f2c.tar-z" files are the Pascal to C and
  6021. Fortran to C programs.  I have picked up the Basic one (basic.tar-z) and
  6022. it claims to be a public domain version of DEC's MU-Basic with Microsoft
  6023. Basic mixed together.  (MU Basic was written in PDP-11 assembler; I've
  6024. seen it.)
  6025.  
  6026. So some of these files may be of interest to people wanting to understand
  6027. how compilers work.
  6028.  
  6029. Note that these files end in ".z" NOT ".Z" so you need GNUZIP to decompress
  6030. them, NOT compress.  Note this is not the ZIP format; GNUZIP is the GNU
  6031. version of Compress, only it creates files different from Compress (but it
  6032. will also extract Compress' ".Z" files, or so it claims).
  6033. -----
  6034. Paul Robinson -- TDARCOS@MCIMAIL.COM
  6035. -- 
  6036. Send compilers articles to compilers@iecc.cambridge.ma.us or
  6037. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  6038.  
  6039.  
  6040. From compilers Mon Apr  5 23:24:03 EDT 1993
  6041. Newsgroups: comp.compilers
  6042. Path: iecc!compilers-sender
  6043. From: Todd Hodes <tdh6t@helga3.acc.virginia.edu>
  6044. Subject: Re: Wanted: Regular Expression -> Finite Automata  C code =-
  6045. Message-ID: <93-04-023@comp.compilers>
  6046. Keywords: lex, question, comment
  6047. Sender: compilers-sender@iecc.cambridge.ma.us
  6048. Organization: University of Virginia Computer Science Department
  6049. Date: Mon, 5 Apr 1993 17:05:45 GMT
  6050. Approved: compilers@iecc.cambridge.ma.us
  6051.  
  6052.     I wanted to use the code in Sedgewick's 'Algorithms in C' book,
  6053. but found the following bug:
  6054.  
  6055.     When it parses REs of the form a(b+c), i.e. a terminal concatenated
  6056. with a union clause, the output is as follows:
  6057.  
  6058.  State :  0  1  2  3  4  5  6
  6059.  Char  :     a  b        c  -
  6060.  Next1 :  1  2  3  6  5  6  0
  6061.  Next2 :  1  2  3  6  2  6  0
  6062.  
  6063.         Weeeeell, this ain't quite right.  State #1 should go on an input
  6064. of "a" to state #4 in addition to or instead of state #2.
  6065.  
  6066.     Anyone with an idea how to salvage his code or new code would be quite
  6067. a savior.  This is for a technical report to be given to the world before
  6068. summer.  It is a teaching tool implementing Hopcraft and Ullmans RE ->
  6069. NFA-w-epsilons -> NFA -> DFA "circle of equivalence" transforms with a
  6070. graphical interface in SUIT under X.  Everything works except Sedgewick's
  6071. code, and I dread rewriting it, figuring that if Sedgewick got it wrong,
  6072. it must be HARD! (I haven't even found his bug yet.)  I already tried
  6073. writing it once (iteratively, even).  Figures that the only code I steal
  6074. doesn't work. :)
  6075.  
  6076. I've already had the following ideas tossed at me:
  6077.  
  6078.     1)  Use Henry Spencer's regexp   [not exactly what I need -
  6079.         just union, concatenation and closure is fine]
  6080.  
  6081.     2)  Pillage source from Unix utilities (flex, lex, grep)
  6082.         [ughh -- haven't tried this yet... again, full Unix REs
  6083.         are too much]
  6084.  
  6085.     3)  Give up  ;>
  6086.  
  6087. (Thanks to Jonathan A. Chandross <jac@yoko.rutgers.edu> for the pointer to
  6088. this group and some additional info about how bugs have been found in the
  6089. code before and posted here.)
  6090.  
  6091. Thanks,
  6092.  
  6093. T.
  6094. --
  6095. Todd Hodes, tdh6t@virginia.edu
  6096. [This came up last month, but without a whole lot of helpful suggestions.
  6097. -John]
  6098. -- 
  6099. Send compilers articles to compilers@iecc.cambridge.ma.us or
  6100. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  6101.  
  6102.  
  6103. From compilers Mon Apr  5 23:27:19 EDT 1993
  6104. Newsgroups: comp.compilers
  6105. Path: iecc!compilers-sender
  6106. From: "Paul Purdom" <pwp@cs.indiana.edu>
  6107. Subject: Semantic Actions and LR(k)
  6108. Message-ID: <93-04-024@comp.compilers>
  6109. Keywords: LR(1), parse
  6110. Sender: compilers-sender@iecc.cambridge.ma.us
  6111. Organization: Computer Science, Indiana University
  6112. References: <93-04-008@comp.compilers> <93-04-010@comp.compilers>
  6113. Date: Mon, 5 Apr 1993 17:45:48 GMT
  6114. Approved: compilers@iecc.cambridge.ma.us
  6115.  
  6116. I hear that there has been some discussion of LR(k) parsing and semantic
  6117. action routines concerning the question of where one can place calls to
  6118. the routines without causing parsing difficulties.
  6119.  
  6120. People interested in this question may wish to see the article Semantic
  6121. Routines and LR(k) Parsers by Cynthia Brown and myself, Acta Informatica
  6122. 14 (1980) p299-315.
  6123.  
  6124. One might wish to call a routine before the first symbol of the right side
  6125. of a production (thereby simulating LL(k) with an LR(k) parser), or after
  6126. the i-th symbol for any i up to an including the length of the production.
  6127. The above paper shows that each position is either:
  6128.  
  6129. 1. Forbidden, the grammar is no longer parseable (with an LR(k) parser) if a
  6130.    routine is called there. The only forbidden positions are the positions
  6131.    zero of left recursive productions.
  6132.  
  6133. 2. Contingent, the grammar is parseable provided the same routine is called
  6134.    at certain other positions in the grammar.
  6135.  
  6136. 3. Free, the grammar is parseable whether or not the same routine is called
  6137.    at other positions.
  6138.  
  6139. The paper has an algorithm for classifying positions.
  6140.  
  6141. A more refined analysis has been done by Michael R. Anderson. The last I
  6142. knew (1992), his email address was mra@opal.idbsu.edu.
  6143. -- 
  6144. Send compilers articles to compilers@iecc.cambridge.ma.us or
  6145. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  6146.  
  6147.  
  6148. From compilers Mon Apr  5 23:28:23 EDT 1993
  6149. Newsgroups: comp.compilers
  6150. Path: iecc!compilers-sender
  6151. From: mauney@csljon.csl.ncsu.edu (Jon Mauney)
  6152. Subject: Re: Semantic actions in LR parser
  6153. Message-ID: <93-04-025@comp.compilers>
  6154. Keywords: LR(1), parse
  6155. Sender: compilers-sender@iecc.cambridge.ma.us
  6156. Organization: NCSU
  6157. References: <93-04-008@comp.compilers> <93-04-014@comp.compilers>
  6158. Date: Mon, 5 Apr 1993 17:39:52 GMT
  6159. Approved: compilers@iecc.cambridge.ma.us
  6160.  
  6161.  
  6162. roy@prism.gatech.edu (Roy Mongiovi) writes:
  6163. >LR parsers can only perform semantic actions when the recognize a handle
  6164. >... you can stick in epsilon productions whose only purpose is to cause
  6165. >semantic actions.
  6166.  
  6167. karsten@tfl.dk (Karsten Nyblad) writes:
  6168. >...  So, you can allow for actions to be executed when you push a terminal or
  6169. >nonterminal and that brings you to a state that has only one item in kernel.
  6170. >Even that can be generalized. ...
  6171.  
  6172. These are the same thing.  Creating a nonterminal, with an epsilon
  6173. production, for each action, and inserting them at the places Nyblad
  6174. suggests will not cause parse conflicts (and inserting them in places he
  6175. implicitly disallows will cause conflicts).  It is simply a matter of
  6176. syntactic sugar whether the tool does this for you, or makes you do it
  6177. manually. (There is also the question of whether the tool can recongnize
  6178. that two actions are identical.)
  6179. --
  6180. Jon Mauney                   mauney@csc.ncsu.edu
  6181. Mauney Computer Consulting   (919)828-8053
  6182. -- 
  6183. Send compilers articles to compilers@iecc.cambridge.ma.us or
  6184. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  6185.  
  6186.  
  6187. From compilers Mon Apr  5 23:29:53 EDT 1993
  6188. Newsgroups: comp.compilers
  6189. Path: iecc!compilers-sender
  6190. From: henry@zoo.toronto.edu (Henry Spencer)
  6191. Subject: Re: Regexps from shell wilcards
  6192. Message-ID: <93-04-026@comp.compilers>
  6193. Keywords: lex
  6194. Sender: compilers-sender@iecc.cambridge.ma.us
  6195. Organization: U of Toronto Zoology
  6196. References: <93-04-012@comp.compilers>
  6197. Date: Mon, 5 Apr 1993 20:57:57 GMT
  6198. Approved: compilers@iecc.cambridge.ma.us
  6199.  
  6200. colas@opossum.inria.fr (Colas Nahaboo) writes:
  6201. >Is there an algorithm to convert shell-expressions into regular
  6202. >expressions?  (i.e. generate the string ".*[.]c" from the input "*.c")
  6203.  
  6204. The mapping is fairly trivial, but depends on the exact shell syntax you
  6205. are interested in.  In general, all the constructs are present in both
  6206. forms, and you can just map construct-by-construct, but you have to watch
  6207. details.  For example, mapping shell "*" to regexp ".*" is wrong, because
  6208. shell "*" does not match "/".  If you write down the exact rules for the
  6209. shell syntax you're using, transforming it to regular expressions is
  6210. typically easy.
  6211.  
  6212. >In the same vein, is there an algorithm to generate case-independent
  6213. >regular expressions from nomal ones?  (i.e. generate the string
  6214. >"[aA][bB][cC][eEfFgG]*" from the input "abc[efg]*")
  6215.  
  6216. Again, the real question is defining what you mean by "case-independent
  6217. regular expression".  It's not trivial; does [^x]y match Xy?  As I recall,
  6218. those of us on the POSIX.2 regular-expressions working group noticed this
  6219. question too late, and the standard as shipped will be rather vague on the
  6220. subject.  Our informal conclusion, which we hope will make it into an
  6221. eventual tidying-up of the standard, was that the right way for
  6222. case-independent regular expressions to act is based on a model in which
  6223. case distinctions vanish from the alphabet.  You can't take that too
  6224. literally or complexities arise, but it's a good guide.  So no,
  6225. case-independent [^x]y does not match Xy, because the [^x] covers all
  6226. kinds of X's, be they uppercase or lowercase.
  6227.  
  6228. Again, once you have defined what you're talking about, implementation
  6229. is easy.  For the case-distinctions-vanish model, any literal letter x
  6230. becomes [xX], and the contents of a bracket expression [xyz] are augmented
  6231. with any case counterparts of the things in it, giving [xyzXYZ].  The hard
  6232. thing to do in a portable way, actually, is to find out which characters
  6233. have case counterparts and what they are.
  6234. --
  6235. Henry Spencer @ U of Toronto Zoology, henry@zoo.toronto.edu  utzoo!henry
  6236. -- 
  6237. Send compilers articles to compilers@iecc.cambridge.ma.us or
  6238. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  6239.  
  6240.  
  6241. From compilers Tue Apr  6 10:27:01 EDT 1993
  6242. Newsgroups: comp.compilers
  6243. Path: iecc!compilers-sender
  6244. From: assmann@karlsruhe.gmd.de (Uwe Assmann)
  6245. Subject: SUMMARY: Loop transformations with unimodular matrices
  6246. Message-ID: <93-04-027@comp.compilers>
  6247. Keywords: optimize, summary, theory
  6248. Sender: compilers-sender@iecc.cambridge.ma.us
  6249. Organization: GMD Forschungsstelle an der Universitaet Karlsruhe
  6250. References: <93-04-020@comp.compilers>
  6251. Date: Tue, 6 Apr 1993 10:48:59 GMT
  6252. Approved: compilers@iecc.cambridge.ma.us
  6253.  
  6254. Here comes a summary of answers concerning the description of loop
  6255. transformations with unimodular matrices. Thanks to all who have
  6256. responded.
  6257.  
  6258. ------------------------------------------------------------------------------
  6259. From: pugh@cs.umd.edu (Bill Pugh)
  6260.  
  6261. Actually, it was M. E. Wolf, not M. Wolfe (confusing, isn't it?).  Here
  6262. are a couple of references on the subject.
  6263.  
  6264. U. Banerjee.
  6265.  Unimodular transformations of double loops.
  6266.  In {\em Proc. of the 3rd Workshop on Programming Languages and
  6267.   Compilers for Parallel Computing}, Irvine, CA, August 1990.
  6268.  
  6269. Paul Feautrier.
  6270.  Some efficient solutions to the affine scheduling problem, part i,
  6271.   one-dimensional time.
  6272.  Technical Report 92.28, IBP/MASI, April 1992.
  6273.  
  6274. Paul Feautrier.
  6275.  Some efficient solutions to the affine scheduling problem, part ii,
  6276.   multi-dimensional time.
  6277.  Technical Report 92.78, IBP/MASI, Oct 1992.
  6278.  
  6279. Wayne Kelly and William Pugh,
  6280.  Generating Schedules and Code within a
  6281.         Unified Reordering Transformation Framework,
  6282.   Technical Report CS-TR-2995,
  6283.   Dept. of Computer Science, University of Maryland, College Park,
  6284.   November, 1992
  6285.  
  6286.  
  6287. K. G. Kumar, D. Kulkarni, and A. Basu.
  6288.  Deriving good transformations for mapping nested loops on hieracical
  6289.   parallel machines in polynomial time.
  6290.  In {\em Proc. of the 1992 International Conference on
  6291.   Supercomputing}, July 1992.
  6292.  
  6293. Wei Li and Keshav Pingali.
  6294.  A singular loop transformation framework based on non-singular
  6295.   matrices.
  6296.  In {\em 5th Workshop on Languages and Compilers for Parallel
  6297.   Computing}, Yale University, August 1992.
  6298.  
  6299. Lee-Chung Lu.
  6300.  A unified framework for systematic loop transformations.
  6301.  In {\em Proceedings of Third ACM SIGPLAN Symp. on the Principles \&
  6302.   Practice of Parallel Programming}, April 1991.
  6303.  
  6304. William Pugh.
  6305.  Uniform techniques for loop optimization.
  6306.  In {\em 1991 International Conference on Supercomputing}, pages
  6307.   341--352, Cologne, Germany, June 1991.
  6308.  
  6309. J. Ramanujam.
  6310.  Non-unimodular transformations of nested loops.
  6311.  In {\em Supercomputing `92}, November 1992.
  6312.  
  6313. Vivek Sarkar and Radhika Thekkath.
  6314.  A general framework for iteration-reordering loop transformations.
  6315.  In {\em ACM SIGPLAN'92 Conference on Programming Language Design and
  6316.   Implementation}, San Francisco, California, Jun 1992.
  6317.  
  6318. Michael E. Wolf and Monica S. Lam.
  6319.  A data locality optimizing algorithm.
  6320.  In {\em ACM SIGPLAN'91 Conference on Programming Language Design and
  6321.   Implementation}, 1991.
  6322.  
  6323. Michael E. Wolf and Monica S. Lam.
  6324.  A loop transformation theory and an algorithm to maximize
  6325.   parallelism.
  6326.  In {\em IEEE Transactions on Parallel and Distributed Systems}, July
  6327.   1991.
  6328.  
  6329. ------------------------------------------------------------------------------
  6330.  
  6331. From: wak@cs.UMD.EDU (Wayne Kelly)
  6332.  
  6333. @inproceedings{Ban90,
  6334.         author = "U. Banerjee",
  6335.         title = "Unimodular Transformations of Double Loops",
  6336.         booktitle = "Proc. of the 3rd Workshop on Programming Languages and
  6337.                 Compilers for Parallel Computing",
  6338.         month = aug,
  6339.         year = 1990,
  6340.         address = "Irvine, CA" }
  6341.  
  6342. @INPROCEEDINGS{WL91,
  6343.     author = {Michael E. Wolf and Monica S. Lam},
  6344.     title = {A Data Locality Optimizing Algorithm},
  6345.     booktitle = {ACM SIGPLAN'91 Conference on Programming Language
  6346.     Design and Implementation},
  6347.     year = 1991
  6348.     }
  6349.  
  6350. @INPROCEEDINGS{WL91b,
  6351.     author = {Michael E. Wolf and Monica S. Lam},
  6352.     title = {A loop transformation theory and an algorithm to maximize
  6353.     parallelism}, 
  6354.     booktitle = {IEEE Transactions on Parallel and Distributed Systems},
  6355.     month = {July},
  6356.     year = 1991
  6357.     }
  6358.  
  6359. Unimodular transformations is a unified framework that is able to describe
  6360. any transformation that can be obtained by compositions of loop
  6361. interchange, loop skewing, and loop reversal.  Unfortunately, unimodular
  6362. transformations are limited by two facts: they can only be applied to
  6363. perfectly nested loops, and all statements in the loop nest are
  6364. transformed in the same way. They can therefore not represent some
  6365. important transformations such as loop fusion, loop distribution and
  6366. statement reordering.
  6367.  
  6368. We have developed a framework that generalizes unimodular transformations.
  6369. Our framework can represent a much broader set of reordering
  6370. transformations, including any transformation that can be obtained from
  6371. some combination of: loop interchange, loop reversal, loop skewing,
  6372. statement reordering, loop distribution, loop fusion, loop scaling, loop
  6373. alignment, index set splitting, loop blocking, loop interleaving, loop
  6374. coalescing.  I would be happy to send you a copy of our paper if you are
  6375. interested.
  6376.  
  6377.  
  6378. ---------------------------------------------------------------------------
  6379. From: wei@cs.cornell.EDU (Wei Li)
  6380.  
  6381. We have a matrix-oriented approach to loop transformations that uses
  6382. non-singular matrices to represent loop transformations. Non-singular
  6383. matrices generalize the unimodular approach (unimodular matrices are a
  6384. special case of non-singular matrices in which the determinant is 1 or
  6385. -1).  Some important transformations such as loop tiling can only be
  6386. modeled by non-singular matrices.  Furthermore, we provide a completion
  6387. algorithm that makes the theory easier to use in practice.  In
  6388. transformations for parallelism and data locality, it is very useful to
  6389. have such completion algorithm.  Our work was presented at the 5th
  6390. Compiler Workshop at Yale last year.  A journal version is to appear soon
  6391. in IJPP.
  6392.  
  6393. We have used the non-singular matrix framework to develop optimizations
  6394. for data locality in our compiler for NUMA parallel machines.  You can
  6395. find how the transformation matrix is constructed automatically.  The
  6396. algorithms are in the paper that appeared in ASPLOS V (ACM SIGPLAN
  6397. Notices, Vol 27, Number 9, Sep.  1992).
  6398.  
  6399. The papers can also be found via ftp from Cornell (ftp.cs.cornell.edu,
  6400. pub/TyphoonCompiler/papers-ps/).
  6401.  
  6402. file:   framework.ps
  6403.  
  6404.         "A Singular Loop Transformation Framework
  6405.          Based on Non-singular Matrices"
  6406.            by Wei Li and Keshav Pingali
  6407.  
  6408. file:   asplos92.ps
  6409.  
  6410.         "Access Normalization: Loop Restructuring for NUMA Compilers"
  6411.            by Wei Li and Keshav Pingali
  6412.  
  6413. file:   pnuma.ps
  6414.  
  6415.         "Loop Transformations for NUMA Machines"
  6416.            by Wei Li and Keshav Pingali
  6417.            SIGPLAN Notices, January 1993
  6418.  
  6419. -- Wei Li
  6420. Department of Computer Science
  6421. Cornell University
  6422. Ithaca, NY 14853
  6423. ---------------------------------------------------------------------------
  6424. From: mehrotra@csrd.uiuc.edu (Sharad Mehrotra)
  6425.  
  6426. Those are excellent pointers, but unimodular transformations are only one
  6427. aspect of the larger problem of automatic program parallelization. If you
  6428. are just getting started in the area, you might find the following CSRD
  6429. report (also to appear soon in the Proceedings of the IEEE) useful:
  6430.  
  6431.     Banerjee, U., Eigenman, R., Nicolau, A., and Padua, D.,
  6432.     "Automatic Program Parallelization", CSRD TR 1250, November 1992.
  6433.  
  6434. The report contains a timely survey of the field and a bibliography with
  6435. 161 citations.
  6436.  
  6437. Many CSRD Tech Reports are available for anonymous ftp from host
  6438. sp2.csrd.uiuc.edu (128.174.153.4) in directory CSRD_Info/reports. We'll
  6439. try and arrange to put the PostScript for this report there soon. If it's
  6440. not available in a few days, email reinhart@csrd.uiuc.edu, and ask for a
  6441. paper copy by snail mail.
  6442.  
  6443. ---------------------------------------------------------------------------
  6444. From: dsehr@gomez.intel.com (David Sehr)
  6445.  
  6446. A colleague here at Intel has been working on exactly that problem for
  6447. several years.  His name is Utpal Banerjee, and he has recently published
  6448. a book describing the approach you mention (using unimodular matrices for
  6449. dependence testing and transformation).  The full info:
  6450.     Loop Transformations for Restructuring Compilers: the Foundations
  6451.     Utpal Banerjee
  6452.     Kluwer Academic Publishers
  6453.     ISBN: 0-7923-9318-X
  6454.  
  6455. Other possibilities to pursue are the recent papers of William Pugh of the
  6456. University of Maryland (pugh@cs.umd.edu), and Paul Feautrier of the
  6457. University of P. et M. Curie (feautrier@masi.ibp.fr).
  6458.  
  6459. David C. Sehr, Intel Corporation
  6460. 2200 Mission College Blvd., M/S RN6-18
  6461. Santa Clara, CA 95052-8119
  6462. ---------------------------------------------------------------------------
  6463. From: paik@mlo.dec.com (Samuel S. Paik)
  6464.  
  6465. Access Normalization: Loop Restructuring for NUMA Compilers.  Wei Li,
  6466. Keshav Pingali.  Proceedings of the Fifth International Conference on
  6467. Architectural Support for Programming Languages and Operating Systems,
  6468. SIGPLAN Notices, Vol. 27, No. 9, Sept 1992, pp. 285-295.  ACM.
  6469.  
  6470.   Generalizes Banerjee's work on unimodular matrices for modeling
  6471.   loop transformations to invertable matrices, and applies this to
  6472.   restructuring loops for NUMA multiprocessors.  Also available as a
  6473.   Cornell University CS technical report.
  6474.  
  6475. ---------------------------------------------------------------------------
  6476. From: Francois IRIGOIN <irigoin@cri.ensmp.fr>
  6477.  
  6478. Some loop transformations are equivalent to a change of basis. To preserve
  6479. the number of iterations, the change of basis matrix has to be unimodular.
  6480. This idea has been around implictly for at least 6 years.  Utpal Banerjee
  6481. has a paper on the subject. He's also written a book.  Perhaps, you should
  6482. get in touch with him: <banerjee@csrd.uiuc.edu>.
  6483.  
  6484. Non-unimodular matrices are useful for tiling transformations.
  6485.  
  6486. Some loop transformations cannot be put in this framework: loop
  6487. distribution and loop alignment are good examples.
  6488.  
  6489. I'd like to know why you are interested in this subject. We've been
  6490. active in this field for many years but did not really manage to get in
  6491. touch with people in Germany, except the SUPERB team, Hans Zima/Michael
  6492. Gerndt.
  6493.  
  6494. Also, there is a Workshop in June in Germany (Dagsthul) about scheduling.
  6495. Simple schedules lead to matrix transformations, complex ones cover the
  6496. other loop transformation.
  6497.  
  6498. Francois Irigoin                tel. +33 1 64 69 48 48
  6499. Centre de Recherche en Informatique        fax. +33 1 64 69 47 09
  6500. Ecole des Mines de Paris            e-mail: irigoin@cri.ensmp.fr
  6501. 35 rue Saint Honore                    irigoin@fremp11.bitnet
  6502. 77300 FONTAINEBLEAU
  6503. FRANCE
  6504. ------------------------------------------------------------------------------
  6505. From: jrbd@craycos.com (James Davies)
  6506.  
  6507. I have a paper here for ASPLOS V (1992), published by ACM, which seems
  6508. related; it's called "Access Normalization: Loop restructuring for NUMA
  6509. Compilers", by Wei Li and Keshav Pingali of Cornell University, and
  6510. discusses using invertible matrices to model loop transformations.  They
  6511. refer to a paper by Utpal Banerjee in Proceedings of the Workshop on
  6512. Advances in Languages and Compilers for Parallel Processing, August 1990,
  6513. called "Unimodular Transformations of Double Loops", which is supposed to
  6514. have also used matrices to model loop transforms.  (I don't know who
  6515. published this workshop, all I have is the reference in the Li-Pingali
  6516. paper.)
  6517.  
  6518. ------------------------------------------------------------------------------
  6519. From: vadik@cs.UMD.EDU (Vadim Maslov)
  6520.  
  6521. Ask Dr. Pugh (pugh@cs.umd.edu) and/or Mr. Kelly (wak@cs.umd.edu) from
  6522. University of Maryland.  They have a theory that goes beyond unimodular
  6523. transformations.  There are a couple of papers on it which are
  6524. electronically available.
  6525.  
  6526. ------------------------------------------------------------------------------
  6527. From: Joe Hummel <jhummel@esp.ICS.UCI.EDU>
  6528.  
  6529. Actually, I think it was Utpal Banerjee with his work on unimodular
  6530. transformations.  His new book, which is just being published, should have
  6531. lots of info on this.  Utpal also has a paper, I think it appeared in the
  6532. last year or two in the IEEE Trans on Parallel and Distributed Computing.
  6533.  
  6534. ------------------------------------------------------------------------------
  6535. From: Lode Nachtergaele <nachterg@imec.be>
  6536.  
  6537. M.E. Wolfe, M. Lam, "A loop transformation theory and an algorithm to
  6538. maximize parallelism", IEEE transactions on parallel and distributed
  6539. systems, Vol.2, October 1991
  6540.  
  6541. Look also to the work going on at the university of Maryland.  The papers
  6542. and reports can be ftp'ed from : ftp.cs.umd.edu
  6543.  
  6544. Lode Nachtergaele
  6545. IMEC V.Z.W.      
  6546. Kapeldreef 75    
  6547. 3001 Heverlee    
  6548. Belgium          
  6549. Phone : +32 (0)16 28.15.12
  6550. E-mail: nachterg@imec.be
  6551.  
  6552. ------------------------------------------------------------------------------
  6553. Yep. I found it in ACM SIGPLAN'91 Conference: p.30-45,
  6554. authors Michael E. Wolf (not Wolfe) and Monica S. Lam (Stanford Uni.)
  6555. --
  6556. Jan Jongejan                            email: jjan@cs.rug.nl
  6557. Dept. Comp.Sci.,
  6558. Univ. of Groningen,
  6559. Netherlands.
  6560. --
  6561. Uwe Assmann
  6562. GMD Forschungsstelle an der Universitaet Karlsruhe
  6563. Vincenz-Priessnitz-Str. 1
  6564. 7500 Karlsruhe GERMANY
  6565. Email: assmann@karlsruhe.gmd.de Tel: 0721/662255 Fax: 0721/6622968
  6566. -- 
  6567. Send compilers articles to compilers@iecc.cambridge.ma.us or
  6568. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  6569.  
  6570.  
  6571. From compilers Tue Apr  6 14:52:06 EDT 1993
  6572. Xref: iecc comp.arch:27674 comp.compilers:4486 comp.object:9795
  6573. Newsgroups: comp.arch,comp.compilers,comp.object
  6574. Path: iecc!compilers-sender
  6575. From: "Steven A. Moyer" <sam2y@server.cs.virginia.edu>
  6576. Subject: Utilization of Non-caching Access Instructions
  6577. Message-ID: <93-04-028@comp.compilers>
  6578. Originator: sam2y@koa.cs.Virginia.EDU
  6579. Keywords: optimize, architecture, GC, report, FTP
  6580. Sender: compilers-sender@iecc.cambridge.ma.us
  6581. Organization: University of Virginia Computer Science Department
  6582. References: <C4ppA5.BLx.1@cs.cmu.edu> <93-04-013@comp.compilers>
  6583. Date: Tue, 6 Apr 1993 14:22:32 GMT
  6584. Approved: compilers@iecc.cambridge.ma.us
  6585.  
  6586.  
  6587. In following up a thread on the utilization of non-caching load
  6588. instructions (ala i860) for implementing GC algorithms, I discussed a
  6589. general optimization for increasing effective memory bandwidth that
  6590. utilized such an instruction.  The techreports I cited contained some
  6591. older work and I received many requests to make available the newer
  6592. recently completed dissertation text.
  6593.  
  6594. I have made the complete text a technical report and have placed it in an
  6595. anonymous ftp directory located at uvacs.cs.virginia.edu. The report is
  6596. the compressed postscript file:
  6597.  
  6598.   pub/techreports/CS-93-18.ps.Z
  6599.  
  6600. I hope this information proves useful; comments are certainly welcome.
  6601. And yes, I've learned my lesson about posting references to older material
  6602. ;-)
  6603.  
  6604. Steve
  6605.  
  6606.  
  6607. -------------------------------------------------------------------------
  6608. Abstract:
  6609.  
  6610.               Access Ordering and Effective Memory Bandwidth
  6611.  
  6612.  
  6613. High-performance scalar processors are characterized by multiple pipelined
  6614. functional units that can be initiated simultaneously to exploit
  6615. instruction level parallelism.  For scientific codes, the performance of
  6616. these processors depends heavily on memory bandwidth.  To achieve peak
  6617. processor rate, data must be supplied to the arithmetic units at the peak
  6618. aggregate rate of consumption.
  6619.  
  6620. Access ordering, a loop optimization that reorders non-caching accesses to
  6621. better utilize memory system resources, is a compiler technology that
  6622. addresses the memory bandwidth problem for scalar processors executing
  6623. scientific codes.  For a given computation, memory architecture, and
  6624. memory device type, an access ordering algorithm determines a well-defined
  6625. interleaving of vector references that maximizes effective bandwidth.
  6626. Consequently, analytic models of performance can also be derived.
  6627.  
  6628. Access ordering is fundamentally different from, though complementary to,
  6629. both caching and access scheduling techniques that attempt to overlap
  6630. computation with memory latency.  Simulation results demonstrate that
  6631. for a given computation, access ordering can significantly increase
  6632. effective bandwidth over that achieved by the natural reference sequence.
  6633. --
  6634. Steve Moyer
  6635. Computer Science Department
  6636. University of Virginia
  6637. -- 
  6638. Send compilers articles to compilers@iecc.cambridge.ma.us or
  6639. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  6640.  
  6641.  
  6642. From compilers Tue Apr  6 17:25:27 EDT 1993
  6643. Newsgroups: comp.compilers
  6644. Path: iecc!compilers-sender
  6645. From: clark@zk3.dec.com (Chris Clark USSG)
  6646. Subject: Semantic actions in LR parser
  6647. Message-ID: <93-04-029@comp.compilers>
  6648. Keywords: LR(1), parse
  6649. Sender: compilers-sender@iecc.cambridge.ma.us
  6650. Organization: Compilers Central
  6651. References: <93-04-008@comp.compilers> <93-04-010@comp.compilers>
  6652. Date: Tue, 6 Apr 1993 15:26:32 GMT
  6653. Approved: compilers@iecc.cambridge.ma.us
  6654.  
  6655. It was asked.
  6656.  
  6657. > I am just wondering if we have to put all semantic actions on the tail
  6658. > parts of some productions for LR grammar instead of any positions in LL
  6659. > grammar?
  6660.  
  6661. Most LR parsers (i.e. yacc) introduce pseudo productions only because it
  6662. is convenient to do so.  It simplifies the LR engine, by allowing it to
  6663. fold the action selection into the reduction code.  It's actually a fairly
  6664. clever hack to recognize that you can simulate shift actions by
  6665. introducing pseude productions.  A similar hack gives you a "poor person's
  6666. ELR parser" allowing regular expressions on the RHS.  However, in both
  6667. cases, I feel there is a better way, which we used in our product,
  6668. Yacc++(R) and the Language Objects Library.
  6669.  
  6670. In, Yacc++, we model our LR engine as an abstract machine, and the
  6671. generator outputs "assembly language" for it.  Doing so, makes it
  6672. straight-forward to put actions with shifts as well as with reduces.
  6673.  
  6674. Essentially, as you are building your dotted items for a state, some of
  6675. them may include actions.  You just encode those actions as part of your
  6676. shift transitions.  If you model it right, it is fairly simple.  When you
  6677. build the dotted productions for a state, you are essentially simulating
  6678. running a bunch of LL parsers in parallel.  Thus, you can do anything in
  6679. an LR parser, that you can in an LL parser, except it's difficult to
  6680. program in recursive descent--because your programming language probably
  6681. does not allow running a bunch of routines in parallel and selecting the
  6682. one which succeeds.  (I guess recursive descent in prolog would work fine
  6683. aside from the backtracking overhead.)
  6684.  
  6685. One curious feature which falls out, is that if you can detect two actions
  6686. are the same you can execute the action even if the eventual reduces are
  6687. parts of two distinct productions.  That allows you to defer (and
  6688. eliminate) some conflicts.  (In our model, two actions are the same if
  6689. they are character for character the same string.)  Eliminating the pseudo
  6690. productions, also means smaller state tables.
  6691.  
  6692. I hope this helps.
  6693.  
  6694. Disclaimer, signature, et. al.
  6695.  
  6696. Chris Clark
  6697.  
  6698. I am biased in favor of parser generators and work for,
  6699.  
  6700. Compiler Resources, Inc.
  6701. 3 Proctor St.
  6702. Hopkinton, MA 01748
  6703. (508) 435-5016  fax: (508) 435-4847
  6704.  
  6705. For a technical literature packet (including a price list) send email
  6706. to: bz%compres@primerd.prime.com
  6707. -- 
  6708. Send compilers articles to compilers@iecc.cambridge.ma.us or
  6709. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  6710.  
  6711.  
  6712. From compilers Tue Apr  6 18:15:54 EDT 1993
  6713. Newsgroups: comp.compilers
  6714. Path: iecc!compilers-sender
  6715. From: keerthi@leland.Stanford.EDU (Keerthi Angammana)
  6716. Subject: Looking for a MATLAB parser
  6717. Message-ID: <93-04-030@comp.compilers>
  6718. Keywords: parse, question
  6719. Sender: compilers-sender@iecc.cambridge.ma.us
  6720. Organization: DSG, Stanford University, CA 94305, USA
  6721. Date: Tue, 6 Apr 1993 15:32:12 GMT
  6722. Approved: compilers@iecc.cambridge.ma.us
  6723.  
  6724. Hi,
  6725.  
  6726. Does anybody know if a parser (or at least a complete grammar) for
  6727. MATLAB is available for free someplace ?
  6728.  
  6729. thanks
  6730.  
  6731. -keerthi
  6732. -- 
  6733. Send compilers articles to compilers@iecc.cambridge.ma.us or
  6734. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  6735.  
  6736.  
  6737. From compilers Tue Apr  6 18:17:01 EDT 1993
  6738. Newsgroups: comp.compilers
  6739. Path: iecc!compilers-sender
  6740. From: Wei Li <wei@cs.cornell.EDU>
  6741. Subject: Re: Theory on loop transformations
  6742. Message-ID: <93-04-031@comp.compilers>
  6743. Keywords: theory, optimize
  6744. Sender: compilers-sender@iecc.cambridge.ma.us
  6745. Organization: Cornell University, CS Dept., Ithaca, NY
  6746. References:  <93-04-006@comp.compilers>
  6747. Date: Tue, 6 Apr 1993 16:25:16 GMT
  6748. Approved: compilers@iecc.cambridge.ma.us
  6749.  
  6750. assmann@karlsruhe.gmd.de (Uwe Assmann) writes:
  6751. |> I remember that ... Whenever a transformation is performed this amounts to
  6752. |> a matrix operation over the loop.
  6753.  
  6754. I find the matrix approach easy to use, and have successfully used it for
  6755. improving data locality on parallel machines with memory hierarchies such
  6756. as the BBN Butterfly and KSR1. All you need to do is to construct one
  6757. matrix that represents the transformation.
  6758.  
  6759. My question to folks who have implemented loop transformations:
  6760.  
  6761. if you have done it in the traditional way, i.e.  a sequence of loop
  6762. transformations as opposed to the matrix approach, what is your experience
  6763. about coming up with the right sequence of transformations to apply?
  6764.  
  6765. We can start with a small set of transformations such as loop interchange,
  6766. loop skewing, loop distribution/jamming etc.
  6767.  
  6768. Thanks.
  6769. --
  6770. Wei Li
  6771. Department of Computer Science
  6772. Cornell University
  6773. Ithaca, NY 14853
  6774. -- 
  6775. Send compilers articles to compilers@iecc.cambridge.ma.us or
  6776. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  6777.  
  6778.  
  6779. From compilers Tue Apr  6 18:17:50 EDT 1993
  6780. Newsgroups: comp.compilers
  6781. Path: iecc!compilers-sender
  6782. From: bourne-linda@CS.YALE.EDU (Linda Bourne)
  6783. Subject: Alan J. Perlis Symposium
  6784. Message-ID: <93-04-032@comp.compilers>
  6785. Keywords: conference
  6786. Sender: compilers-sender@iecc.cambridge.ma.us
  6787. Organization: Yale CS Mail/News Gateway
  6788. Date: Tue, 6 Apr 1993 10:20:14 GMT
  6789. Approved: compilers@iecc.cambridge.ma.us
  6790.  
  6791.             PROGRAMMING LANGUAGES:
  6792.             THE NEXT GENERATION
  6793.  
  6794.               Alan J. Perlis Symposium
  6795.  
  6796.              Sponsored by the
  6797.              Department of Computer Science
  6798.                 Yale University
  6799.  
  6800.                 April 29, 1993
  6801.  
  6802.  
  6803.     9:45    Opening Remarks
  6804.         Drew McDermott
  6805.         Chairman
  6806.  
  6807.     10:00   Languages for Multi-levelled Computers
  6808.         Used as Models, Tools, and Toys
  6809.         Peter Naur
  6810.         University of Copenhagen
  6811.  
  6812.     11:00   Concurrent Logic Programming:
  6813.         Past, Present, and Future
  6814.         Ehud Shapiro
  6815.         Weizmann Institute of Science
  6816.  
  6817.      1:30   Object-Oriented Programming and C++
  6818.         Bjarne Stroustrup
  6819.         AT&T Bell Laboratories
  6820.  
  6821.      2:30   Total Functional Programming
  6822.         David Turner
  6823.         University of Kent
  6824.  
  6825.     4:00    Panel Discussion
  6826.  
  6827. Following the panel discussion a public reception will be held at the
  6828. Department of Computer Science, Arthur K. Watson Hall.
  6829.  
  6830. All talks are free and open to the public.
  6831.  
  6832.     Yale School of Organization and Management
  6833.     135 Prospect Street
  6834.     Room B74
  6835.     Corner Sachem and Prospects Streets
  6836.     New Haven, Connecticut
  6837.  
  6838.     For information please call (203) 432-1246
  6839. -- 
  6840. Send compilers articles to compilers@iecc.cambridge.ma.us or
  6841. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  6842.  
  6843.  
  6844. From compilers Wed Apr  7 09:03:32 EDT 1993
  6845. Newsgroups: comp.compilers
  6846. Path: iecc!compilers-sender
  6847. From: gnb@leo.bby.com.au (Gregory N. Bond)
  6848. Subject: Re: Regexps from shell wildcards
  6849. Message-ID: <93-04-033@comp.compilers>
  6850. Keywords: lex
  6851. Sender: compilers-sender@iecc.cambridge.ma.us
  6852. Organization: Burdett, Buckeridge & Young, Melbourne, Australia
  6853. References: <93-04-012@comp.compilers> <93-04-018@comp.compilers>
  6854. Date: Tue, 6 Apr 1993 23:23:09 GMT
  6855. Approved: compilers@iecc.cambridge.ma.us
  6856.  
  6857. Warner Losh <imp@Boulder.ParcPlace.COM> writes:
  6858.    if you wanted to do /bin/csh shell expressions, then you'll find that
  6859.    things like "*.{c,C,H,h,cf}" cause problems and cause the output string
  6860.    length to grow wildly.
  6861.  
  6862. Worse than that, the csh {foo,bar} construct is not a file glob and
  6863. in general has semantics that cannot be duplicated with REs:
  6864.  - Order is preserved, so *.{h,c} is NOT the same as *.[hc]
  6865.  - Is expanded regardles of matches, so "echo {foo,bar}.c" will work
  6866.    whether or not foo.c or bar.c exist.
  6867.  
  6868. Of course, in any one application these may not be a problem, and
  6869. more-or-less mechanical conversion to (foo|bar) might be acceptable.
  6870.  
  6871. Just as a hint, here is some perl code I use to convert sh-type globs
  6872. to REs in a Perl package.  The input glob pattern is known to contain
  6873. no '/' characters (the handling of which is "interesting" recursion).
  6874.  
  6875. I make no promises about this, but it hasn't failed me yet.
  6876.  
  6877.   # Convert shell-style glob pattern to regex
  6878.   $pat =~ s/[.=<>+_\\-]/\\$&/g;
  6879.   $pat =~ s/\?/./g;
  6880.   $pat =~ s/\*/.*/g;
  6881.   # Hide leading . from wildcards
  6882.   $pat =~ s/^\.\*/[^.].*/; # .* -> [^.].*
  6883.   $pat =~ s/^\.([^\*])/[^.]$1/; # .x -> [^.]x
  6884.   $pat =~ s/^\*/[^.]*/;
  6885.   # Anchor the pattern
  6886.   $pat = "^$pat\$";
  6887.   # could do some optimising here, but leave it to perl!
  6888.   # e.g. "^.*" => ""
  6889.   #      ".*$" => ""
  6890. --
  6891. Gregory Bond <gnb@bby.com.au>
  6892. Burdett Buckeridge & Young Ltd Melbourne Australia
  6893. -- 
  6894. Send compilers articles to compilers@iecc.cambridge.ma.us or
  6895. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  6896.  
  6897.  
  6898. From compilers Wed Apr  7 09:04:08 EDT 1993
  6899. Newsgroups: comp.compilers
  6900. Path: iecc!compilers-sender
  6901. From: darte@ens.ens-lyon.fr (Alain Darte)
  6902. Subject: Re: SUMMARY: Loop transformations with unimodul
  6903. Message-ID: <93-04-034@comp.compilers>
  6904. Keywords: optimize, bibliography
  6905. Sender: compilers-sender@iecc.cambridge.ma.us
  6906. Reply-To: darte@ens.ens-lyon.fr
  6907. Organization: Ecole Normale Superieure de Lyon
  6908. References: <93-04-027@comp.compilers>
  6909. Date: Wed, 7 Apr 1993 08:24:19 GMT
  6910. Approved: compilers@iecc.cambridge.ma.us
  6911.  
  6912. Let me add some references that could be of interest concerning our work
  6913. here in Lyon.
  6914.  
  6915. Alain Darte. Regular partitioning for synthesizing fixed-size systolic
  6916. arrays.  {\em INTEGRATION, The VLSI Jounal}, 12:293--304, December 1991.
  6917.  
  6918. Alain Darte, Leonid Khachiyan and Yves Robert. Linear scheduling is nearly
  6919. optimal.  {\em Parallel Processing Letters} 1(2):73--81, December 1991.
  6920.  
  6921. Alain Darte and Yves Robert. Scheduling uniform loop nests. In R. Melhem
  6922. ed., {\em ISMM Conference on Parallel and Distributed Systems}, ISMM Press
  6923. (1992), 75-82.
  6924.  
  6925. Alain Darte, Tanguy Risset and Yves Robert. Loop nest scheduling and
  6926. transformations.  In J.J. Dongarra et B. Tourancheau eds., {\em
  6927. Environments and Tools for Parallel Scientific Computing}, Elsevier
  6928. Science Publishers (1993).
  6929.  
  6930. Alain Darte and Yves Robert. Mapping uniform loop nests onto distributed
  6931. memory architectures. Technical Report 93-03, LIP, January 1993.
  6932. Submitted. Available via anonymous ftp at lip.ens-lyon.fr in
  6933. /pub/LIP/RR/RR93 (file RR93-03.ps.Z).
  6934.  
  6935. Thanks to Uwe Assmann for his summary and the interesting references he
  6936. gives.
  6937. -- 
  6938. Send compilers articles to compilers@iecc.cambridge.ma.us or
  6939. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  6940.  
  6941.  
  6942. From compilers Wed Apr  7 21:50:41 EDT 1993
  6943. Newsgroups: comp.compilers
  6944. Path: iecc!compilers-sender
  6945. From: nachterg@imec.be (Lode Nachtergaele)
  6946. Subject: papers about loop transformations
  6947. Message-ID: <93-04-035@comp.compilers>
  6948. Keywords: optimize, bibliography, theory
  6949. Sender: compilers-sender@iecc.cambridge.ma.us
  6950. Reply-To: nachterg@imec.be
  6951. Organization: IMEC vzw Leuven
  6952. References: <93-04-020@comp.compilers>
  6953. Date: Wed, 7 Apr 1993 14:31:42 GMT
  6954. Approved: compilers@iecc.cambridge.ma.us
  6955.  
  6956. Hello world,
  6957.  
  6958. Uwe Assman asked for the precise pointer to the paper of M.E. Wolf, but
  6959. people mailed their reference list about this subject. So here is our list
  6960. of references.
  6961.  
  6962. 1. Loop data flow analysis.
  6963.  
  6964. a. group P.Featrier (Univ. P.et M.Curie, Paris): paper in International
  6965. Journal of Parallel Programming Vol. 20 No. 1, Feb. 1991 : "Dataflow
  6966. Analysis of Array and Scalar References" This handles formal data flow
  6967. analysis for sets of nested loops with manifest affine index expressions
  6968. including manifest conditions.  Equations are set up to calculate
  6969. dependencies which are solved with their PIP (Parametric Integer
  6970. Programming) package. The result could be written out in an applicative
  6971. form (but it is currently not).
  6972.  
  6973. b. group Pugh (Univ. of Maryland): papers in Supercomputing'91 and
  6974. Sigplan'92.  This also handles formal data flow analysis for sets of
  6975. nested loops with manifest affine index expressions but it can include
  6976. also user specified assertions on non-manifest conditions which make it
  6977. more general (though not general enough for all our applications).
  6978. Equations are set up to check dependencies which are passed to their
  6979. "omega"-test based on Fourier-Motzkin elimination. The result can be
  6980. written out in an (more or less) applicative form.
  6981.  
  6982. c. group Monica Lam (Stanford University): thesis of Dror Eliezer Maydan,
  6983. "Accurate analysis of array references", CSL-TR-92-547 (STAN-CS-92-1449),
  6984. september 1992
  6985.  
  6986. In addition there are a few older refs worth mentioning:
  6987.  
  6988. d. J.Bu (Delft): papers ISCAS/ICASSP'88, thesis 90 Provides data flow
  6989. analysis on restricted set of nested loops.
  6990.  
  6991. e. S. Rajopadhye (University of Oregon): paper in IMEC Workschop on Formal
  6992. Methods, November 89 "Algebraic transformations in Systolic Arrays
  6993. synthesis: A case study" Provides some algebraic transformations on Affine
  6994. Recurrence Equations to change dependencies. The transformations rely on
  6995. algebraic characteristics of the operators.
  6996.  
  6997.  
  6998. 2. Analysis techniques to check whether (a) particular class(es) of loop
  6999. trafos can be applied. No full data flow analysis happens in this case.
  7000.  
  7001. a. U. Banerjee (?): paper '89 in Proc. 2nd Workshop Languages Compilers
  7002. Parallel Computing : "A theory of loop permutation" Here, sets of nested
  7003. URE loops are checked for a potential permutation.  This can also be
  7004. solved if data flow analysis is performed first to derive a single
  7005. assignment form.
  7006.  
  7007. b. D.Padua, M. J. Wolfe (University of Illinois): papers Proc ACM'86 -
  7008. Supercomputing'90.  This provides a survey of loop trafo analysis
  7009. techniques (under restrictions) + a way to check loop interchanging for
  7010. manifest affine index expressions.  Also the decomposition of uni-modular
  7011. loop trafos into skew/reversal/inter- change is proposed here (though not
  7012. proven).
  7013.  
  7014. c. Randy Allen, Ken Kennedy (Rice University, Houston) : paper in IEEE
  7015. Transactions on computers, Vol. 41, No. 10, october 1992, "Vector Register
  7016. Allocation" Interesting survey paper on register allocation techniques
  7017. which includes analysis on when loop trafo can be applied.
  7018.  
  7019. 3. Extraction of parallelism in presence of nested loops:
  7020.  
  7021. a. Polychronopoulos (University of Illinois): paper in IEEE Transactions
  7022. on Computers, Vol. 37, No. 8, August 1988 "Compiler Optimizations for
  7023. Enhancing Parallelism and their impact on architecture design" Survey of
  7024. loop trafo classes with some analysis on how to extract parallelism but
  7025. not really automated.
  7026.  
  7027. b. M.J. Wolfe (Oregon Graduate Institute of Science and Technology): paper
  7028. The Journal of Super Computing 4,321-344, 1990 : "Data dependence and
  7029. Program Restructuring" Maximal parallelism is found for sets of UREs with
  7030. lexicographically ordered index expressions (quite restricted).
  7031.  
  7032. c. Pugh-Wonnacott (Univ. of Maryland): report UMIACS-TR-92-126
  7033. (CS-TR-2994) They find maximal parallelism for sets of nested loops with
  7034. manifest affine index expressions but including the user specified
  7035. assertions on non-manifest conditions.
  7036.  
  7037. d. Shang-Fortes (?): paper in Algorithms and Parallel VLSI Architectures
  7038. II, P.Quiton and Y.Robert (eds.), 1992 Also here parallelism is detected
  7039. for sets of nested loops with manifest affine index expressions.
  7040.  
  7041. 4. Methods to perform piece-wise linear scheduling.
  7042.  
  7043. a. M.E. Wolf, M. Lam (Stanford University) : paper IEEE Transactions on
  7044. parallel and distributed systems, Vol.2, No.4, October 1991 "A loop
  7045. transformation theory and an algorithm to maximize parallelism" Very good
  7046. paper on unimodular transformation of a loop structure.  An general
  7047. algorithm to generate the loop structure after transformation is proposed.
  7048.  
  7049. b. L.Thiele (Univ. Saarland), "On the design of piecewise regular
  7050. processor arrays", ISCAS'89, pp. 2239-2242.  Original work on this topic,
  7051. but not really automated.
  7052.  
  7053. c. Alain Darte, Tanguy Risset, Yves Robert, "Loop nest scheduling and
  7054. transformations", to appear in Environments and tools for Parallel
  7055. Scientific Computing, J.J. Dongarra and B.Tourancheau eds, North Holland,
  7056. 1993
  7057.  
  7058. d. Leslie Lamport : "The parallel execution of do loops" Communication of
  7059. the ACM, 17(2):83-93, February 1974
  7060.  
  7061. e. W.Kelly, W.Pugh (Univ. of Maryland) : report in ftp.cs.umd.edu
  7062. UMIACS-TR-92-126 (CS-TR-2995) November 1992 "Generating Schedules and Code
  7063. within a Unified Reordering Transformation Framework" Describes an
  7064. algorithm to compute transformations to obtain maximum parallellism. Gives
  7065. a method to genererate code after transformation.
  7066.  
  7067. f. C.-H. Huang, P. Sadayappan, "Communication-Free Hyperplane Partitioning
  7068. of Nested Loops", Languages and Compilers for parallel Computing, Fourth
  7069. International Workshop, Santa Clara, California, August 1991
  7070.  
  7071. g. M. Neeracher, R.Ruhl, "Automatic Parallelization of LINPACK Routines on
  7072. distributed Memory of Parallel processors", Proceedings 7th International
  7073. Parallel Programming Symposium, April 1993
  7074.  
  7075. 5. Singular Loop transformations papers ftp'ed from
  7076. ftp.cs.cornell.edu:pub/TyphoonCompiler/papers-ps/ Department of Computer
  7077. Science, University of Cornell a. Wei Li, Keshav Pingali, "A singular loop
  7078. transformation framework based on non-singular matrices", Proceedings of
  7079. the Fifth Annual Workshop on Language and Compilers for Parallelism, New
  7080. Haven, August, 1992
  7081.  
  7082. b. Wei Li, Keshav Pingali, "Access Normalization : Loop restructuring for
  7083. NUMA Compilers", ACM SIGPLAN Notices, Vol 27, Number 9, Sep.  1992
  7084.  
  7085. c. Wei Li, Keshav Pingali, "Loop transformation for NUMA Machines", to
  7086. appear in SIGPLAN Notices, 1993
  7087.  
  7088. d. R. Johnson, Wei Li, Keshav Pingali, "An executable representation of
  7089. distance and direction", Languages and Compilers for parallel Computing,
  7090. Fourth International Workshop, Santa Clara, California, August 1991
  7091.  
  7092. 6. The work in the following three references is related to automated
  7093. control flow optimization for DSP memory management.  In the papers a
  7094. method is presented to automatically generate a sequence of unimodular
  7095. transformations in order to optimize memory needs.
  7096.  
  7097. Group of F.V.M. Catthoor (IMEC, Belgium) :
  7098.  
  7099.         M.F.X.B. van Swaaij, F.H.M. Franssen, F.V.M. Catthoor, H.J. De Man.
  7100.         "Modeling data flow and control flow for high level memory
  7101.          management", European Design Automation Conference, pp. ,1992.
  7102.  
  7103.         M.F.X.B. van Swaaij, F.H.M. Franssen, F.V.M. Catthoor, H.J. De Man.
  7104.         "Modeling data flow and control flow for DSP system synthesis",
  7105.     VLSI Design Methodologies for DSP Systems, M. Bayoumi editor,
  7106.     Kluwer, 1993.
  7107.  
  7108.         M.F.X.B. van Swaaij, F.H.M. Franssen, F.V.M. Catthoor, H.J. De Man.
  7109.         "Automating high level control flow transformations for
  7110.          DSP memory management",
  7111.         Proceedings of the IEEE Workshop on VLSI signal processing, 1992.
  7112.  
  7113. =============================================================================
  7114. Papers we are still looking for :
  7115.  
  7116. a. C.Ancourt, F.Irigoin, "Scanning polyhedra with DO loops", Third ACM
  7117. symposium on Principles and Practice of Parallel Programming, p.39-50,
  7118. April 1991
  7119.  
  7120. b. L.Lu, "A Unified framework for systematic loop transformations", Third
  7121. ACM Symposium on Principles and Practice of parallel Programming, p.
  7122. 28-38, April 1991
  7123.  
  7124. Frank Franssen
  7125. IMEC Laboratory,
  7126. Kapeldreef 75,
  7127. B-3001 Leuven,
  7128. Belgium
  7129.  
  7130. Email: franssen@imec
  7131. tel: ++32-16-281512
  7132. fax: ++32-16-281515
  7133.  
  7134. -- 
  7135. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7136. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7137.  
  7138.  
  7139. From compilers Wed Apr  7 21:55:03 EDT 1993
  7140. Newsgroups: comp.compilers
  7141. Path: iecc!compilers-sender
  7142. From: wand@ccs.northeastern.edu (Mitchell Wand)
  7143. Subject: Re: Semantic actions in LR parser
  7144. Message-ID: <93-04-036@comp.compilers>
  7145. Keywords: LALR, parse, bibliography, comment
  7146. Sender: compilers-sender@iecc.cambridge.ma.us
  7147. Organization: College of Computer Science, Northeastern University
  7148. References: <93-04-008@comp.compilers> <93-04-029@comp.compilers>
  7149. Date: Wed, 7 Apr 1993 17:24:25 GMT
  7150. Approved: compilers@iecc.cambridge.ma.us
  7151.  
  7152. clark@zk3.dec.com (Chris Clark USSG) writes:
  7153. > One curious feature which falls out, is that if you can detect two actions
  7154. > are the same you can execute the action even if the eventual reduces are
  7155. > parts of two distinct productions.  That allows you to defer (and
  7156. > eliminate) some conflicts.  (In our model, two actions are the same if
  7157. > they are character for character the same string.)  Eliminating the pseudo
  7158. > productions, also means smaller state tables.
  7159.  
  7160. Ahh, this sounds like you've rediscovered a result similar to the one in
  7161.  
  7162. Brown, C. & Purdom, P. "Semantic Routines and LR(k) Parsers," Acta
  7163. Informatica 14 (1980), 299--315.
  7164.  
  7165. I suppose 1980 is before the beginning of time for a lot of folks.
  7166.  
  7167. I wonder if Chris could compare his results with the Brown-Purdom results.
  7168.  
  7169. --Mitch
  7170. --
  7171. Mitchell Wand
  7172. College of Computer Science, Northeastern University
  7173. 360 Huntington Avenue #161CN, Boston, MA 02115     Phone: (617) 437 2072
  7174. Internet: wand@ccs.northeastern.edu                Fax:   (617) 437 5121
  7175. [In 1980 yacc was already eight years old. -John]
  7176. -- 
  7177. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7178. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7179.  
  7180.  
  7181. From compilers Wed Apr  7 21:55:44 EDT 1993
  7182. Newsgroups: comp.compilers
  7183. Path: iecc!compilers-sender
  7184. From: jwe@emx.cc.utexas.edu (John W. Eaton)
  7185. Subject: Re: Looking for a MATLAB parser
  7186. Message-ID: <93-04-037@comp.compilers>
  7187. Keywords: parse
  7188. Sender: compilers-sender@iecc.cambridge.ma.us
  7189. Organization: The University of Texas at Austin, Austin, Texas
  7190. References: <93-04-030@comp.compilers>
  7191. Date: Wed, 7 Apr 1993 22:05:04 GMT
  7192. Approved: compilers@iecc.cambridge.ma.us
  7193.  
  7194. keerthi@leland.Stanford.EDU (Keerthi Angammana) writes:
  7195.  
  7196. > Does anybody know if a parser (or at least a complete grammar) for
  7197. > MATLAB is available for free someplace ?
  7198.  
  7199. I'm working on an interpreter called Octave that's very much like Matlab.
  7200. The parser is built using flex and bison and the whole thing is
  7201. distributed under the terms of the GNU Copyleft.
  7202.  
  7203. The underlying numerical solvers are currently standard Fortran ones like
  7204. Lapack, Linpack, Odepack, the Blas, etc., packaged in a library of C++
  7205. classes (see the files in the libcruft and liboctave subdirectories).  If
  7206. possible, the Fortran subroutines are compiled with the system's Fortran
  7207. compiler, and called directly from the C++ functions.  If that's not
  7208. possible, they are translated with f2c and compiled with a C compiler.
  7209. Better performance is usually achieved if the intermediate translation to
  7210. C is avoided.
  7211.  
  7212. The library of C++ classes may also be useful by itself, and they are
  7213. distributed under the same terms as Octave.
  7214.  
  7215. Octave has been compiled and tested with g++-2.3.3 and libg++-2.3 on a
  7216. SPARCstation 2 running SunOS 4.1.2, an IBM RS/6000 running AIX 3.2, a
  7217. DECstation 5000/240 running Ultrix 4.2a, and an i486 system running Linux
  7218. SLS 0.99-47.  It should be possible to build on almost all systems where
  7219. gcc and g++ are available.
  7220.  
  7221. If you are on the Internet, you can copy the latest distribution version
  7222. of Octave from the file /pub/octave/octave-M.N.tar.Z, on the host
  7223. ftp.che.utexas.edu.  This is a compressed tar file, so be sure to use
  7224. binary mode for the transfer.  M and N stand for version numbers; look at
  7225. a listing of the directory through ftp to see what version is available.
  7226. After you unpack the distribution, be sure to look at the files README and
  7227. INSTALL.
  7228. --
  7229. John W. Eaton
  7230. jwe@che.utexas.edu
  7231. Department of Chemical Engineering
  7232. The University of Texas at Austin
  7233. -- 
  7234. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7235. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7236.  
  7237.  
  7238. From compilers Thu Apr  8 11:41:53 EDT 1993
  7239. Newsgroups: comp.compilers
  7240. Path: iecc!compilers-sender
  7241. From: ccsis@sunlab1.bath.ac.uk (Icarus Sparry)
  7242. Subject: Re: Serendipitious Compiler Stuff
  7243. Message-ID: <93-04-038@comp.compilers>
  7244. Keywords: tools, FTP
  7245. Sender: compilers-sender@iecc.cambridge.ma.us
  7246. Organization: Bath University Computing Services, UK
  7247. References: <93-04-022@comp.compilers>
  7248. Date: Thu, 8 Apr 1993 11:13:25 GMT
  7249. Approved: compilers@iecc.cambridge.ma.us
  7250.  
  7251. Paul Robinson <tdarcos@mcimail.com> writes:
  7252. >Note that these files end in ".z" NOT ".Z" so you need GNUZIP to decompress
  7253. >them, NOT compress. ...
  7254.  
  7255. No, these are '.Z' (compress) files. Simtel-20 runs an operating system
  7256. which does not distinguish between cases. For simplicity most (all?)
  7257. mirror sites map everything to lower case. Simtel-20 filenames can only
  7258. have a single '.' in them, so the common extension is '.tar-z'. File
  7259. should be renamed to have an extension of '.tar.Z' and then treated in
  7260. the normal manner.
  7261. -- 
  7262. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7263. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7264.  
  7265.  
  7266. From compilers Thu Apr  8 17:11:24 EDT 1993
  7267. Xref: iecc comp.arch:27742 comp.lang.functional:2718 comp.lang.lisp:7184 comp.lang.scheme:5462 comp.parallel:5681 comp.compilers:4497
  7268. Newsgroups: comp.arch,comp.lang.functional,comp.lang.lisp,comp.lang.scheme,comp.parallel,comp.compilers
  7269. Path: iecc!compilers-sender
  7270. From: Lori Lynn Avirett-Mackenzie <lori@au-bon-pain.lcs.mit.edu>
  7271. Subject: FPCA 93 Advance Program Information
  7272. Message-ID: <93-04-039@comp.compilers>
  7273. Keywords: conference, parallel, functional
  7274. Sender: compilers-sender@iecc.cambridge.ma.us
  7275. Organization: MIT Lab for Computer Science, Cambridge, Mass.
  7276. Date: Thu, 8 Apr 1993 21:59:09 GMT
  7277. Approved: compilers@iecc.cambridge.ma.us
  7278.  
  7279. ANNOUNCEMENT: Programming Language Conferences, Copenhagen, June 9-16, 1993
  7280. ===========================================================================
  7281.  
  7282. June  9-11: FPCA (Functional Programming Languages and Computer Architecture)
  7283. June 12   : SIPL (State in Programming Languages)
  7284. June 14-16: PEPM (Symposium on Partial Evaluation and Semantics Based Program
  7285.                   Manipulation)
  7286.  
  7287. The advance program for the above ACM-sponsored meetings is being sent
  7288. out as a supplement to ACM SIGPLAN Notices. It contains detailed
  7289. programs for FPCA and PEPM plus information about registration and
  7290. accommodation.  The advance program is also available by request from
  7291.  
  7292.     Lisa Wiese
  7293.     Attn.: FPCA '93
  7294.     DIKU, University of Copenhagen
  7295.     Universitetsparken 1
  7296.     DK-2100 Copenhagen East
  7297.     Denmark
  7298.  
  7299.     Tel. +45-35 32 14 13
  7300.     Email: wiese@diku.dk
  7301.  
  7302. or in .dvi and .ps format via anonymous ftp from DIKU; see the
  7303. following sample session:
  7304.  
  7305.    > ftp ftp.diku.dk
  7306.    Name: anonymous
  7307.    Password: <type your internet email address here>
  7308.    ftp> binary
  7309.    ftp> cd pub/diku/semantics
  7310.    ftp> get FPCA-SIPL-PEPM.dvi      (or: get FPCA-SIPL-PEPM.ps)
  7311.    ftp> bye
  7312.  
  7313.  
  7314. or in .dvi and .ps format via anonymous ftp from MIT; see the
  7315. following sample session:
  7316.  
  7317.     ftp jj.lcs.mit.edu
  7318.     Name: anonymous
  7319.     Password: <type your internet email address here>
  7320.     ftp> binary
  7321.     ftp> cd fpca93
  7322.     ftp> get FPCA-SIPL-PEPM.dvi      (or: get FPCA-SIPL-PEPM.ps)
  7323.     ftp> bye
  7324. -- 
  7325. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7326. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7327.  
  7328.  
  7329. From compilers Thu Apr  8 19:53:46 EDT 1993
  7330. Newsgroups: comp.compilers
  7331. Path: iecc!compilers-sender
  7332. From: Steven Novack <snovack@enterprise.ICS.UCI.EDU>
  7333. Subject: Assembly hacker vs. compiler revisited
  7334. Message-ID: <93-04-040@comp.compilers>
  7335. Keywords: assembler, optimize
  7336. Sender: compilers-sender@iecc.cambridge.ma.us
  7337. Organization: Compilers Central
  7338. References: <93-02-105@comp.compilers> <93-02-122@comp.compilers>
  7339. Date: Thu, 8 Apr 1993 20:12:16 GMT
  7340. Approved: compilers@iecc.cambridge.ma.us
  7341.  
  7342. A month or so ago there was a debate on in this group about the question
  7343. of by how much, if at all, a good assembly language programmer could beat
  7344. the best compiler.  Someone on the assembly side mentioned an example
  7345. wherein handcoding a data compression algorithm was able to achieve an 8
  7346. fold improvement over compiling the same algorithm written in a high level
  7347. language.
  7348.  
  7349. I would greatly appreciate receiving more information on this example, or
  7350. any others, in which hand-coding provides significant improvements over
  7351. compiling high-level implementations.  I'm interested in any aspect of
  7352. this from where benefits are obtained throughout an application, all the
  7353. way down to little, but useful ``tricks'' that would be missed by most
  7354. compilers.
  7355.  
  7356. Thanks in advance,
  7357. Steve Novack
  7358.  
  7359. Dept. of Information and Computer Science
  7360. University of California, Irvine, CA  92717
  7361. snovack@ics.uci.edu
  7362. (714) 725-2248
  7363. -- 
  7364. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7365. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7366.  
  7367.  
  7368. From compilers Sun Apr 11 11:41:40 EDT 1993
  7369. Newsgroups: comp.compilers
  7370. Path: iecc!compilers-sender
  7371. From: megatest!plethorax!djones@uu2.psi.com (Dave Jones)
  7372. Subject: Re: Wanted: Regular Expression -> Finite Automata  C code =-
  7373. Message-ID: <93-04-041@comp.compilers>
  7374. Keywords: lex, DFA
  7375. Sender: compilers-sender@iecc.cambridge.ma.us
  7376. Organization: Compilers Central
  7377. References: <93-04-023@comp.compilers>
  7378. Date: Fri, 9 Apr 1993 11:39:29 GMT
  7379. Approved: compilers@iecc.cambridge.ma.us
  7380.  
  7381. tdh6t@helga3.acc.virginia.edu (Todd Hodes):
  7382. >     I wanted to use the code in Sedgewick's 'Algorithms in C' book,
  7383. > but found the following bug: ...
  7384.  
  7385. Last month I posted an article pointing out two bugs in Sedgewick's Pascal
  7386. algorithm for matching the NFA against an input string. The bug Todd
  7387. reports is in the algorithm for building the NFA, in the "C" book, which I
  7388. have never seen.
  7389.  
  7390. Helpful suggestion: Don't try to salvage the Sedgewick algorithms.  See
  7391. the New Dragon Book, "Compilers, Priciples, Techniques, and Tools", by
  7392. Aho, Sethi, and Ullman; Addison Wesley; Reading, Mass; 1988; IBSN
  7393. 0-201-10088-6.
  7394.  
  7395. Both procedures are sketched out almost correctly in algorithms 3.3 and
  7396. 3.4.  Algorithm 3.4 is not quite right, but you'll figure it out when you
  7397. start to implement it. As written, it terminates only when the input
  7398. string has been read to the end. It should terminate either then or when
  7399. the NFA is in a state in which it can make no move on the current input
  7400. character. In the language the book uses, that will be when
  7401. e-closure(move(S,a)) is empty.
  7402.  
  7403. Also, every time a final state is encountered, you will want to remember
  7404. the number of characters that have been processed at that point.  The last
  7405. number remembered will be the length of the longest match.
  7406.  
  7407. One key difference between the Dragon Book algorithm and the Sedgewick
  7408. algorithm is the use of the bit-vector to prevent putting the same NFA
  7409. state into the the "next state" set more than once.  Come to think of it,
  7410. do you need another bit-vector to keep from putting the same set into the
  7411. "current state" set more than once when calculating the e-closure? Hmm.
  7412.  
  7413. The other Seg. problem is stopping when a final NFA state is first
  7414. encountered. In other words, it finds the shortest match -- seldom what is
  7415. wanted, particularly for expressions that can match the empty string!
  7416.  
  7417. I haven't verified the bug you report against the other Sedgewick
  7418. algorithm, so I don't know what the difference is, but I think the Dragon
  7419. algorithm 3.3 is correct, if memory serves. It's been about 10 years since
  7420. I looked at it though (in the old Dragon book).
  7421.  
  7422. Good luck.
  7423.  
  7424.         Dave
  7425. -- 
  7426. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7427. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7428.  
  7429.  
  7430. From compilers Sun Apr 11 11:44:25 EDT 1993
  7431. Xref: iecc comp.lang.c++:34615 comp.compilers:4500
  7432. Newsgroups: comp.lang.c++,comp.compilers
  7433. Path: iecc!compilers-sender
  7434. From: Mayan Moudgill <moudgill@cs.cornell.EDU>
  7435. Subject: A C++ Parser toolkit
  7436. Message-ID: <93-04-042@comp.compilers>
  7437. Summary: a toolkit for quickly implementing a parser (including CSGs)
  7438. Keywords: C++, parse, tools, comment
  7439. Sender: compilers-sender@iecc.cambridge.ma.us
  7440. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  7441. Date: Sun, 11 Apr 1993 02:43:30 GMT
  7442. Approved: compilers@iecc.cambridge.ma.us
  7443.  
  7444. I've implemented a parser/scanner/text-matcher :) that allows a programmer
  7445. to quickly specify a grammar, and to attach actions to productions.
  7446.  
  7447. For instance, the following code:
  7448.  
  7449.       int name(Parse& P)
  7450.       {
  7451.       Token  t;
  7452.  
  7453.           P, IDENT(t);
  7454.           if( P && StbFind(t) ) {
  7455.              return 1;
  7456.           }
  7457.           return 0;
  7458.       }
  7459.  
  7460.       int stmt(Parse & P)
  7461.       {
  7462.       Token      t;
  7463.  
  7464.          P, MATCH(name), "=", NUMBER(val);
  7465.       }
  7466.  
  7467. matches an identifier (i.e. [a-zA-Z_][a-zA-Z_0-9]*), '=', number string,
  7468. but only if identifier is already in the symbol-table.
  7469.  
  7470. NOTES: It works on a Sun 4.0 with C++ 3.0. It _MIGHT_ work on some other OSes
  7471. I've used mmap() to implement it. Your OS might have the function;
  7472. then again it might not. Even if it does, its parameters might not be
  7473. the same.
  7474.  
  7475. PS.  Its also ftp'able as pub/Parse.shar from ftp.cs.cornell.edu
  7476.  
  7477. :)
  7478. Mayan
  7479. [I've put this in the compilers FTP archives at primost.cs.wisc.edu as
  7480. c++kit.Z.  If you can't FTP, it's available by e-mail from the mail server
  7481. at compilers-server@iecc.cambridge.ma.us; send "send c++kit" to retrieve it.
  7482. Please FTP if you can, the mail server is linked to the outside world by a
  7483. single dial-up modem. -John]
  7484. -- 
  7485. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7486. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7487.  
  7488.  
  7489. From compilers Sun Apr 11 11:48:44 EDT 1993
  7490. Xref: iecc comp.compilers:4501 misc.jobs.offered:26691
  7491. Newsgroups: comp.compilers,misc.jobs.offered
  7492. Path: iecc!compilers-sender
  7493. From: compilers-jobs@iecc.cambridge.ma.us
  7494. Subject: Compiler positions available for week ending April 11
  7495. Message-ID: <93-04-043@comp.compilers>
  7496. Keywords: jobs
  7497. Sender: compilers-sender@iecc.cambridge.ma.us
  7498. Organization: Compilers Central
  7499. Date: Sun, 11 Apr 1993 15:47:31 GMT
  7500. Approved: compilers@iecc.cambridge.ma.us
  7501.  
  7502. This is a digest of ``help wanted'' and ``position available'' messages
  7503. received at comp.compilers during the preceding week.  Messages must
  7504. advertise a position having something to do with compilers and must also
  7505. conform to the guidelines periodically posted in misc.jobs.offered.
  7506. Positions that remain open may be re-advertised once a month.  To respond
  7507. to a job offer, send mail to the author of the message.  To submit a
  7508. message, mail it to compilers@iecc.cambridge.ma.us.
  7509.  
  7510.  
  7511. -------------------------------
  7512.  
  7513. From: reinders@SSD.intel.com (James Reinders)
  7514. Subject: Intel Supercomputer Job Opennings
  7515. Organization: Supercomputer Systems Division (SSD), Intel
  7516. Date: Fri, 9 Apr 1993 21:38:53 GMT
  7517.  
  7518. The Supercomputing Systems Division of Intel has positions available now
  7519. in Beaverton, Oregon for Senior Software Engineers, Compilers.
  7520.  
  7521. A more detailed description is attached.
  7522.  
  7523. Please mail resumes (no FAXes, no phone calls, no e-mail, please):
  7524.  
  7525.   James Reinders
  7526.   c/o Intel Corporation
  7527.   Mail Stop CO4-02
  7528.   5200 N.E. Elam-Young Parkway
  7529.   Hillsboro, OR 97124-6497
  7530.  
  7531. - james
  7532.  
  7533. ------------------------------------------------------------------------------
  7534.  
  7535. Senior Software Engineers, Compilers
  7536. Position(s): Design and implement compilers for Intel Parallel
  7537.              Supercomputers, both scalar and parallelizing compiler positions.
  7538. Education:   M.S. or PhD in Computer Engineering or Computer Science.
  7539. Experience:  minimum of 3 years of experience in compiler development
  7540.              and system architecture.
  7541. Skills:      Experience with parallel or vector supercomputers required.
  7542.              Proficiency in compiler technology, computer architecture,
  7543.              parallel architectures, C, FORTRAN, UNIX and UNIX tools.
  7544.              Must have strong communication and analytical skills, and team
  7545.              software development experience.
  7546. --
  7547. :: James R. Reinders                 reinders@ssd.intel.com ::
  7548. :: Intel Supercomputer Systems, M/S C04-02                  ::
  7549. -- 
  7550. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7551. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7552.  
  7553.  
  7554. From compilers Mon Apr 12 17:05:10 EDT 1993
  7555. Newsgroups: comp.compilers
  7556. Path: iecc!compilers-sender
  7557. From: parrt@ecn.purdue.edu (Terence J Parr)
  7558. Subject: Re: A C++ Parser toolkit
  7559. Message-ID: <93-04-044@comp.compilers>
  7560. Keywords: tools, PCCTS
  7561. Sender: compilers-sender@iecc.cambridge.ma.us
  7562. Organization: Compilers Central
  7563. References: <93-04-042@comp.compilers>
  7564. Date: Mon, 12 Apr 1993 15:25:55 GMT
  7565. Approved: compilers@iecc.cambridge.ma.us
  7566.  
  7567. I'm very pleased by the posting of Mayan Moudgill
  7568. <moudgill@cs.cornell.EDU>; people are beginning to see that semantic
  7569. predicates are the way to recognize context-sensitive constructs rather
  7570. than having the lexer change the token type (ack!).  Mayan writes:
  7571.  
  7572. > For instance, the following code:
  7573. >
  7574. >       int name(Parse& P)
  7575. >       {
  7576. >       Token  t;
  7577. >
  7578. >           P, IDENT(t);
  7579. >           if( P && StbFind(t) ) {
  7580. >              return 1;
  7581. >           }
  7582. >           return 0;
  7583. >       }
  7584. >
  7585. >       int stmt(Parse & P)
  7586. >       {
  7587. >       Token      t;
  7588. >
  7589. >          P, MATCH(name), "=", NUMBER(val);
  7590. >       }
  7591. >
  7592. > matches an identifier (i.e. [a-zA-Z_][a-zA-Z_0-9]*), '=', number string,
  7593. > but only if identifier is already in the symbol-table.
  7594.  
  7595. In PCCTS, we would write something akin to:
  7596.  
  7597. name : << IsVAR(LATEXT(1)) >>? IDENT
  7598.      ;
  7599.  
  7600. stat : name "=" NUMBER
  7601.      ;
  7602.  
  7603. where <<IsVAR(LATEXT(1))>>? is a semantic predicate; IsVAR is some
  7604. user-defined function and LATEXT(1) is the text of the first token of
  7605. lookahead.  This example behaves exactly as Mayan outlines.  We call this
  7606. a *validation* semantic predicate (we have syntactic predicates in the
  7607. next release of PCCTS).  Predicates can also be used to distinguish
  7608. between two syntactically ambiguous productions (*disambiguating* semantic
  7609. predicates).  E.g., let's add a production to stat to match a type name
  7610. followed by a declarator.
  7611.  
  7612. name : << IsVAR(LATEXT(1)) >>? IDENT
  7613.      ;
  7614.  
  7615. type : << IsTYPE(LATEXT(1)) >>? IDENT
  7616.      ;
  7617.  
  7618. stat : name "=" NUMBER
  7619.      | type declarator
  7620.      ;
  7621.  
  7622. In this case, IDENT predicts both productions of stat and k=1 lookahead is
  7623. syntactically insufficient.  However, ANTLR (the parser-generator of
  7624. PCCTS) finds 2 *visible* predicates (one in name and the other in type)
  7625. that can be used to semantically disambiguate the productions of stat.
  7626. Hence, it *hoists* the predicates for use in the prediction expressions
  7627. for stat, thus, resolving the conflict.  Note that, using k=2, ANTLR could
  7628. uniquely predict stat's productions without predicates and would not hoist
  7629. the visible predicates.
  7630.  
  7631. PCCTS is in the public domain and may be obtained by sending email to
  7632. pccts@ecn.purdue.edu with a blank "Subject:" line.
  7633.  
  7634. Terence Parr
  7635. Purdue University
  7636. School of Electrical Engineering
  7637. -- 
  7638. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7639. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7640.  
  7641.  
  7642. From compilers Mon Apr 12 17:07:03 EDT 1993
  7643. Newsgroups: comp.compilers
  7644. Path: iecc!compilers-sender
  7645. From: henry@zoo.toronto.edu (Henry Spencer)
  7646. Subject: Re: Wanted: Regular Expression -> Finite Automata  C code =-
  7647. Message-ID: <93-04-045@comp.compilers>
  7648. Keywords: DFA, lex
  7649. Sender: compilers-sender@iecc.cambridge.ma.us
  7650. Organization: U of Toronto Zoology
  7651. References: <93-04-023@comp.compilers> <93-04-041@comp.compilers>
  7652. Date: Mon, 12 Apr 1993 19:50:34 GMT
  7653. Approved: compilers@iecc.cambridge.ma.us
  7654.  
  7655. megatest!plethorax!djones@uu2.psi.com (Dave Jones) writes:
  7656. >Also, every time a final state is encountered, you will want to remember
  7657. >the number of characters that have been processed at that point.  The last
  7658. >number remembered will be the length of the longest match.
  7659.  
  7660. Unfortunately, this doesn't generalize to most real-life applications,
  7661. where the match is not anchored at the start of the string.  It's easy to
  7662. generalize the matching algorithm so you still make only one pass, by
  7663. considering the possibility of a fresh start at each character, and this
  7664. is definitely the way to do it -- you don't want to retry the match at
  7665. each possible starting position!  Alas, the bookkeeping for longest match
  7666. falls apart.  You don't know when the particular match that corresponds to
  7667. a new final state started.  Consider the RE "(abcde|cd|ef)" and the string
  7668. "xabcdefy".  You reach a final state after seeing the "d", another after
  7669. the "e", and another after the "f", but the last one is not the longest.
  7670. --
  7671. Henry Spencer @ U of Toronto Zoology, henry@zoo.toronto.edu  utzoo!henry
  7672. -- 
  7673. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7674. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7675.  
  7676.  
  7677. From compilers Tue Apr 13 11:18:18 EDT 1993
  7678. Newsgroups: comp.compilers
  7679. Path: iecc!compilers-sender
  7680. From: Thomas Johnsson <johnsson@cs.chalmers.se>
  7681. Subject: Effectiveness of coloring: Chaitin-style vs Chow-style
  7682. Message-ID: <93-04-046@comp.compilers>
  7683. Keywords: optimize, registers, question
  7684. Sender: compilers-sender@iecc.cambridge.ma.us
  7685. Organization: Compilers Central
  7686. Date: Tue, 13 Apr 1993 08:39:09 GMT
  7687. Approved: compilers@iecc.cambridge.ma.us
  7688.  
  7689. Here is something that has puzzled me, regarding the effectiveness of
  7690. Chaitin style graph coloring vs Chow style priority based coloring.
  7691.  
  7692. In Chaitin's original coloring scheme, nodes which have degree < N (N
  7693. being the number of available registers) are deleted from the graph,
  7694. together with the incident arcs, because such nodes are trivially
  7695. colorable.  If one comes to a point where all nodes have degree >= N, some
  7696. node is chosen for spilling, and the deletion continues (In a modification
  7697. of this, a node is simply chosen for deletion anyway -- I think this is
  7698. what Preston Briggs does).  Nodes are colored in reverse order in which
  7699. they were deleted from the graph.
  7700.  
  7701. In Chow style priority based coloring, nodes are basically colorored in
  7702. order highest priority first, where the priority is set by the estimated
  7703. runtime gain by allocating the variable to a register.
  7704.  
  7705. In the (modified) Chaitin scheme, coloring order basically becomes: high
  7706. pressure regions first -- an order which is different from the priority
  7707. order.
  7708.  
  7709. All other things being equal (i.e., ignoring issues of subsumption, live
  7710. range splitting, etc) I would have thought that it would always be more
  7711. beneficial to color the high gain nodes first, irrespective of how many
  7712. other nodes that the node-to-be-colored conflicts with.
  7713.  
  7714. True or not?
  7715.  
  7716. -- Thomas Johnsson (johnsson@cs.chalmers.se)
  7717. -- 
  7718. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7719. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7720.  
  7721.  
  7722. From compilers Tue Apr 13 11:33:45 EDT 1993
  7723. Newsgroups: comp.compilers
  7724. Path: iecc!compilers-sender
  7725. From: wjackson@pinnacle.cerc.wvu.edu
  7726. Subject: request C code which translates source into PDG
  7727. Message-ID: <93-04-047@comp.compilers>
  7728. Keywords: optimize, analysis, question
  7729. Sender: compilers-sender@iecc.cambridge.ma.us
  7730. Organization: Compilers Central
  7731. Date: Tue, 13 Apr 1993 14:37:13 GMT
  7732. Approved: compilers@iecc.cambridge.ma.us
  7733.  
  7734. Has anyone implemented algorithms which convert a source program into a
  7735. Program Dependence Graph?  We are currently working to implement such
  7736. algorithms as outlined in the 1987 paper "The Program Dependence Graph and
  7737. Its Use in Optimization" by Ferrante, Ottenstein, and Warren.  If anyone
  7738. else has done this or another implementation and has code available, we
  7739. would appreciate the information.
  7740.  
  7741. Thanks,
  7742. Walter Jackson
  7743. -- 
  7744. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7745. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7746.  
  7747.  
  7748. From compilers Tue Apr 13 16:55:57 EDT 1993
  7749. Newsgroups: comp.compilers
  7750. Path: iecc!compilers-sender
  7751. From: preston@dawn.cs.rice.edu (Preston Briggs)
  7752. Subject: Re: Effectiveness of coloring: Chaitin-style vs Chow-style
  7753. Message-ID: <93-04-048@comp.compilers>
  7754. Keywords: optimize, registers
  7755. Sender: compilers-sender@iecc.cambridge.ma.us
  7756. Organization: Rice University, Houston
  7757. References: <93-04-046@comp.compilers>
  7758. Date: Tue, 13 Apr 1993 19:37:54 GMT
  7759. Approved: compilers@iecc.cambridge.ma.us
  7760.  
  7761. Thomas Johnsson <johnsson@cs.chalmers.se> writes:
  7762. [asking about Chow and Chaitin]
  7763.  
  7764. >All other things being equal (i.e., ignoring issues of subsumption, live
  7765. >range splitting, etc) I would have thought that it would always be more
  7766. >beneficial to color the high gain nodes first, irrespective of how many
  7767. >other nodes that the node-to-be-colored conflicts with.
  7768.  
  7769. I disagree.  If you waste colors on expensive (but trivially colorable)
  7770. nodes, you may have to spill in situations where no spilling was required.
  7771.  
  7772. Look at it like this.  Both Chaitin and Chow divide the nodes in the graph
  7773. into two sets: trivial and non-trivial.  Then they try and color the
  7774. non-trivial nodes first.  Chow says all the nodes with degree < k (where k
  7775. is the number of registers) are trivially colorable. Chaitin finds his
  7776. sets of trivial nodes by removing from the graph all nodes of degree < k.
  7777. He continues removing nodes until no nodes of degree < k remain in the
  7778. graph.  Chaitin's set always includes all the nodes in Chow's set.  Thus,
  7779. Chow may spill nodes that Chaitin would consider trivial.
  7780.  
  7781. Within the remainder of the graph (the non-trivial part), Briggs et al.
  7782. (following Chaitin) first remove nodes with low spill cost and high
  7783. degree.  Thus nodes with high spill cost tend to remain in the graph
  7784. longer and be colored earlier, just like Chow.
  7785.  
  7786. Preston Briggs
  7787. -- 
  7788. Send compilers articles to compilers@iecc.cambridge.ma.us or
  7789. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  7790.  
  7791.  
  7792. From compilers Wed Apr 14 10:41:36 EDT 1993
  7793. Newsgroups: comp.compilers
  7794. Path: iecc!compilers-sender
  7795. From: M.J. Ratcliffe <Michael.Ratcliffe@ecrc.de>
  7796. Subject: PARLE'93: Advanced Programme Corrections
  7797. Message-ID: <93-04-049@comp.compilers>
  7798. Keywords: conference, CFP, parallel
  7799. Sender: compilers-sender@iecc.cambridge.ma.us
  7800. Organization: ECRC GmbH, Arabellast. 17, D-8000 Munich 81
  7801. References: <93-03-047@comp.compilers>
  7802. Date: Tue, 13 Apr 1993 21:18:30 GMT
  7803. Approved: compilers@iecc.cambridge.ma.us
  7804.  
  7805. We have recently spotted some bugs in the printed version of the PARLE'93
  7806. Advanced Programme. Here are the most important points for those of you
  7807. receiving the printed version, followed by a reposting of the full
  7808. information for reference. Please note that the early registration
  7809. deadline is nearing (April 30th).
  7810.      a) the tutorial attendance fee is DM275
  7811.      b) the reduced registration fee is available for all members of CEPIS
  7812.         (Council of European Professional Informatics Societies)
  7813.         organisations (i.e. AFCET, AFIN, AICA, BCS, CCS, DD, DND, FESI,
  7814.     FIPA, GCS, GI, ICS, ITG im VDE, NGI, NJSzT, OCG, PIPS, SAI,
  7815.     SI, VRI). Please include your membership number and relevant
  7816.     member organisation on the registration form.
  7817.  
  7818. --michael
  7819.  
  7820. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  7821.  
  7822.              +-----------------------------------------------+
  7823.              |                                               |
  7824.              |     A D V A N C E D   P R O G R A M M E       |
  7825.              |                                               |
  7826.              |                      &                        |
  7827.              |                                               |
  7828.              | C A L L    F O R    P A R T I C I P A T I O N |
  7829.              |                                               |
  7830.              |                                               |
  7831.              +-----------------------------------------------+
  7832.  
  7833.  
  7834.      PARALLEL ARCHITECTURES  PPPP    AA    RRRR   L    EEEE  999   333
  7835.                              P   P  A  A   R   R  L    E    9   9     3
  7836.               AND LANGUAGES  PPP    AAAA   RRR    L    EEE   9999   33
  7837.                              P     A    A  R  R   L    E        9     3
  7838.                      EUROPE  P     A    A  R   R  LLLL EEEE  999   333
  7839.  
  7840.                              Marriott Hotel, Munich, Germany
  7841.                              June 14 - 18, 1993
  7842.  
  7843.  
  7844.  
  7845.                                  OVERVIEW
  7846.  
  7847. PARLE is an international, european!based conference focusing on the
  7848. parallel processing subdomain of Informatics/Information Technology. It
  7849. is organised annually on a non!profit making basis to act as a European
  7850. forum for interchange between those working or interested in the domain,
  7851. from both academia and industry.
  7852.  
  7853. Ever increasing demands are being made on computer technology to provide
  7854. the processing power necessary to help understand and master the
  7855. complexity of natural phenomena and engineering structures. Within human
  7856. organisations ever more processing power is needed to master the
  7857. increased information flow. Many so!called !Grand Challenges! have been
  7858. identified as being orders of magnitude beyond even the most powerful
  7859. computers available today.
  7860.  
  7861. Parallel processing technology offers a solution to providing the
  7862. necessary power and is therefore generally recognised as a strategically
  7863. important technology. By taking many basic processing devices and
  7864. connecting them together the potential exists of being able to achieve a
  7865. performance many times that of an individual device. However it is still
  7866. an important topic of research to discover how to do this optimally and
  7867. then to be able to effectively exploit the potential power through real
  7868. applications solving real!world problems.
  7869.  
  7870.  
  7871.                              WHO SHOULD ATTEND?
  7872.  
  7873. PARLE!93 has been designed to be attractive for a very wide!ranging
  7874. audience. It will appeal to academic researchers and students working in
  7875. the field of parallel processing or related areas. It will also appeal to
  7876. industrial workers in the area wishing to discover the latest ideas,
  7877. techniques and approaches. The Tutorial Programme offers an opportunity
  7878. for anyone interested in learning the state!of!the!art in some of the
  7879. newest, most exciting areas of parallel processing from world renowned
  7880. experts. A special Esprit project poster display will provide an overview
  7881. of many projects funded by the European Commission. The Industrial
  7882. Programme, consisting of both Vendor Presentations and an Exhibition,
  7883. offers the opportunity to gain first!hand experience of the commercial
  7884. products available today.
  7885.  
  7886. PARLE!93 offers an unrivaled opportunity for anyone interested to learn
  7887. more about parallel processing, whether expert or novice.
  7888.  
  7889.  
  7890.                              PROGRAMME OVERVIEW
  7891.  
  7892.       +------------+------------+------------+------------+------------+
  7893.       | Monday     | Tuesday    | Wednesday  | Thursday   | Friday     |
  7894.       | 14th June  | 15th June  | 16th June  | 17th June  | 18th June  |
  7895.       +------------+------------+------------+------------+------------+
  7896.       |    T       |                                      |            |
  7897.       |    U       |                                      | SATELLITE  |
  7898.       |    T       |           PAPER  SESSIONS            |            |
  7899.       |    O       |                                      |     EVENTS |
  7900.       |    R       |                                      |            |
  7901.       |    I       +------------+------------+------------+------+-----+
  7902.       |    A       |                                             |
  7903.       |    L       |          INDUSTRIAL  EXHIBITION             |
  7904.       |    S       |                                             |
  7905.       +------------+------------+------------+------------+------+
  7906.                    | RECEPTION  |  BANQUET   |
  7907.                    +------------+------------+
  7908.  
  7909.  
  7910.                           INDUSTRIAL PROGRAMME
  7911.  
  7912. The Industrial Programme associated with PARLE!93 consists of an
  7913. Exhibition and Vendor Sessions. The following companies have confirmed
  7914. their participation:
  7915.      Convex                         Intel
  7916.      Cray Research                  MasPar
  7917.      Distributed Software Limited   Meiko
  7918.      DSM Computer                   nCUBE
  7919.      Encore                         Pallas
  7920.      GENIAS Software GmbH           Parsytec
  7921.      IBM                            Siemens-Nixdorf Information Systems
  7922.      ICL                            Transtech Parallel Systems
  7923.  
  7924.  
  7925.                            SATELLITE EVENTS
  7926.  
  7927. Two satellite events are being organised in association with PARLE!93:
  7928.      * A meeting for Esprit projects involved in parallel processing is
  7929. planned
  7930.        by the European Commission.
  7931.      * An Intel European Users! Group meeting.
  7932.      * A meeting of CONVEX's SCWG (Scalable Computing Working Group) on
  7933.        compatible cluster and MPP programming
  7934.  
  7935.  
  7936.                               TUTORIALS
  7937.  
  7938. A choice of four parallel tutorials is being offered. Each tutorial will
  7939. last a full day in order to provide the time necessary for an in-depth
  7940. coverage:
  7941.  
  7942.  
  7943. TUTORIAL 1: MOLECULAR BIOINFORMATICS
  7944.  
  7945. Presenter: Thomas Lengauer, GMD, St. Augustin, Germany
  7946.  
  7947. Objectives
  7948. This tutorial will give an overview of Molecular Bioinformatics, its
  7949. promises, its limitations, and its scientific challenges. Molecular
  7950. Bioinformatics is an area in applied computer science which is in general
  7951. terms concerned with the development of methods and tools for analysing,
  7952. understanding, reasoning about and, eventually, designing large
  7953. biomolecules such as DNA, RNA, and proteins, with the aid of the
  7954. computer. The complexity of these molecules necessitates sophisticated
  7955. algorithmic and organizational models and techniques in order to keep the
  7956. computational requirements within acceptable ranges. High-performance
  7957. computing and parallel computation are an important aspect of Molecular
  7958. Bioinformatics. On the one hand, chemists have a well-developed tradition
  7959. of using high-performance computers. On the other hand, many of the
  7960. problems involved can only be tackled if the highest computing power
  7961. available is used effectively.
  7962.  
  7963. Contents
  7964.      I    Introduction to the biomolecular background.
  7965.      II   Alignment of biomolecular sequences (DNA, RNA, Proteins) and the
  7966.           detection of evolutionary relationships between such sequences
  7967.           (phylogenetic trees).
  7968.      III  Modeling of large biomolecules, including the prediction and
  7969. analysis of
  7970.           secondary and higher-level structure as well as spatial
  7971. conformations
  7972.           (folding).
  7973.      IV    Molecular dynamics and simulations of interactions between
  7974. biomolecules.
  7975.  
  7976. Biography
  7977. Thomas Lengauer is a director of the Institute of Foundations of
  7978. Information Technology at the Federal Research Center for Computer
  7979. Science (GMD) in St. Augustin, Germany. He is also Professor of Computer
  7980. Science at the University of Bonn. His research interests are in the area
  7981. of efficient algorithms and their application in science and technology.
  7982. Applications besides molecular biology that he is interested in are:
  7983. circuit design and layout, parallel computation, and cutting problems in
  7984. manufacturing.
  7985.  
  7986.  
  7987. TUTORIAL 2: NEURAL NETWORKS, FROM THEORY TO APPLICATIONS
  7988.  
  7989. Presenter: Francoise Fogelman Soulie, LRI, University of Orsay, France
  7990.  
  7991. Objectives
  7992. Participants in this tutorial will learn about advanced Neural Network
  7993. techniques. Efficient methods will be given for training the complex,
  7994. hybrid architectures required for real-world problems. Through a survey
  7995. of applications, the tutorial will assess the technology's realizations
  7996. and provide a development methodology. Parallel implementations of Neural
  7997. Networks will be discussed.
  7998.  
  7999. Contents
  8000.      I    General introduction to Neural Networks. Overview of industrial
  8001.           implementations.
  8002.      II   Survey of major Neural Network learning algorithms: Adaline,
  8003. Perceptron,
  8004.           Multi-Layer Networks, Learning Vector Quantisation, Radial
  8005. Basis Function,
  8006.           Topological Maps.
  8007.      III  Neural Networks and Pattern Recognition: theoretical links with
  8008. the
  8009.           Bayesian Classifier, computing and generalisation capabilities
  8010. of Multi-
  8011.           Layer Networks, links of Multi-Layer Networks with Principal
  8012. Component
  8013.           Analysis and Discriminant Analysis.
  8014.      IV   Architectures for real-world applications. The need for modular
  8015. design.
  8016.           Cooperation of hybrid techniques (Neural Networks and
  8017. conventional).
  8018.           Training algorithms and examples.
  8019.      V    Development methodology of Neural Network applications:
  8020. detailed case
  8021.           studies will be presented to illustrate the development
  8022. methodology, from
  8023.           various sectors: optical character recognition, security,
  8024. finance, High
  8025.           Energy Physics, control, biology and Medicine.
  8026.      VI   Parallel implementations: algorithms, hardware, language
  8027.  
  8028. Biography
  8029. Francoise Fogelman Soulie is Professor of Computer Science at LRI,
  8030. University of Orsay. She has participated in various ESPRIT projects
  8031. concerned with Neural Networks and their applications. She was a
  8032. co-founderof Mimetics. She is vice-president of the European Neural
  8033. Networks Society, and an editor for a number of Neural Networks journals.
  8034. Her research interests are on Neural Networks and their use, in
  8035. conjunction with other methods (eg Pattern Recognition and AI), to
  8036. develop industrial applications.
  8037.  
  8038.  
  8039. TUTORIAL 3: OBJECT-ORIENTED CONCURRENT PPROGRAMMING
  8040.  
  8041. Presenter: Jean-Pierre Briot, Dept. of Information Science, The
  8042. University of
  8043.            Tokyo, Japan and LITP, Institut Blaise Pascal, Paris, France.
  8044.  
  8045. Objectives
  8046. This tutorial introduces the basic concepts and methodology of
  8047. object-oriented concurrent programming. Object-oriented concurrent
  8048. programming is a natural integration of object-oriented programming and
  8049. concurrent programming. The resulting programming methodology allows
  8050. large programs to be decomposed into a collection of small modules that
  8051. run and interact concurrently and which are capable of exploiting
  8052. parallel hardware. The tutorial covers both a progressive introduction to
  8053. the concepts, a number of program examples, and a survey of the current
  8054. state of the art.
  8055.  
  8056. Contents
  8057.      I    Introduction
  8058.      II   From Passive Objects to Active Objects
  8059.      III  Concepts
  8060.      IV   Example of Programming Language: ConcurrentSmalltalk
  8061.      V    Programming Methodology and Examples in ConcurrentSmalltalk
  8062.      VI   Implementing Active Objects: Actalk
  8063.      VII  The Actor Model of Computation
  8064.      VIII Survey/Comparison of Main OOCP Languages
  8065.      IX   Present and Future, Conclusion, and Bibliography
  8066.  
  8067. Biography
  8068. Jean-Pierre Briot is a researcher at LITP, University of Paris-VI. He is
  8069. currently visiting the Department of Information Science, University of
  8070. Tokyo. He participated in the design of several OOCP languages and
  8071. platforms, and their applications to computer music and distributed AI.
  8072. He co-headed an ESPRIT parallel computing action to develop an OOCP
  8073. programming environment for multiprocessors. He has performed tutorials
  8074. on OOCP at the main OOP conferences (TOOLS, ECOOP and OOPSLA).
  8075.  
  8076.  
  8077. TUTORIAL 4: AUTOMATIC PARALLELISATION FOR DISTRIBUTED-MEMORY SYSTEMS
  8078.  
  8079. Presenter: Hans P. Zima, Institute for Software Technology and Parallel
  8080. Systems,
  8081.            University of Vienna, Austria
  8082.  
  8083. Objectives
  8084. In this tutorial, we describe the current state of the art in compiling
  8085. procedural languages (in particular, Fortran) for distributed-memory
  8086. multiprocessing systems (DMMPs), analyze the limitations of these
  8087. approaches, and outline future research. We introduce the language
  8088. extensions of Vienna Fortran which allow the user to write programs for
  8089. DMMPs using global addresses, and to specify the distribution of data
  8090. across the processors of the machine. We also introduce Message Passing
  8091. Fortran (MPF), a Fortran extension that allows the formulation of
  8092. explicitly parallel programs which communicate via explicit message
  8093. passing.
  8094.  
  8095. Contents
  8096.      I    Current programming practice on DMMPs by means of a simple
  8097. example.
  8098.      II   A programming model is introduced and an informal overview of
  8099. the relevant
  8100.           elements of Vienna Fortran and MPF is provided.
  8101.      III  Basic parallelisation is described by discussing the individual
  8102. phases
  8103.           involved in the translation from Vienna Fortran to MPF. This
  8104. includes a
  8105.           discussion of the procedures and various optimisation
  8106. techniques.
  8107.      IV   Additional optimisation methods and advanced parallelization
  8108. techniques
  8109.           including run-time analysis.
  8110.      V    An overview of related work and a discussion of open research
  8111. issues.
  8112.  
  8113. Biography
  8114. Hans P. Zima is Professor for Computer Science, University of Vienna,
  8115. Austria, and Adjunct Professor, Computer Science, Rice University, USA.
  8116. He is also Director of the Austrian Center for Parallel Computation
  8117. (ACPC). He guided the development of Vienna Fortran, one of the major
  8118. inputs for the High Performance Fortran effort. His main research
  8119. interests are in the field of advanced programming environments for
  8120. parallel machines, in particular automatic parallelisation for
  8121. distributed-memory machines, performance analysis, and knowledge-based
  8122. transformation systems. He currently leads research efforts in the
  8123. context of the ESPRIT III projects PREPARE and PPPE.
  8124.  
  8125.  
  8126.                               PAPER PRESENTATIONS
  8127.  
  8128. TUESDAY, 15th JUNE 1993
  8129.  
  8130. 09.00 - 09.30: Welcome
  8131.  
  8132. 09.30 - 10.30: Plennary Session: The Rubbia Committee Report
  8133.                B. Hertzberger, University of Amsterdam, The Netherlands
  8134.  
  8135. 10.30 - 11.00: BREAK
  8136.  
  8137. 11.00 - 12.30: Parallel Sessions
  8138.  
  8139. Track a: Architectures: Virtual Shared Memory
  8140. ---------------------------------------------
  8141. Simulation-based Comparison of Hash Functions for Emulated Shared Memory,
  8142. J. Keller
  8143.      & C. Engelmann, Universit!t des Saarlandes, Germany
  8144. Task Management, Virtual Shared Memory, and Multithreading in a
  8145. Distributed Memory
  8146.      Implementation of Sisal, M. Haines & W. B!hm, Colorado State
  8147. University, USA
  8148. Simulating the Data Diffusion Machine, E. Hagersten, M. Grindal, A.
  8149. Landin,
  8150.      A. Saulsbury, B. Werner & S. Haridi, SICS, Sweden
  8151.  
  8152. Track b: Functional Programming
  8153. -------------------------------
  8154. 2 DT-FP : An FP Based Programming Language for Efficient Parallel
  8155. Programming of
  8156.      Multi Processors Networks, R. Wilhelm, Y. Ben Asher, G. R!nger & A.
  8157. Schuster,
  8158.      Universitaet des Saarlandes, Germany
  8159. The Data-Parallel Categorial Abstract Machine, Ga!tan Hains & Christian
  8160. Foisy,
  8161.      Universite Montreal, Canada
  8162. Data Parallel Implementation of Extensible Sparse Functional Arrays,
  8163.      J. T. O!Donnell, University of Glasgow, UK
  8164.  
  8165. 12.30 - 14.00: LUNCH: Bavarian Specialities
  8166.  
  8167. 14.00 - 15.30: Parallel Sessions
  8168.  
  8169. Track a: Interconnection Networks: Embeddings
  8170. ---------------------------------------------
  8171. Embeddings of Tree-Related Networks in Incomplete Hypercubes, S. Oehring,
  8172. S. K. Das,
  8173.      Universitaet Wuerzburg, Germany
  8174. Static and Dynamic Performance of the M!bius Cubes, P. Cull, S. Larson,
  8175. Oregon State
  8176.      University, USA
  8177. Optimal Mappings of a m Dimensional FFT Communication to a k Dimensional
  8178. Mesh for
  8179.      Arbitrary m and k, Z. G. Mou, X. Wang, Brandeis University, USA
  8180.  
  8181. Track b: Vendor Session 1
  8182. -------------------------
  8183.  
  8184. 15.30 - 16.00: BREAK
  8185.  
  8186. 16.00 - 18.00: Parallel Sessions
  8187.  
  8188. Track a: Language Issues
  8189. ------------------------
  8190. Implicit Parallelism: The United Functions and Objects Approach, J.
  8191. Sargeant,
  8192.      University of Manchester, UK
  8193. Detection of Reductions in Sequential Programs, X. Redon & P. Feautrier,
  8194. Universite
  8195.      Versailles-St. Quentin, France
  8196. Parallel Programming Using Skeleton Functions, R. L. While, J. Darlington,
  8197.      A.J. Field, P.G. Harrison et al., Imperial College, UK
  8198. Data-parallel portable software platform: principles and implementation,
  8199.      A. V. Shafarenko, C. Sutton & V. B. Muchnick, University of Surrey,
  8200. UK
  8201.  
  8202. Track b: Concurrency: Responsive Systems
  8203. -----------------------------------------
  8204. A Compositional Approach to Fault-Tolerance Using Specification
  8205. Transformation,
  8206.      D. Peled & M. Joseph, AT&T Bell Laboratories, USA
  8207. Concurrent METATEM-A Language for Modelling Reactive Systems, M. Fisher,
  8208.      University of Manchester, UK
  8209. Trace-based Compositional Reasoning about Fault Tolerant Systems, Henk
  8210. Schepers,
  8211.      Jozef Hooman, Eindhoven University of Technology, The Netherlands
  8212. A Kahn principle for networks of nonmontonic real-time processes, R. K.
  8213. Yates &
  8214.      G. R. Gao, McGill University, Canada
  8215.  
  8216. 20.00: RECEPTION     Munich Town Hall
  8217.  
  8218.  
  8219.  
  8220. WEDNESDAY, 16th JUNE 1993
  8221.  
  8222. 9.00 - 9.30: Bavarian Secretary of State, Dr. Wiesheu
  8223.  
  8224. 9.30 - 11.00: Plenary Session
  8225.  
  8226. 11.00 - 11.30: BREAK
  8227.  
  8228. 11.30 - 13.00: Parallel Sessions
  8229.  
  8230. Track a: Interconnection Networks: Routing
  8231. ------------------------------------------
  8232. Adaptive Multicast Wormhole Routing in 2D Mesh Multicomputers, A.-H.
  8233. Esfahanian,
  8234.      X. Lin, P. K. McKinley, Michigan State University, USA
  8235. The Impact of Packetization in Wormhole-Routed Networks, J. H. Kim & A.
  8236. A. Chien,
  8237.      University of Illinois at Urbana-Champaign, USA
  8238. Grouping Virtual Channels for Deadlock!Free Adaptive Wormhole Routing, Z.
  8239. Liu,
  8240.      Royal Institute of Technology, Sweden
  8241.  
  8242. Track b: Logic Programming
  8243. --------------------------
  8244. Monaco: A High-Performance Flat Concurrent Logic Programming System, Evan
  8245. Tick,
  8246.      University of Oregon, USA
  8247. Exploiting Recursion-Parallelism in Prolog, J. Bevemyr, T. Lindgren & H.
  8248. Millroth,
  8249.      Uppsala University, Sweden
  8250. Why and How in the ElipSys OR!parallel CLP System, A. V!ron, K.
  8251. Schuerman, M. Reeve
  8252.      & L.-L. Li, ECRC, Germany
  8253.  
  8254. 13.00 - 14.00: LUNCH
  8255.  
  8256. 14.00 - 15.30: Parallel Sessions
  8257.  
  8258. Track a: Poster Session
  8259. -----------------------
  8260.  
  8261. Track b: Vendor Session 2
  8262. -------------------------
  8263.  
  8264. 15.30 - 16.00 BREAK
  8265.  
  8266. 16.00 - 18.00 Parallel Sessions
  8267.  
  8268. Track a: Architectures: Caches
  8269. ------------------------------
  8270. Skewed-associative Caches, A. Seznec & F. Bodin, IRISA, France
  8271. Trace-Splitting for the Parallel Simulation of Cache Memory, N.
  8272. Ironmonger,
  8273.      ETH Zentrum, Switzerland
  8274. Locality and False Sharing in Coherent-Cache Parallel Graph Reduction, A.
  8275. Bennett &
  8276.      P. Kelly, Imperial College, UK
  8277. SLiD!A Cost-Effective and Scalable Limited!Directory for Cache Coherence,
  8278. G. Chen,
  8279.      New York University, USA
  8280.  
  8281. Track b: Concurrency: Semantics
  8282. -------------------------------
  8283. Actor Programs Formal Development Using Structured Algebraic Petri Nets,
  8284. N. Guelfi &
  8285.      D. Buchs, University of Geneva, Switzerland
  8286. A Parallel Programming Style and Its Algebra of Programs, C. Hankin, D.
  8287. Le Metayer &
  8288.      D. Sands, Imperial College, UK
  8289. B(PN) - a Basic Petri Net Programming Notation, E. Best & R. P. Hopkins,
  8290. Univesitaet
  8291.      Hildesheim, Germany
  8292. A Calculus of Value Broadcasts, K. V. S. Prasad, Chalmers University of
  8293. Technology,
  8294.      Sweden
  8295.  
  8296. 18.30 - 19.30: Poster Session
  8297.  
  8298. 20.00: BANQUET     Marriott Hotel
  8299.  
  8300.  
  8301.  
  8302. THURSDAY, 17th JUNE 1993
  8303.  
  8304. 9.00 - 10.00: Parallel Sessions
  8305.  
  8306. Track a: Tools
  8307. --------------
  8308. TRAPPER : A Graphical Programming Environment for Industrial
  8309. High-Performance
  8310.      Applications, C. Scheidler, L. Schaefers & O. Kraemer-Fuhrmann,
  8311. Daimler-Benz AG,
  8312.      Germany
  8313. Control and Data Flow Visualization for Parallel Logic Programs on a
  8314. Multi-window
  8315.      Debugger HyperDEBU, J. Tatemura, H. Koike & H. Tanaka, University of
  8316. Tokyo
  8317.  
  8318. Track b: Neural Networks
  8319. ------------------------
  8320. Artificial Neural Networks for the Bipartite and K!partite Subgraph
  8321. Problems,
  8322.      J!S. Lai & S!Y. Kuo, National Taiwan University, R. O. China
  8323. Homogeneous Neuronlike Structures for Optimisation Variational Problem
  8324. Solving,
  8325.      I. A. Kalyayev, Scientific Research Institute of Multiprocessor
  8326. Computing,
  8327.      Russia
  8328.  
  8329. 10.00 - 10.30: BREAK
  8330.  
  8331. 10.30 - 12.30: Parallel Sessions
  8332.  
  8333. Track a: Scheduling
  8334. -------------------
  8335. Effectiveness of Heuristics and Simulated Annealing for the Scheduling of
  8336. Concurrent
  8337.      Tasks!An Empirical Comparison, Z. Liu & C. Coroyer, INRIA, France
  8338. Task Scheduling with Restricted Preemptions, K. Ecker & R. Hirschberg,
  8339. Technische
  8340.      Universitaet Clausthal, Germany
  8341. Effects of Job Size Irregularity on the Dynamic Resource Scheduling of a
  8342. 2!D Mesh
  8343.      Multicomputer, D. Min & M. W. Mutka, Michigan State University, USA
  8344. Static Allocation of Tasks on Multiprocessor Architectures with
  8345. Interprocessor
  8346.      Communication Delays, S. Norre, Universit! Blaise
  8347. Pascal!Clermont!Ferrand II,
  8348.      France
  8349.  
  8350. Track b: Specification & Verification
  8351. -------------------------------------
  8352. PEI: a single unifying model to design parallel programs, E. Violard &
  8353. G-R. Perrin,
  8354.      University of Franche-Comte, France
  8355. Correctness of Automated Distribution of Sequential Programs, Cyrille
  8356. Bareau,
  8357.      Benoit Caillaud, Claude Jard, Rene Thoraval, IRISA, France
  8358. Compositionality Issues of Concurrent Object-Oriented Logic Languages, E.
  8359. Pimentel,
  8360.      J. M. Troya, Universidad de Malaga, Spain
  8361. Using State Variables for the Specification and Verification of TCSP
  8362. Processes,
  8363.      Luis M. Alonso, R. Pena Mari, Universidad del Pais Vasco, Spain
  8364.  
  8365. 12.30 - 14.00: LUNCH
  8366.  
  8367. 14.00 - 15.30: Parallel Sessions
  8368.  
  8369. Track a: Algorithms
  8370. -------------------
  8371. A Parallel Reduction of Hamiltonian Cycle to Hamiltonian Path in
  8372. Tournaments,
  8373.      E. Bampis, M. El Haddad, Y. Manoussakis & M. Santha, Universite de
  8374. Paris-Sud,
  8375.      France
  8376. A Unifying Look at Semigroup Computations on Meshes with Multiple
  8377. Broadcasting,
  8378.      S. Olariu, D. Bhagavathi, W. Shen & L. Wilson, Old Dominion
  8379. University, USA
  8380. A fast, simple algorithm to balance a parallel multiway merge, R.S.
  8381. Francis,
  8382.      I. D. Mathieson & L. J. H. Pannan, CSIRO, Australia
  8383.  
  8384. Track b: Vendor Session 3
  8385. -------------------------
  8386.  
  8387. 15.30      16.00: BREAK
  8388.  
  8389. 16.00 - 17.30: Parallel Sessions
  8390.  
  8391. Track a: Architectures: Fine Grain Parallelism
  8392. ----------------------------------------------
  8393. Some Design Aspects for VLIW Architectures Exploiting Fine-Grained
  8394. Parallelism,
  8395.      W. Karl, Technische Universitaet Muenchen, Germany
  8396. Load Balanced Optimisation of Virtualised Algorithms for implementation
  8397. on Massively
  8398.      Parallel SIMD Architectures, C. A. Farell & D. H. Kieronska, Curtin
  8399. University,
  8400.      Australia
  8401. Performance evaluation of WASMII: a data flow machine based on the
  8402. virtual hardware,
  8403.      X.-P. Ling & H. Amano, Keio University, Japan
  8404.  
  8405. Track b: Databases
  8406. ------------------
  8407. On the Performance of Parallel Join Processing in Shared Nothing Database
  8408. Systems,
  8409.      E. Rahm, R. Marek, Universit!t Kaiserslautern, Germany
  8410. Processing Transactions on Grip, a Parallel Graph Reducer, G. Akerholt,
  8411. K. Hammond,
  8412.      S. Peyton Jones & P. Trinder, Glasgow University, UK
  8413. Arithmetic for Parallel Linear Recursive Query Evaluation in Deductive
  8414. Databases,
  8415.      J. Robinson & S. Lin, University of Essex, UK
  8416.  
  8417.  
  8418.                                POSTER PAPERS
  8419.  
  8420. Computing the Complete Orthogonal Decomposition Using a SIMD Array
  8421. Processor,
  8422.      E. J. Kontoghiorghes, Queen Mary and Westfield College, UK
  8423. A Dynamic Load Balancing Strategy for Massively Parallel Computers, D.
  8424. Talia,
  8425.      M. Cannataro & Y. D. Sergeyev, CRAI, Italy
  8426. Issues in Event Abstraction, T. Kunz, Technische Hochschule Darmstadt,
  8427. Germany
  8428. Modelling Replicated Processing, M. Koutny, L. V. Mancini & G. Pappalardo,
  8429.      University of Newcastle upon Tyne, UK
  8430. Procedures for Folding Transformations, M. Gusev & D. J. Evans,
  8431. Loughborough
  8432.      University, UK
  8433. Performance Analysis of M3S: a Serial Multiported Memory Multiprocessor,
  8434.      Ch. Rochange, P. Sainrat & D. Litaize, Universite Paul Sabatier,
  8435. France
  8436. Multi-Criteria : Degrees of Recoverability in Distributed Databases, M.
  8437. Nyg!rd,
  8438.      The Norwegian Institute of Technology, Norway
  8439. Deadlock-Free Adaptive Routing Algorithms for the 3D-Torus: Limitations
  8440. and
  8441.      Solutions, P. Lopez & J. Duato, Universidad Politecnica de Valencia,
  8442. Spain
  8443. Convergence of Asynchronous Iterations of Least Fixed Points, J. Wei, GMD
  8444. Karlsruhe,
  8445.      Germany
  8446. Efficient Parallel Simulation of Neural Networks, A. Zell, H. Bayer, R.
  8447. Huebner,
  8448.      N. Mache & M. Vogt, Stuttgart Universitaet, Germany
  8449. Improve Instruction Bandwidth through Compact Encoding, O. S. Schoepke,
  8450. University
  8451.      of Bath, UK
  8452. LU-Decomposition on a Massively Parallel Transputer System, S. Luepke,
  8453. Technische
  8454.      Universitaet Hamburg, Germany
  8455. PSEE: Parallel System Evluation Environment, E. Luque, R. Suppi & J.
  8456. Sorribes,
  8457.      Universitat Autonoma de Barcelona, Spain
  8458. An Algorithm for distributing a finite transition system on a
  8459. shared/distributed
  8460.      memory system, P. Caspi & A. Girault, LGI/IMAG, France
  8461. Implementation of a Digital Modular Chip for a Reconfigurable Artificial
  8462. Neural
  8463.      Network, P. Plaskonos, S. Pakzad, B. Jin & A. R. Hurson,
  8464. Pennsylvania State
  8465.      University, USA
  8466. Article!Acquisition: A Scenario for Non!Serializability in a Distributed
  8467. Database,
  8468.      M. Nygard, The Norwegian Institute of Technology, Norway
  8469. An Empirical Study of Vision Programs for Data Dependence Analysis, L. A.
  8470. Barragan &
  8471.      A. Roy, Universidad de Zaragoza, Spain
  8472. Cyclic Weighted Reference Counting without Delay, R. E. Jones & R. D.
  8473. Lins,
  8474.      University of Canterbury, UK
  8475. Parallel Optimisation of Join Queries Using an Enhanced Iterative
  8476. Improvement,
  8477.      M. Spiliopoulou, Y. Cotronis & M. Hatzopoulos, University of Athens,
  8478. Greece
  8479. Distributed Data Structures in Distributed Shortest Path Algorithms, J.
  8480. L. Traeff,
  8481.      University of Copenhagen, Denmark
  8482. A Routing and Broadcasting Scheme on Faulty Star Graphs, N. Bagherzadeh &
  8483. N. Nassif,
  8484.      University of California, USA
  8485. A Disabling of Event Structures, N. Anisimov, Far East Division of the
  8486. Russian
  8487.      Academy of Sciences, Russia
  8488. Barrier Semantics in Very Weak Memory, R.S. Francis & A. N. Pears, LaTrobe
  8489.      University, Australia
  8490. Using Hammock Graphs to Eliminate Nonstructured Branch Statements, F.
  8491. Zhang &
  8492.      E. H. D'Hollander, University of Ghent, Belgium
  8493. Performance Modeling of Micro-kernel Thread Schedulers for Shared Memory
  8494.      Multiprocessors, W. Van de Velde, J. Opsommer & E. H. D'Hollander,
  8495. University
  8496.      of Ghent, Belgium
  8497. A Semantic Model of Data Flow Networks based on Process Algebras, C.
  8498. Bernardeschi,
  8499.      A. Bondavalli & L. Simoncini, CNUCE!CNR, Italy
  8500. On the Time Complexity of Parallel Algorithms for Lattice Basis Reduction,
  8501.      C. Heckler & L. Thiele, Universit!t des Saarlands, Germany
  8502. Computer Vision Applications Experience with Actors, M. Di Santo, F.
  8503. Arcelli,
  8504.      M. De Santo & A. Picariello, Universita di Salerno, Italy
  8505. Grid Massively Parallel Processor, V.P. Il'in & Y. I. Fet, Siberian
  8506. Division of the
  8507.      Russian Academy of Sciences, Russia
  8508.  
  8509.  
  8510.                             STEERING COMMITTEE
  8511.  
  8512. The PARLE conferences are controlled by a Steering Committee consisting
  8513. of some of the most renowned European experts:
  8514. Werner Damm (U. of Oldenburg, D)           Jean!Claude Syre (Bull SA, F)
  8515. Jose Delgado (INESC, P)                    Jorgen Staunstrup (TU Denmark,
  8516. DK)
  8517. Lucio Grandinetti (U. of Calabria, I)      Mateo Valero (U. of Catalunya,
  8518. E)
  8519. Constantin Halatsis (U. of Athens, GR)     Thierry Van der Pyl (DGXIII,
  8520. CEC)
  8521. Ron Perrot (u. of Belfast, UK)             Pierre Wolper (U. of Liege, B)
  8522. Martin Rem (TU Eindhoven, NL)
  8523.  
  8524.  
  8525.                             ORGANISING COMMITTEE
  8526.  
  8527. PARLE!93 is being organised by a committee consisting of:
  8528. Arndt Bode (TU Munich, D)                  Masaru Kitsuregawa (U. of
  8529. Tokyo, J)
  8530. Werner Damm (U. of Oldenburg, D)           Rudi Kober (Siemens/ZFE, D)
  8531. Doug DeGroot (TI/CSC, USA)                 Michael Ratcliffe (ECRC, D)
  8532. Ulrike Jendis, (ECRC, D)                   Mike Reeve (ECRC, D)
  8533. Peter Kacsuk (KFKI, H)                     Gottfried Wolf (DLR, D)
  8534.  
  8535.  
  8536.                   GENERAL INFORMATION, TERMS AND CONDITIONS
  8537.  
  8538. OFFICIAL CONFERENCE ADDRESS
  8539. ECRC GmbH (PARLE!93), Arabellastrasse 17, 8000 Munich 81, Germany
  8540. tel. ++49 89 926990    fax. ++49 89 92699!170
  8541.  
  8542. CONFERENCE VENUE
  8543. Marriott Hotel, Berlinerstrasse 93, 8000 Munich 40, Germany
  8544. tel: ++49 89 360020    fax: ++49 89 3600220
  8545.  
  8546. CONFERENCE DATE
  8547. June 14!18, 1993
  8548.  
  8549. LANGUAGE
  8550. The official conference language is English
  8551.  
  8552. ENTRY VISA
  8553. Non-EEC residents may require an entry visa to enter Germany. Please
  8554. check with your local German consulate as early as possible.
  8555.  
  8556. ACCESS TO MUNICH CITY CENTRE
  8557. By plane: Munich International Airport is directly connected by the S8
  8558. commuter line; a station is located in the central area of the airport.
  8559. Leave the train at !Marienplatz!. The journey takes about 45 minutes.
  8560. By train: Take any !S! commuter train from the central station in the
  8561. direction of !Ostbahnhof! as far as !Marienplatz!. Look out for the green
  8562. signs showing a white letter !S!.
  8563.  
  8564. ACCESS TO THE MARRIOTT HOTEL
  8565. By public transport: Proceed from !Marienplatz! on the underground line
  8566. !U6! in the direction of !Kieferngarten! as far as !Nordfriedhof!. Leave
  8567. the station by the exit at the rear end of the train and follow the signs
  8568. to the Marriott Hotel.
  8569. By car: The hotel is located near the Schwabing exit of National Highway
  8570. 9 (Nurnberg!Munich)
  8571.  
  8572. REGISTRATION PROCEDURE
  8573. Advanced: The enclosed tear!off form and payment must be received by the
  8574. organisers by April 30th, 1993. Completed forms should be sent to the
  8575. official conference address given above.
  8576. On-site: The Registration Desk will be open on Sunday, June 13th, between
  8577. 18.00 and 20.00, and on each day of the conference from 8.30 until 17.00.
  8578. Fees: Registration fees include access to all conference sessions, one
  8579. copy of the conference proceedings, access to the Industrial Exhibition,
  8580. lunches, coffee breaks, and a ticket for the conference reception and
  8581. banquet. The special student rate does not include a copy of the
  8582. proceedings or a ticket for the banquet.
  8583.  
  8584. PAYMENT
  8585. Payment will only be accepted in German Marks. Fees may be paid by cash,
  8586. credit card (VISA or JCB), Eurocheque or direct bank credit transfer to:
  8587. bank:             Dresdner Bank, Munich, Germany
  8588. sorting code:     700 800 00
  8589. account number:   3008 630/01
  8590. account holder:   ECRC GmbH (wgn. PARLE!93)
  8591. Please be sure to ask your bank to indicate your name and !PARLE!93!
  8592. along with any payments. Any banking charges incurred for processing your
  8593. payments will be charged directly to you.
  8594.  
  8595. CANCELLATIONS
  8596. Refunds of 50% of the fee already paid can only be made if a written
  8597. request is received by April 30th, 1993.
  8598. Should the PARLE!93 conference be cancelled for reasons beyond the
  8599. organisers! control, liability is limited to the paid registration fees.
  8600.  
  8601. PROCEEDINGS
  8602. Extra copies of the conference proceedings will be available from the
  8603. Reception Desk at a specially reduced conference price.
  8604.  
  8605. SOCIAL EVENTS
  8606. Reception: The official reception will be held in the historic !Alte
  8607. Rathaussaal!, the ancient seat of the Mayor of Munich, on June 15th.
  8608. Banquet: A banquet has been organised for June 16th.
  8609. Excursions: A wide variety of picturesque and interesting tours can be
  8610. booked through the Marriott Hotel.
  8611.  
  8612. HOTEL ROOM RESERVATIONS AT THE MARRIOTT HOTEL
  8613. A special discount rate is available for people attending PARLE!93 and
  8614. their guests. This is only available by returning the attached tear-off
  8615. registration form to the organisers before April 30th, 1993.
  8616.  
  8617. SPONSORSHIP
  8618. The organisers of PARLE!93 are grateful to be able to acknowledge the
  8619. support of the following organisations: AFCET, CEPIS, the Commission of
  8620. the European Communities, The Dresdner Bank AG, ECRC GmbH, GI, ITG, the
  8621. Technische Universitaet Muenchen.
  8622.  
  8623.  
  8624.                             CONFERENCE ATTENDENCE FEES
  8625.  
  8626. The registration fees include access to all conference sessions, the
  8627. Industrial Exhibition, lunches, coffee breaks, a copy of the conference
  8628. proceedings, a ticket for the banquet and reception.
  8629.  
  8630.                                        Advanced Registration    Late
  8631. Registration
  8632.                                         (before April 30th)     (after
  8633. April 30th)
  8634.  
  8635.      Members of supporting
  8636.      organisations (AFCET, CEPIS, GI, ITG)     DM725
  8637. DM825
  8638.  
  8639.      Students*                                 DM350
  8640. DM450
  8641.  
  8642.      Normal registration fee                   DM825
  8643. DM925
  8644.  
  8645.   *this special student rate does not include a copy of the conference
  8646. proceedings
  8647.    or a ticket for the banquet. Student status will only be acknowledged
  8648. if your
  8649.    registration is accompanied by a copy of a valid student identity card.
  8650.  
  8651.      Tutorial attendance fee          DM275 for one tutorial
  8652.      Extra tickets for the banquet    DM125 each
  8653.      Extra tickets for the reception  DM50  each
  8654.  
  8655. -----------------------------------------------------------------------
  8656.  
  8657.                              PARLE'93 REGISTRATION FORM
  8658.  
  8659. Please write clearly and return to the official conference address given
  8660. above.
  8661.  
  8662.  
  8663. PERSONAL INFORMATION
  8664. -----------------------------------------------------------------------
  8665.  
  8666.   last name                                      first name
  8667. -----------------------------------------------------------------------
  8668.  
  8669.   address
  8670. -----------------------------------------------------------------------
  8671.  
  8672.  
  8673. -----------------------------------------------------------------------
  8674.  
  8675.   country
  8676. -----------------------------------------------------------------------
  8677.  
  8678.   telephone                                      fax
  8679. -----------------------------------------------------------------------
  8680.   email
  8681. -----------------------------------------------------------------------
  8682.  
  8683.  
  8684. HOTEL RESERVATIONS FOR THE MARRIOTT
  8685. The special PARLE'93 rates of DM195 per night (single room) or DM215 per
  8686. night (double room) are only available when your completed registration
  8687. form is returned by April 30th, 1993. The information given in this part
  8688. will be given to the Marriott Hotel and processed directly by them. Any
  8689. changes in your requirements should be referred to the Marriott Hotel.
  8690. Payment should be made directly to the hotel on your departure.
  8691.  
  8692. Please Reserve:
  8693.  
  8694.       single room(s) for the nights of        to        June 1993
  8695. inclusive
  8696.   ----                                 ------    ------
  8697.  
  8698.       double room(s) for the nights of        to        June 1993
  8699. inclusive
  8700.   ----                                 ------    ------
  8701.  
  8702.  
  8703. REGISTRATION FEES
  8704. Student registrations should be accompanied by a copy of a student
  8705. identity card valid for the current academic year. The conference fees
  8706. are given above.
  8707.  
  8708.      conference registration fee:    DM
  8709.                                          -----------
  8710.      tutorial registration fee:      DM              for tutorial number
  8711.                                          -----------
  8712. -----
  8713.            extra banquet tickets:    DM
  8714.      -----                               -----------
  8715.            extra reception tickets:  DM
  8716.      -----                               -----------
  8717.  
  8718.                      TOTAL SUM DUE:  DM
  8719.                                          ===========
  8720.  
  8721. PAYMENT
  8722. Registration is only valid once the full payment has been received.
  8723. Credit card payments are only possible for VISA or JCB account holders.
  8724.  
  8725. I prefer to pay: (please tick as appropriate)
  8726.  
  8727.        by Eurocheque (enclosed)          by direct transfer        by
  8728. credit card
  8729.   ----                               ----                      ----
  8730.  
  8731.  
  8732. If you prefer to pay by credit card, please complete the authorisation
  8733. below:
  8734.  
  8735.   I authorise you to charge the following credit card with the sum of DM
  8736.  
  8737. ----------
  8738.  
  8739.  
  8740. -----------------------------------------------------------------------
  8741.      card type: VISA or JCB            card number
  8742.  
  8743. -----------------------------------------------------------------------
  8744.      card expiry date                  holder's name
  8745.  
  8746. -----------------------------------------------------------------------
  8747.      date                              signature
  8748.  
  8749. -----------------------------------------------------------------------
  8750.  
  8751.  
  8752. Please complete the following if you are paying a reduced fee for being a
  8753. member of one of the PARLE'93 supporting organisations (i.e. AFCET, ITG,
  8754. GI)
  8755.  
  8756.   I am a member of                                       (name of
  8757. organisation)
  8758.                    -------------------------------------
  8759.  
  8760.  
  8761. -----------------------------------------------------------------------
  8762.     membership number
  8763.  
  8764. -----------------------------------------------------------------------
  8765.     date                               signature
  8766.  
  8767. -----------------------------------------------------------------------
  8768.  
  8769.  
  8770. MISCELLANEOUS
  8771. Please tick as appropriate:
  8772.  
  8773.        please do not include my address in any published mailing lists
  8774.   ----
  8775.        please provide me with a receipt for the registration fees
  8776.   ----
  8777. -- 
  8778. Send compilers articles to compilers@iecc.cambridge.ma.us or
  8779. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  8780.  
  8781.  
  8782. From compilers Wed Apr 14 19:12:10 EDT 1993
  8783. Newsgroups: comp.compilers
  8784. Path: iecc!compilers-sender
  8785. From: jbowyer@cis.vutbr.cs (Bowyer Jeff)
  8786. Subject: Internationalization mailing list
  8787. Message-ID: <93-04-050@comp.compilers>
  8788. Keywords: i18n
  8789. Sender: compilers-sender@iecc.cambridge.ma.us
  8790. Reply-To: jbowyer@cis.vutbr.cs
  8791. Organization: Technical University of Brno, Czech Republic
  8792. Date: Wed, 14 Apr 1993 09:51:59 GMT
  8793. Approved: compilers@iecc.cambridge.ma.us
  8794.  
  8795. We want you to announce your work on our mailing list!
  8796.  
  8797.      Do you use a program that has a non-English interface?
  8798.  
  8799.      Have you converted any software to support more than one language for
  8800.      its interface?
  8801.  
  8802.      Will you sponsor a conference that might concern software with a
  8803.      non-English interface?
  8804.  
  8805. Please tell us!
  8806.  
  8807. INSOFT-L@CIS.VUTBR.CS            Internationalization of Software
  8808.                                     Discussion List
  8809.  
  8810.    Internationalization of software relates to two subjects:
  8811.  
  8812.         1. Software that is written so a user can easily change the
  8813.            language of the interface;
  8814.  
  8815.         2. Versions of software, such as Czech WordPerfect, whose
  8816.            interface language differs from the original product.
  8817.  
  8818.    Topics discussed on this list will include:
  8819.  
  8820.         -- Techniques for developing new software
  8821.  
  8822.         -- Techniques for converting existing software
  8823.  
  8824.         -- Internationalization tools
  8825.  
  8826.         -- Announcements of internationalized public domain software
  8827.  
  8828.         -- Announcements of foreign-language versions of commercial
  8829.            software
  8830.  
  8831.         -- Calls for papers
  8832.  
  8833.     -- Conference announcements
  8834.  
  8835.     -- References to documentation related to the
  8836.            internationalization of software
  8837.  
  8838.    This list is moderated.
  8839.  
  8840.    To subscribe to this list, send an electronic mail message to
  8841.    LISTSERV@CIS.VUTBR.CS with the body containing the command:
  8842.  
  8843.       SUB INSOFT-L Yourfirstname Yourlastname
  8844.  
  8845.    Owner:
  8846.  
  8847.       Center for Computing and Information Services
  8848.       Technical University of Brno
  8849.       Udolni 19, 602 00 BRNO
  8850.       Czech Republic
  8851.  
  8852.       INSOFT-L-REQUEST@CIS.VUTBR.CS
  8853. -- 
  8854. Send compilers articles to compilers@iecc.cambridge.ma.us or
  8855. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  8856.  
  8857.  
  8858. From compilers Wed Apr 14 19:13:56 EDT 1993
  8859. Newsgroups: comp.compilers
  8860. Path: iecc!compilers-sender
  8861. From: clark@zk3.dec.com (Chris Clark USSG)
  8862. Subject: Semantic actions in LR parser
  8863. Message-ID: <93-04-051@comp.compilers>
  8864. Keywords: LALR, parse, bibliography
  8865. Sender: compilers-sender@iecc.cambridge.ma.us
  8866. Organization: Compilers Central
  8867. References: <93-04-008@comp.compilers> <93-04-036@comp.compilers>
  8868. Date: Wed, 14 Apr 1993 14:56:35 GMT
  8869. Approved: compilers@iecc.cambridge.ma.us
  8870.  
  8871. I was asked:
  8872. > Ahh, this sounds like you've rediscovered a result similar to the one in
  8873. > Brown, C. & Purdom, P. "Semantic Routines and LR(k) Parsers,"
  8874. > Acta Informatica 14 (1980), 299--315.
  8875.  
  8876. And was courteously sent a copy of the paper by the authors.
  8877.  
  8878. It is a very interesting paper, and it details three types of places where
  8879. (shift) action code may or may not be placed--you can always place action
  8880. code, you can never place action code, and you can sometimes place action
  8881. code.
  8882.  
  8883. The set of places you can always place action code matches the places you
  8884. can put action code in your grammar with yacc and not produce a conflict.
  8885.  
  8886. The set of places you can sometimes place action code match the places
  8887. where in Yacc++(R) the action code must match on several possibilities.
  8888. (This is the same in Karsten Nyblad's parser generator.)
  8889.  
  8890. The set of places you can never place action code will always cause a
  8891. conflict.  However, as Karsten describes, the parser generator can attempt
  8892. to postpone the action by one step of look-ahead without too much trouble.
  8893. (Yacc++ does this too, and there is a caution in the manual about
  8894. interactions with the lexer, since if the action code is designed to cause
  8895. the lexer to return a different token and it is postponed, the directive
  8896. to the lexer won't get to the lexer until after the lexer has returned the
  8897. token!)
  8898.  
  8899. The paper provides some interesting algorithms for calculating where
  8900. action code can be placed.  Of course, in a pragmatic sense, it is just
  8901. easier to run it through the parser generator of your choice and find out
  8902. whether it gets conflicts.  However, if you think the place where your
  8903. action code is placed should be legal, the algorithms in the paper could
  8904. either tell you that--you are right, but you need a better parser
  8905. generator; you need to put some other matching action code in; or you are
  8906. wrong and you need to rethink your semantics.
  8907.  
  8908. The most interesting aspect of the algorithms is that they will tell you
  8909. if adding matching action code into another production will have a
  8910. cascading effect producing new conflicts to be resolved with more matching
  8911. action code and whether the cascade will converge and eventually result in
  8912. a legal grammar or not.  Our parser generator doesn't tell you that.  For
  8913. most common cases, it isn't an issue, because the places to add action
  8914. code converges in one step, but for unusual grammars it would help.
  8915.  
  8916. I hope this was interesting.
  8917.  
  8918. Chris Clark
  8919.  
  8920. I am biased in favor of parser generators and work for,
  8921.  
  8922. Compiler Resources, Inc.
  8923. 3 Proctor St.
  8924. Hopkinton, MA 01748
  8925. (508) 435-5016  fax: (508) 435-4847
  8926.  
  8927. For a technical literature packet (including a price list) send email
  8928. to: bz%compres@primerd.prime.com
  8929. -- 
  8930. Send compilers articles to compilers@iecc.cambridge.ma.us or
  8931. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  8932.  
  8933.  
  8934. From compilers Wed Apr 14 19:14:53 EDT 1993
  8935. Newsgroups: comp.compilers
  8936. Path: iecc!compilers-sender
  8937. From: Todd Hodes <tdh6t@onyx.cs.virginia.edu>
  8938. Subject: Re: Wanted: Regular Expression -> Finite Automata  C code =-
  8939. Message-ID: <93-04-052@comp.compilers>
  8940. Keywords: DFA, books
  8941. Sender: compilers-sender@iecc.cambridge.ma.us
  8942. Organization: University of Virginia Computer Science Department
  8943. References: <93-04-023@comp.compilers> <93-04-041@comp.compilers>
  8944. Date: Wed, 14 Apr 1993 20:06:03 GMT
  8945. Approved: compilers@iecc.cambridge.ma.us
  8946.  
  8947. megatest!plethorax!djones@uu2.psi.com (Dave Jones) writes:
  8948. >
  8949. >Last month I posted an article pointing out two bugs in Sedgewick's Pascal
  8950. >algorithm for matching the NFA against an input string. The bug Todd
  8951. >reports is in the algorithm for building the NFA, in the "C" book, which I
  8952. >have never seen.
  8953.  
  8954.     They are exactly identical.
  8955.  
  8956. >Helpful suggestion: Don't try to salvage the Sedgewick algorithms.  See
  8957. >the New Dragon Book ... Both procedures are sketched out almost correctly
  8958. >in algorithms 3.3 and 3.4.
  8959.  
  8960.     I just have the old one.  From what I understand, it's treatment
  8961. of this topic is the same.  There is no implementation in it, just as
  8962. there was no implementation in the book I was originally working from,
  8963. Hopcroft & Ullman's "Intro to Automata Theory, Languages, & Computation"
  8964. (or some such).  This problem must have been implemented bunches of time
  8965. in the past, and is obviously tricky.  Algorithm 3.3 is correct -- the
  8966. problem is parsing the string into it's constituents, which is equivalent
  8967. to parsing a CFG.  I was hoping to find working code, rather than reinvent
  8968. the wheel.
  8969.  
  8970. Thanks for the pointer, although it wasn't exactly what I needed.
  8971.  
  8972. T.
  8973. --
  8974. Todd Hodes, hodes@cs.Virginia.edu
  8975. -- 
  8976. Send compilers articles to compilers@iecc.cambridge.ma.us or
  8977. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  8978.  
  8979.  
  8980. From compilers Wed Apr 14 19:20:06 EDT 1993
  8981. Xref: iecc comp.lang.c++:34711 alt.sources:6157 comp.compilers:4511
  8982. Newsgroups: comp.lang.c++,alt.sources,comp.compilers
  8983. Path: iecc!compilers-sender
  8984. From: Mayan Moudgill <moudgill@cs.cornell.EDU>
  8985. Subject: C++ Parser toolkit: crude mmap added.
  8986. Message-ID: <93-04-053@comp.compilers>
  8987. Summary: Added a crude mmap() for those systems that don't have it.
  8988. Keywords: tools, comment
  8989. Sender: compilers-sender@iecc.cambridge.ma.us
  8990. Organization: Cornell Univ. CS Dept, Ithaca NY 14853
  8991. References: <93-04-042@comp.compilers>
  8992. Date: Wed, 14 Apr 1993 20:55:56 GMT
  8993. Approved: compilers@iecc.cambridge.ma.us
  8994.  
  8995. I've added a crude mmap() for those systems that don't have it.  It works
  8996. by new'ing the necessary space, and then reading the file into it.  So,
  8997. EOF will not match (OUCH!!!). I'll try and work out something better when
  8998. I have the time.
  8999.  
  9000. As usual, its available for anon ftp as pub/Parser.shar from
  9001. ftp.cs.cornell.edu :)
  9002. Mayan
  9003. [Sounds to me like you forgot to set _end, the pointer to the end of the file
  9004. buffer. -John]
  9005. -- 
  9006. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9007. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9008.  
  9009.  
  9010. From compilers Wed Apr 14 19:20:53 EDT 1993
  9011. Newsgroups: comp.compilers
  9012. Path: iecc!compilers-sender
  9013. From: cliffc@rice.edu (Cliff Click)
  9014. Subject: Re: request C code which translates source into PDG
  9015. Message-ID: <93-04-054@comp.compilers>
  9016. Keywords: tools, analysis, optimize
  9017. Sender: compilers-sender@iecc.cambridge.ma.us
  9018. Organization: Center for Research on Parallel Computations
  9019. References: <93-04-047@comp.compilers>
  9020. Date: Wed, 14 Apr 1993 23:02:47 GMT
  9021. Approved: compilers@iecc.cambridge.ma.us
  9022.  
  9023. wjackson@pinnacle.cerc.wvu.edu writes:
  9024. > Has anyone implemented algorithms which convert a source program into a
  9025. > Program Dependence Graph?  We are currently working to implement such
  9026. > algorithms as outlined in the 1987 paper "The Program Dependence Graph and
  9027. > Its Use in Optimization" by Ferrante, Ottenstein, and Warren.
  9028.  
  9029. I've implemented conversion of a low-level 3-address intermediate
  9030. representation to something similar to a PDG.  I do analysis and
  9031. optimizations on this form, then produce something close to assembly out.
  9032.  
  9033. Paul Havlok (paco@cs.rice.edu) has implemented conversion of Fortran
  9034. (really an AST of the Fortran program) to something similar to a PDG.
  9035. Paul does analysis and optimizations, then outputs readable Fortran.
  9036.  
  9037. Our forms are more like each other than they are like a PDG.  We both have
  9038. fewer restrictions on the scheduling of computations than the PDG does,
  9039. and use this freedom to do better analysis.
  9040.  
  9041. Because of our different purposes the kinds and extents of our analyses
  9042. differ, but the basic graph formats are very similar.  We both found this
  9043. kind of IR is very easy to analyze and optimize.
  9044.  
  9045. I can send you C++ code for what I do, but its probably less useful than a
  9046. careful description of how you would go about doing it.
  9047.  
  9048. Cliff
  9049. --
  9050. cliffc@cs.rice.edu
  9051. Massively Scalar Compiler Group
  9052. -- 
  9053. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9054. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9055.  
  9056.  
  9057. From compilers Thu Apr 15 00:04:28 EDT 1993
  9058. Newsgroups: comp.compilers
  9059. Path: iecc!compilers-sender
  9060. From: paco@legia.cs.rice.edu (Paul Havlak)
  9061. Subject: Re: request C code which translates source into PDG
  9062. Message-ID: <93-04-055@comp.compilers>
  9063. Keywords: tools, analysis, optimize
  9064. Sender: compilers-sender@iecc.cambridge.ma.us
  9065. Organization: Rice University
  9066. References: <93-04-047@comp.compilers> <93-04-054@comp.compilers>
  9067. Date: Thu, 15 Apr 1993 02:49:05 GMT
  9068. Approved: compilers@iecc.cambridge.ma.us
  9069.  
  9070. I have code inside the ParaScope programming environment for parallel
  9071. Fortran that builds any or all of the following from a Fortran AST:
  9072.  
  9073.     * Control flow graph
  9074.  
  9075.         * with pre- and post-dominator trees
  9076.  
  9077.         * with Tarjan interval tree (nested loops)
  9078.  
  9079.     * Unfactored control dependence graph (no region nodes)
  9080.  
  9081.         * edge labels according to corresponding branch values
  9082.  
  9083.         * edge levels according to carrying loop
  9084.  
  9085.     * Static Single-Assignment form with def-use chains
  9086.  
  9087.         * with or without arrays modeled as scalars
  9088.  
  9089.         * interprocedural variables modeled separately or as
  9090.             one glob
  9091.  
  9092.         * with or without def-def chains (output dependences)
  9093.  
  9094.         * optionally converted to Gated Single-Assignment form
  9095.             (a variant on the version in Ballance et al.,
  9096.             SIGPLAN 90)
  9097.  
  9098.     * Hashed value numbers based on SSA or GSA form
  9099.  
  9100.     There are several complete or nearly-complete program
  9101. representations in ParaScope:
  9102.  
  9103.     * Control dependence graph and SSA form
  9104.  
  9105.     * Control dependence graph and data dependence graph
  9106.         (like a PDG, although the data dependence computation
  9107.         still has technical limitations)
  9108.  
  9109.     * Gated Single-Assignment form
  9110.  
  9111.     Many more features to come, perhaps even documentation :-).  Of my
  9112. code, only the value numbering is in C++ and relatively abstract; the
  9113. rest is in C with more details about our AST implementation than I
  9114. would put in today.
  9115.     All this is a very small part of the ParaScope infrastructure.
  9116. ParaScope source is available for a relatively small fee -- for
  9117. details send mail to softlib@cs.rice.edu (works like netlib) with the
  9118. line:
  9119.  
  9120. send catalog
  9121.  
  9122. -- and another with the line:
  9123.  
  9124. send license
  9125.  
  9126. Regards,
  9127. Paul
  9128. --
  9129. Paul Havlak            Dept. of Computer Science
  9130. Graduate Student        Rice University, Houston TX 77251-1892
  9131. PFC/ParaScope projects        (713) 527-8101 x2738     paco@cs.rice.edu
  9132. -- 
  9133. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9134. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9135.  
  9136.  
  9137. From compilers Thu Apr 15 09:59:32 EDT 1993
  9138. Newsgroups: comp.compilers
  9139. Path: iecc!compilers-sender
  9140. From: xorian@solomon.technet.sg (Xorian Technologies)
  9141. Subject: Semantic actions in LR parser
  9142. Message-ID: <93-04-056@comp.compilers>
  9143. Keywords: parse, LR(1)
  9144. Sender: compilers-sender@iecc.cambridge.ma.us
  9145. Organization: Compilers Central
  9146. References: <93-04-008@comp.compilers> <93-04-010@comp.compilers>
  9147. Date: Thu, 15 Apr 1993 09:35:59 GMT
  9148. Approved: compilers@iecc.cambridge.ma.us
  9149.  
  9150. roy@prism.gatech.edu (Roy Mongiovi) writes:
  9151. >LR parsers can only perform semantic actions when the recognize a handle
  9152. >(right-hand side).  You can either split up the right-hand sides into
  9153. >pieces so that the pieces end where you need the semantic actions, or you
  9154. >can stick in epsilon productions whose only purpose is to cause semantic
  9155. >actions.
  9156.  
  9157. karsten@tfl.dk (Karsten Nyblad) writes:
  9158. >Even that can be generalized.  All items of the kernel of a state has the
  9159. >same symbol before the . of the item, where the . denotes the point until
  9160. >which the parser has accepted the symbols of the production of the item.
  9161. >If the same action has been specified on all productions of the items of
  9162. >the kernel of a state on pushing the symbol before the ., then that action
  9163. >can executed by the parser.
  9164.  
  9165. The principal problem with the above analysis is that it does not address
  9166. the grammar from the point of view of the language developer.  In
  9167. particular, language developers would prefer not to think in terms of
  9168. states and items much less their manipulation.
  9169.  
  9170. Fortunately, in practice, the problem is usually not nearly so arbitrary
  9171. as the above discussion would imply (though, certianly in theory, it can
  9172. be). In fact, the problems associated with intermediate parser actions
  9173. (namely reduce-reduce conflicts) are more often than not *introduced* by
  9174. the traditional grammar formalism.
  9175.  
  9176. As I am certain Chris Clark is aware, there is a more natural approach to
  9177. grammar specification which better allows for intermediate actions in
  9178. productions: regular expressions. By regular expressions, though, I don't
  9179. just mean a preprocessor which converts regular expression grammars into
  9180. fixed expression grammars. That is what causes the problems in the first
  9181. place. Instead, to work, the regular expression must be taken right down
  9182. into the parser engine.
  9183.  
  9184. The result of using regular expressions to specify grammars is that
  9185. seemingly different productions are coallessed into a single production.
  9186. The implication is obvious: fewer items and, therefore, less chance of
  9187. conflicts associated with intermediate actions. Of course, this requires
  9188. that a single action be specified for the new single production but that
  9189. was already a requirement as previously discussed. In practice, even naive
  9190. users tend to write regular expression grammars that avoid the
  9191. redundencies (and intermediate reductions) of fixed expression grammars
  9192. and are therefore more suitable for intermediate actions and the
  9193. availability of regular expressions provide a more natural mechanism for
  9194. the resolution of conflicts that might arise.
  9195.  
  9196. The essential problem is that an intermediate action, no matter how it is
  9197. implemented, introduces a requirement for the parser to decide what
  9198. production it is working on. This is inherently contrary to the nature of
  9199. LR parsing which seeks to defer the decision until reduction.  Regular
  9200. expression grammars avoid this delimna by eliminating many shift-reduce
  9201. choices by converting them into paths in the regular expression.
  9202.  
  9203. To see just how far this can be taken, consider your favorite grammar.
  9204. Rewrite (top to bottom or vice versa) by making macro substitutions by
  9205. hand to bring productions together. The only circumstance where
  9206. productions cannot be so merged is when a nonterminal is used more than
  9207. once in a nontrivial construct. For example, most of the productions of a
  9208. ANSI C expression can be brought together into a single regular expression
  9209. of nested repetitions. Similarly, much of the complexity of declarations
  9210. can be removed.
  9211.  
  9212. None of this, of course, is new in theory but there are few production
  9213. quality compiler-compilers which support regular expressions. One such
  9214. product is LADE which not only allows regular expressions but provides
  9215. considerable semantic support for them so that you don't have to pick
  9216. through the parse stack trying to figure out, for example, whether or not
  9217. an optional construct occured.
  9218.  
  9219. I strongly recommend that anyone interested in the issue of attaching
  9220. intermediate actions to productions look into regular expression grammars
  9221. and their facility for supporting, at the user level, what is needed at
  9222. the machine level.
  9223.  
  9224. (For more information on LADE, email: xorian@solomon.technet.sg or fax:
  9225. (65)253-7709.)
  9226. -- 
  9227. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9228. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9229.  
  9230.  
  9231. From compilers Fri Apr 16 12:10:32 EDT 1993
  9232. Newsgroups: comp.compilers
  9233. Path: iecc!compilers-sender
  9234. From: ghiya@sally.cs.mcgill.ca (Rakesh Ghiya )
  9235. Subject: Reference formals in Pascal.
  9236. Message-ID: <93-04-057@comp.compilers>
  9237. Keywords: Pascal, question, comment
  9238. Sender: compilers-sender@iecc.cambridge.ma.us
  9239. Organization: Compilers Central
  9240. Date: Thu, 15 Apr 1993 17:13:17 GMT
  9241. Approved: compilers@iecc.cambridge.ma.us
  9242.  
  9243. Hi all,
  9244.  
  9245. I wanted to know, how exactly the reference formals are implemented in
  9246. Pascal compilers : is the reference formal allocated space on the stack
  9247. which contains the address of the corresponding actual parameter, with
  9248. every access to the formal parameter being directed to the actual
  9249. parameter using this address (like dereferencing in C ); or is it
  9250. implemented in some other way ?
  9251.  
  9252. I would appreciate any feedback I receive on this.
  9253.  
  9254. Thanks a bunch,
  9255. Rakesh.
  9256.  
  9257. ghiya@cs.mcgill.ca
  9258. [I'm not aware of any other implementation with the required semantics.
  9259. Fortran arguments can be either reference or copy-in/copy-out, but Pascal
  9260. is not so forgiving. -John]
  9261. -- 
  9262. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9263. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9264.  
  9265.  
  9266. From compilers Fri Apr 16 12:11:48 EDT 1993
  9267. Newsgroups: comp.compilers
  9268. Path: iecc!compilers-sender
  9269. From: jimy@cae.wisc.edu
  9270. Subject: IR Transformations
  9271. Message-ID: <93-04-058@comp.compilers>
  9272. Keywords: optimize, question
  9273. Sender: compilers-sender@iecc.cambridge.ma.us
  9274. Organization: Compilers Central
  9275. Date: Thu, 15 Apr 1993 17:42:49 GMT
  9276. Approved: compilers@iecc.cambridge.ma.us
  9277.  
  9278. Could anyone give me pointers to papers on the subject of IR
  9279. transformations to suit code generation?
  9280.  
  9281. More specificaly, suppose we want to generate code for x = 2 * a; The
  9282. problem is how to know, at the IR level (before code is generated), that
  9283. the above expression can be rewritten as x = a + a (assuming + is cheaper
  9284. than *).  The problem is that the above transformation may be context
  9285. dependent and not always desirable.  In other words, sometimes 2*a may be
  9286. covered cheaper than a+a, e.g.  by a shift left, which some processors
  9287. accomplish for free, bundled in a previous instruction.
  9288.  
  9289. Thanks for any help
  9290.  
  9291. Jim Yu
  9292. jimy@eckert.ece.wisc.edu
  9293. -- 
  9294. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9295. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9296.  
  9297.  
  9298. From compilers Fri Apr 16 12:16:39 EDT 1993
  9299. Xref: iecc comp.arch:27986 comp.parallel:5740 comp.compilers:4517
  9300. Newsgroups: comp.arch,comp.parallel,comp.compilers
  9301. Path: iecc!compilers-sender
  9302. From: stamos@bert.eecs.uic.edu (Jerry Stamatopoulos)
  9303. Subject: ISCA Workshop on Coordination - Prelim. Program and Regist. Material
  9304. Message-ID: <93-04-059@comp.compilers>
  9305. Keywords: conference, parallel
  9306. Sender: compilers-sender@iecc.cambridge.ma.us
  9307. Organization: University of Illinois at Chicago
  9308. Date: Fri, 16 Apr 1993 01:42:08 GMT
  9309. Approved: compilers@iecc.cambridge.ma.us
  9310.  
  9311.  
  9312.         Workshop on Fine-Grain Massively Parallel Coordination
  9313.                 Intl. Symp. on Computer Architecture
  9314.                         San Diego, California
  9315.                            May 15, 1993
  9316.  
  9317. ORGANIZERS:
  9318. ===========
  9319.         Jon A. Solworth (Chair), University of Illinois at Chicago
  9320.         Andrew Chien, University of Illinois at Urbana-Champaign
  9321.         Gary Koob, Office of Naval Research
  9322.  
  9323.  
  9324. LOCAL ARRANGEMENTS
  9325. ==================
  9326.         Jerry Stamatopoulos, isca-ws@parsys.eecs.uic.edu
  9327.  
  9328.  
  9329. PRELIMINARY PROGRAM
  9330. ===================
  9331.  
  9332.  9:00 -  9:15   Opening remarks
  9333.  
  9334.  9:15 -  9:45   "Long-lived Communication Management for iWarp"
  9335.                 Susan Hinrichs (CMU)
  9336.  
  9337.  9:45 - 10:00   "Raising the Level of Abstraction of the Distributed Memory
  9338.                 Paradigm: The Abstract Topology Model"
  9339.                 W.K. Giloi and A. Schramm (Technical Univ. of Berlin)
  9340.  
  9341. 10:00 - 10:15   "Cache Coherent Atomic Synchronization Primitives"
  9342.                 David V. James (Apple Computer)
  9343.  
  9344. 10:15 - 10:30   "Compile-time Analysis to Implement Point-to-point
  9345.                 Synchronization in Parallel Programs"
  9346.                 John Nguyen (MIT)
  9347.  
  9348. 10:30 - 11:00   Break
  9349.  
  9350. 11:00 - 11:30   "Using Barrier Synchronization To Support Massive Fine-Grain
  9351.                 Parallelism Across Conventional Microprocessors"
  9352.                 H.G. Dietz, S. Ramakrishnan, D.G. Meyer, W.E. Cohen,
  9353.                 T.J. Parr, J.B. Sponaugle, R.W. Quong, A.K. Srikanth,
  9354.                 T.M. Chung, G. Krishnamurthy, C. Liou, et al. (Purdue Univ.)
  9355.  
  9356. 11:30 - 11:45   "Do&Merge and its Implementation"
  9357.                 James M. Stichnoth (CMU)
  9358.  
  9359. 11:45 - 12:00   "Smoke: A Parallel Processor Array with Multiple Communication
  9360.                 and Control Modes"
  9361.                 Abhaya Asthana and Boyd T. Mathews (AT&T Bell Labs)
  9362.  
  9363. 12:00 - 12:30   "Optimal Phase Barrier Synchronization in k-ary n-cube
  9364.                 Wormhole-routed Systems using Multirendezvous Primitives"
  9365.                 Dhabaleswar K. Panda (Ohio-State Univ.)
  9366.  
  9367. 12:30 -  2:00   Lunch
  9368.  
  9369.  2:00 -  2:30   "How To Port Sequential Programs to Fine-Grain Machines"
  9370.                 William J. Dally (MIT)
  9371. ^L
  9372.  
  9373.  
  9374.  2:30 -  2:45   "Network-based Coordination of Asynchronously Executing
  9375.                 Processes with Caches"
  9376.                 Craig Williams and Paul Reynolds, Jr. (Univ. of Virginia)
  9377.  
  9378.  2:45 -  3:00   "Dynamic and Static Scheduling of Integrated Network
  9379.                 Barriers (INB's)"
  9380.                 Jon A. Solworth and Jerry Stamatopoulos (Univ. of Illinois)
  9381.  
  9382.  3:00 -  3:30   "On Designing Processor-Network Interface for Fine-Grained
  9383.                 Distributed-Memory Multicomputers"
  9384.                 Yunn-Yen Chen and Chung-Ta King (National Tsing Hua Univ.)
  9385.  
  9386.  3:30 -  4:00   Break
  9387.  
  9388.  4:00 -  4:30   "Workload Characterization for Thread Placement on Multi-
  9389.                 threaded Architectures"
  9390.                 Radhika Thekkath and Susan J. Eggers (Univ. of Washington)
  9391.  
  9392.  4:30 -  4:45   "Justifying Cache Memories for Data Flow Architectures"
  9393.                 Ponnarasu Shanmugam, Shirish Andhare, and Krishna M. Kavi (UTA)
  9394.  
  9395.  4:45 -  5:30   Future Issues in Coordination
  9396. ^L
  9397.  
  9398.                             ISCA'93 WORKSHOPS
  9399.  
  9400.                    Sheraton Harbor Island, San Diego, CA
  9401.                               May 14-15, 1993
  9402.  
  9403. Workshop 2 (Sat only): Fine-Grain Massively Parallel Coordination
  9404.  
  9405.         Jon A. Solworth (Chair), University of Illinois at Chicago
  9406.         Andrew Chien, University of Illinois at Urbana-Champaign
  9407.         Gary Koob, Office of Naval Research
  9408.  
  9409.  
  9410.                         WORKSHOPS REGISTRATION FORM
  9411.                         ---------------------------
  9412.  
  9413.  
  9414.  First Name ___________________ Last Name _______________________ Title ___
  9415.  
  9416.  Company/Institution ______________________________________________________
  9417.  
  9418.  Address ___________________________________________________________________
  9419.  
  9420.  City ________________________________ State ____________ Zip _____________
  9421.  
  9422.  Country _____________________________ Telephone __________________________
  9423.  
  9424.  E-mail ___________________________________________________________________
  9425.  
  9426.  Badge Name _______________________________________________________________
  9427.  
  9428.  
  9429.  Fees                  Prior to April 26          After April 26
  9430.                        Member  Nonmember         Member  Nonmember
  9431.                        -----------------         -----------------
  9432.  
  9433.  Workshop 2 (1 day)     100       100             120       120
  9434.  
  9435.  
  9436.  
  9437.  Workshop number  ________
  9438.  
  9439.  TOTAL FEE ENCLOSED (US$) ________________
  9440.  
  9441.  
  9442.  Make checks payable to ACM ISCA WORKSHOPS (credit card payments are
  9443.  not acceptable for workshops) and forward with completed
  9444.  registration form to:
  9445.  
  9446.                  ACM ISCA WORKSHOPS
  9447.                  c/o Pat Harris
  9448.                  Department of Information
  9449.                   and Computer Science
  9450.                  University of California
  9451.                  Irvine, CA 92717
  9452.                  USA
  9453.                  e-mail: harris@ics.uci.edu
  9454.  
  9455.  
  9456. Early registration discounts are extended to forms received by April 26,
  9457. 1993.  ACM or IEEE-CS members must include membership number to receive
  9458. member discount.  Cancellations must be made in writing and received by
  9459. May 1, 1993. Workshops may be cancelled due to lack of registration.  The
  9460. fee includes coffee breaks, lunches, and reception.
  9461. -- 
  9462. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9463. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9464.  
  9465.  
  9466. From compilers Fri Apr 16 12:18:07 EDT 1993
  9467. Newsgroups: comp.compilers
  9468. Path: iecc!compilers-sender
  9469. From: krishna@cs.unm.edu (Ksheerabdhi Krishna)
  9470. Subject: Re: request C code which translates source into PDG
  9471. Message-ID: <93-04-060@comp.compilers>
  9472. Keywords: optimize, analysis
  9473. Sender: compilers-sender@iecc.cambridge.ma.us
  9474. Organization: Computer Science Department, University of New Mexico
  9475. References: <93-04-047@comp.compilers>
  9476. Distribution: usa
  9477. Date: Thu, 15 Apr 1993 19:32:30 GMT
  9478. Approved: compilers@iecc.cambridge.ma.us
  9479.  
  9480. > Has anyone implemented algorithms which convert a source program into a
  9481. > Program Dependence Graph?
  9482.  
  9483. Karl and Steven Ellcey did implement this, the implementation is described
  9484. in a paper by both of them in "Software Practice and Experience"
  9485.  
  9486. Experience Compiling Fortran to Program Dependence Graphs
  9487. by Karl Ottenstein and Steven Ellcey, vol22(1), 41-62, Jan 1992.
  9488.  
  9489. > If anyone else has done this or another implementation and has code
  9490. > available, we would appreciate the information.
  9491.  
  9492. They did their implemantation in Modula-2, but in Sun's Modula-2
  9493. (different libraries) and to the best of my knowledge Sun has discontinued
  9494. a Modula-2 line, at least last time I checked.
  9495.  
  9496. -begin-plug-
  9497. I am working on an implemenation (restricted C -> PDW) right now, which
  9498. should be available sometime later this year.
  9499. -end-plug-
  9500.  
  9501. Cheers,
  9502. -- 
  9503. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9504. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9505.  
  9506.  
  9507. From compilers Fri Apr 16 12:19:16 EDT 1993
  9508. Newsgroups: comp.compilers
  9509. Path: iecc!compilers-sender
  9510. From: roger@ac.upc.es
  9511. Subject: dependence graphs for vector machines
  9512. Message-ID: <93-04-061@comp.compilers>
  9513. Keywords: optimize, vector, question
  9514. Sender: compilers-sender@iecc.cambridge.ma.us
  9515. Organization: Compilers Central
  9516. Date: Fri, 16 Apr 1993 17:18:52 GMT
  9517. Approved: compilers@iecc.cambridge.ma.us
  9518.  
  9519. We are two PhD students working on instruction scheduling for vector
  9520. processors.  We would like to test different register allocators and
  9521. instruction scheduling algorithms on a set of FORTRAN vectorizable loops.
  9522.                               ^^^^^^^^^^^^
  9523.  
  9524. In order to do that we need to have the (low-level) dependence graph of each
  9525. loop, something like:
  9526.  
  9527.        VLD     VLD   VLD     VLD
  9528.     \    /    \    /
  9529.      \     /     \     /
  9530.       \   /          \   /
  9531.        VADD            VADD
  9532.          \             /
  9533.           \           /
  9534.            \         /
  9535.         \       /
  9536.          \     /
  9537.           \   /
  9538.            VMUL
  9539.             |
  9540.             |
  9541.            VST
  9542.  
  9543. Our problem is how to obtain these graphs from the Fortran loops. We are
  9544. thininkg on the following solutions:
  9545.  
  9546.  1) Compile the loops with a real vectorizing compiler ( the Convex one in
  9547.     our case) and get the assembler produced. Eliminate all the scalar code
  9548.     from the assembler and keep only the vector part. Write a little program
  9549.     that constructs the dependence graph from that ( renaming registers to
  9550.     eliminate artificial dependencies ).
  9551.     Problems with this approach:
  9552.      - Difficult to handle memory aliases (i.e.  is VLD 300(a3),r1
  9553.      dependent on VLD 500(a3),r2 or not ? )
  9554.      - The graph produced is? (terribly?) biased by the compiler used
  9555.  
  9556.  2) Given that we are interested in loops, and usually the body of a loop is
  9557.     "simple" (mainly expressions and assignment), write a tiny compiler
  9558.     that parses the loops and generates the graph.
  9559.     Problems with this approach:
  9560.      - We won't be able to perform all the usual optimizations that a
  9561.      compiler does (cse, strength reduction ...) so we'll probably end up
  9562.      with a graph not very representative of real programs
  9563.  
  9564.  3) Is there any tool that does what we want ?
  9565.  4) Does the latest GNU gcc version (2.3.3?)  vectorize for the convex ?
  9566.  4) Is there source code for a vectorizing compiler freely available ?
  9567.  5) Any other suggestions ?
  9568.  
  9569.  Thanks,
  9570.  
  9571.     Roger Espasa
  9572.     e-mail: roger@ac.upc.es
  9573.  
  9574.     Marta Jimenez
  9575.     e-mail: marta@ac.upc.es
  9576. -- 
  9577. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9578. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9579.  
  9580.  
  9581. From compilers Fri Apr 16 12:19:53 EDT 1993
  9582. Newsgroups: comp.compilers
  9583. Path: iecc!compilers-sender
  9584. From: tbr@tfic.bc.ca (Tom Rushworth )
  9585. Subject: LALR(k) lookahead set algorithms
  9586. Message-ID: <93-04-062@comp.compilers>
  9587. Keywords: LALR, bibliography
  9588. Sender: compilers-sender@iecc.cambridge.ma.us
  9589. Organization: Compilers Central
  9590. Date: Fri, 16 Apr 1993 03:40:00 GMT
  9591. Approved: compilers@iecc.cambridge.ma.us
  9592.  
  9593. There was a series of papers several years back in TOPLAS and SIGPLAN Notices
  9594. about improved algorithms for LALR(1) lookahead set generation:
  9595.  
  9596.  1982 October - TOPLAS vol 4 # 4,
  9597.      "Efficient Computation of LALR(1) Look-Ahead Sets",
  9598.      DeRemer and Pennello
  9599.  
  9600.  1985 January - TOPLAS vol 7 # 1,
  9601.      "A New Analysis of LALR Formalisms",
  9602.      Park, Choe and Chang
  9603.  
  9604.  1986 July - SIGPLAN Notices vol 21 # 7, (Proceedings of the SIGPLAN'86
  9605.      Symposium on Compiler Construction)
  9606.      "Unifying View of recent LALR(1) Lookahead Set Algorithms"
  9607.      Ives
  9608.  
  9609.  1987 April - SIGPLAN Notices vol 22 # 4,
  9610.      "Remarks on Recent Algorithms for LALR Lookahead Sets"
  9611.      Park and Choe
  9612.  
  9613.  1987 August - SIGPLAN Notices vol 22 # 8,
  9614.      "Response to Remarks on Recent Algorithms for LALR Lookahead Sets"
  9615.      Ives
  9616.  
  9617. I implemented the original DeRemer and Pennello algorithm, but I'm rusty
  9618. enough on the subject that I found the later papers heavy going.  Does
  9619. anyone know if Fred Ives published a more detailed paper later?  The
  9620. August'87 paper mentions a paper submitted to TOPLAS, but if it was
  9621. accepted, I've missed it.
  9622.  
  9623. The point of all this is that I'm thinking of implementing either the
  9624. Park, Choe and Chang algorithm or the Ives algorithm, and I want as clear
  9625. an explanation as I can get.  Any pointers or suggestions will be
  9626. appreciated!
  9627. ----
  9628. Tom Rushworth (604) 733-0731 [FAX: 733-0634]  e-mail: tbr@tfic.bc.ca  {VE7TBR}
  9629.                Timberline Forest Inventory Consultants
  9630. -- 
  9631. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9632. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9633.  
  9634.  
  9635. From compilers Fri Apr 16 16:56:33 EDT 1993
  9636. Newsgroups: comp.compilers
  9637. Path: iecc!compilers-sender
  9638. From: goer@midway.uchicago.edu (Richard L. Goerwitz)
  9639. Subject: FIRST() algorithm
  9640. Message-ID: <93-04-063@comp.compilers>
  9641. Keywords: LR(1), question
  9642. Sender: compilers-sender@iecc.cambridge.ma.us
  9643. Reply-To: goer@midway.uchicago.edu
  9644. Organization: University of Chicago
  9645. Date: Fri, 16 Apr 1993 16:16:37 GMT
  9646. Approved: compilers@iecc.cambridge.ma.us
  9647.  
  9648. Perhaps this is not a puzzle for old hands.  For me, though, it's
  9649. a real conundrum.  Where is the breakdown in the following sequence?
  9650.  
  9651.     1) LR-family parser generators associate actions with reductions
  9652.     2) To calculate when a reduction must take place, one uses (among
  9653.        other things) the FIRST() algorithm we all know and love
  9654.     3) FIRST() does not work with left recursive rules, so we must
  9655.        first convert left recursion to right recursion
  9656.     4) The only left recursion -> right recursion algorithms I know
  9657.        are only guaranteed to work on grammars without epsilon moves
  9658.     5) To remove epsilon moves from a grammar that specifies actions
  9659.        for epsilon moves will alter the action-reduction assocations in
  9660.        an unacceptable way
  9661.     6) hence I can't do step 1 except for grammars that don't specify
  9662.        actions for epsilon moves (and, by implication, for grammars that
  9663.        have left recursion, since conversion to right recursion intro-
  9664.        duces new nonterminals and action->epsilon-move associations).
  9665.  
  9666. Where's the weak link in my reasoning?
  9667. --
  9668.    -Richard L. Goerwitz              goer%midway@uchicago.bitnet
  9669.    goer@midway.uchicago.edu          rutgers!oddjob!ellis!goer
  9670. -- 
  9671. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9672. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9673.  
  9674.  
  9675. From compilers Sun Apr 18 20:10:19 EDT 1993
  9676. Xref: iecc comp.compilers:4522 misc.jobs.offered:27038
  9677. Newsgroups: comp.compilers,misc.jobs.offered
  9678. Path: iecc!compilers-sender
  9679. From: compilers-jobs@iecc.cambridge.ma.us
  9680. Subject: Compiler positions available for week ending April 18
  9681. Message-ID: <93-04-064@comp.compilers>
  9682. Keywords: jobs
  9683. Sender: compilers-sender@iecc.cambridge.ma.us
  9684. Organization: Compilers Central
  9685. Date: Sun, 18 Apr 1993 12:00:03 GMT
  9686. Approved: compilers@iecc.cambridge.ma.us
  9687.  
  9688. This is a digest of ``help wanted'' and ``position available'' messages
  9689. received at comp.compilers during the preceding week.  Messages must
  9690. advertise a position having something to do with compilers and must also
  9691. conform to the guidelines periodically posted in misc.jobs.offered.
  9692. Positions that remain open may be re-advertised once a month.  To respond
  9693. to a job offer, send mail to the author of the message.  To submit a
  9694. message, mail it to compilers@iecc.cambridge.ma.us.
  9695.  
  9696.  
  9697. -------------------------------
  9698.  
  9699. Subject: Position Available, C++, Pittsburgh, PA.
  9700. Date: Fri, 16 Apr 93 16:36:07 -0400
  9701. From: Sam Harbison <harbison@tartan.com>
  9702.  
  9703. SENIOR MEMBER, TECHNICAL STAFF-- C++; Debuggers; Pittsburgh, PA.
  9704.  
  9705. This is a software engineering and programing job in a new group
  9706. developing a C++ programming environment for embedded systems. The job
  9707. involve individual technical contributions and work in groups.
  9708.  
  9709. The successful applicant is expected to be--or quickly become--thoroughly
  9710. familiar with all aspects of the C++ language, and will be the group's
  9711. primary resource on C++. He or she will assume overall responsibility for
  9712. designing, developing, and/or modifying a proprietary embedded-systems
  9713. symbolic debugger to work with C++, by designing and implementing a C++
  9714. subset interpreter in the debugger. Subsequently, the applicant will
  9715. assume other tasks involving C++ technical leadership in the project.
  9716.  
  9717. Requirements: M.S. or Ph.D. in computer science; 4 years or more
  9718. experience in programming languages and their implementations. Thorough
  9719. knowledge of C++, and excellent software engineering skills.  Some
  9720. exposure to embedded systems.  Ability to work well individually and in a
  9721. group. Project management experience is a plus.
  9722.  
  9723. If interested, send your resume to:
  9724.     Personnel Dept.
  9725.     Tartan, Inc.
  9726.     300 Oxford Drive
  9727.     Monroeville, PA 15146
  9728.     (412) 856-3600
  9729.     --or email to harbison@tartan.com
  9730.  
  9731. Expect no response until the end of April, due to travel schedules.
  9732. -- 
  9733. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9734. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9735.  
  9736.  
  9737. From compilers Sun Apr 18 20:11:00 EDT 1993
  9738. Newsgroups: comp.compilers
  9739. Path: iecc!compilers-sender
  9740. From: mauney@csljon.csl.ncsu.edu (Jon Mauney)
  9741. Subject: Re: FIRST() algorithm
  9742. Message-ID: <93-04-065@comp.compilers>
  9743. Keywords: LR(1)
  9744. Sender: compilers-sender@iecc.cambridge.ma.us
  9745. Organization: NCSU
  9746. References: <93-04-063@comp.compilers>
  9747. Date: Sun, 18 Apr 1993 20:50:11 GMT
  9748. Approved: compilers@iecc.cambridge.ma.us
  9749.  
  9750. goer@midway.uchicago.edu (Richard L. Goerwitz) writes:
  9751.  
  9752. >Perhaps this is not a puzzle for old hands.  For me, though, it's
  9753. >a real conundrum.  Where is the breakdown in the following sequence?
  9754.  
  9755. >    3) FIRST() does not work with left recursive rules, so we must
  9756. >       first convert left recursion to right recursion
  9757.  
  9758. >Where's the weak link in my reasoning?
  9759.  
  9760. First works fine with left-recursion.  First is a set of terminals, and
  9761. therefore of finite size; it is easily calculated with an iterative
  9762. algorithm.
  9763.  
  9764. You are probably thinking of the LL-family use of First to build the
  9765. Predict() function, which does have trouble with left-recursion.
  9766.  
  9767. --
  9768. Jon Mauney                   mauney@csc.ncsu.edu
  9769. Mauney Computer Consulting   (919)828-8053
  9770. -- 
  9771. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9772. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9773.  
  9774.  
  9775. From compilers Mon Apr 19 10:20:12 EDT 1993
  9776. Newsgroups: comp.compilers
  9777. Path: iecc!compilers-sender
  9778. From: xorian@solomon.technet.sg (Xorian Technologies)
  9779. Subject: Semantic predicates into grammar specifications
  9780. Message-ID: <93-04-066@comp.compilers>
  9781. Keywords: parse, tools
  9782. Sender: compilers-sender@iecc.cambridge.ma.us
  9783. Organization: Compilers Central
  9784. References: <93-04-044@comp.compilers>
  9785. Date: Mon, 19 Apr 1993 01:17:31 GMT
  9786. Approved: compilers@iecc.cambridge.ma.us
  9787.  
  9788. parrt@ecn.purdue.edu (Terence J Parr) writes:
  9789. >I'm very pleased by the posting of Mayan Moudgill
  9790. ><moudgill@cs.cornell.EDU>; people are beginning to see that semantic
  9791. >predicates are the way to recognize context-sensitive constructs rather
  9792. >than having the lexer change the token type (ack!).
  9793. >
  9794. >We call this a *validation* semantic predicate (we have syntactic
  9795. >predicates in the next release of PCCTS).  Predicates can also be used to
  9796. >distinguish between two syntactically ambiguous productions
  9797. >(*disambiguating* semantic predicates).
  9798.  
  9799. Terence only begins to scratch the surface of what can be accomplished by
  9800. the introduction of semantic predicates into grammar specifications. His
  9801. examples concentrated on the lookahead (looking up the next symbol in the
  9802. symbol tables) but this is by far the least interesting use of semantic
  9803. predicates.
  9804.  
  9805. Semantic predicates, as defined in LADE, allow you to attach arbitrary
  9806. computations to any production: the production will only be reduced if the
  9807. predicate returns true. The predicates have access not only to the
  9808. lookahead symbol(s), but to the entire state of lexical, syntactic and
  9809. semantic analysis.
  9810.  
  9811. Here are two examples of what can be achieved:
  9812.  
  9813. The predicate has access to, for example, the synthesized attributes of
  9814. the production symbols. You might, for example, restrict a particular
  9815. production to only allow expressions of a particular type or type
  9816. expressions which indicate a class. This is of particular importance in
  9817. sugh languages as C++ where type expression equivalence is not name based.
  9818.  
  9819. In C++, there are many pathological ambiguities which are unresolvable for
  9820. lr(k) or ll(k) for any k. They require, instead, an unbounded lookahead.
  9821. This can be accomplished by predicating the reduction of a production on a
  9822. successful recursive parsing of the forward stream.  In essence, the
  9823. current parse is suspended and a secondary, simplified, parse is
  9824. initiated. If the forward parse succeeds, then the production is reduced
  9825. and the primary parsing proceeds as usual from the original point.  If the
  9826. forward parse fails, another alternative is considered.
  9827.  
  9828. As a general rule, though, you should only use predicates for the purpose
  9829. of disambiguation; if there is no alternative syntactic interpretation of
  9830. a string, let the error handling fall to the semantic analysis. But where
  9831. syntactic ambiguities occur, whether shift-reduce or reduce-reduce,
  9832. semantic predicates are a powerful tool for their resolution and certainly
  9833. a much cleaner and simpler approach than hacking the lexer.
  9834.  
  9835. A more interesting questions arises wich respect to language design:
  9836. should languages be intionally designed to take advantage of semantic
  9837. predicates? A purist might be inclined to answer no, but consider that the
  9838. typical programmer does not look at a program and see only the syntactic
  9839. information; he does not look at it with PDA-eyes. Instead, he not only
  9840. sees the semantic information that has passed before but also that which
  9841. lies ahead. (My favorite example is the function call/arrary reference
  9842. ambiguity in Ada. No rational Ada programmer would see it as an ambiguity
  9843. for he would have to practice extreme myopia to fail to notice that the
  9844. declarations that preceeded their use.) If anything, semantic predicates
  9845. allow for more natural languages to be defined, languages which are not so
  9846. syntactically contrived. That, I think, is the best argument for a closer
  9847. look at semantic predicates in grammar specifications.
  9848.  
  9849.  
  9850. For more info on LADE, fax or send us an email.
  9851.  
  9852. Xorian Technologies
  9853. email: xorian@solomon.technet.sg
  9854. Fax: +65 253-7709
  9855. Tel: +65 255-7151
  9856. -- 
  9857. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9858. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9859.  
  9860.  
  9861. From compilers Tue Apr 20 10:07:12 EDT 1993
  9862. Newsgroups: comp.compilers
  9863. Path: iecc!compilers-sender
  9864. From: parrt@ecn.purdue.edu (Terence J Parr)
  9865. Subject: Re: Semantic predicates into grammar specifications
  9866. Message-ID: <93-04-067@comp.compilers>
  9867. Keywords: parse, tools
  9868. Sender: compilers-sender@iecc.cambridge.ma.us
  9869. Organization: Compilers Central
  9870. References: <93-04-044@comp.compilers> <93-04-066@comp.compilers>
  9871. Date: Mon, 19 Apr 1993 20:45:31 GMT
  9872. Approved: compilers@iecc.cambridge.ma.us
  9873.  
  9874. I thank xorian@solomon.technet.sg (Xorian Technologies) for furthering my
  9875. brief introduction to predicates.  A couple of comments on his summary:
  9876.  
  9877. As will the LADE system, our semantic predicates have access to all
  9878. information about the current parse, results of user actions and current
  9879. lexical state etc... (although LL(k) parsers know more about their *exact*
  9880. position in the parse than LR(k) parsers do).
  9881.  
  9882. Of particular interest in Xorian's posting is:
  9883.  
  9884. > In C++, there are many pathological ambiguities which are unresolvable for
  9885. > lr(k) or ll(k) for any k. They require, instead, an unbounded lookahead.
  9886. > This can be accomplished by predicating the reduction of a production on a
  9887. > successful recursive parsing of the forward stream.  In essence, the
  9888. > current parse is suspended and a secondary, simplified, parse is
  9889. > initiated. If the forward parse succeeds, then the production is reduced
  9890. > and the primary parsing proceeds as usual from the original point.  If the
  9891. > forward parse fails, another alternative is considered.
  9892.  
  9893. Quoting from Ellis and Stroustrup's ARM where they discuss some rather
  9894. nasty C++ ambiguities:
  9895.  
  9896. "In a parser with backtracking the disambiguating rule can be stated very
  9897. simply:
  9898.  
  9899.     [1] If it looks like a \fIdeclaration\fP, it is; otherwise
  9900.     [2] if it looks like an \fIexpression\fP, it is; otherwise
  9901.     [3] it is a syntax error."
  9902.  
  9903. PCCTS notation for Stroustrup's solution is simply:
  9904.  
  9905. stat:   (declaration)?
  9906.     |   expression
  9907.     ;
  9908.  
  9909. PCCTS-generated parsers are completely deterministic, LL(k), until you
  9910. enter a (...)? block which can be viewed as a guess block (backtracking).
  9911. Note that this guess block is NOT a simplified parse; hence, you will be
  9912. doing arbitrary lookahead with full CFG power (not regular expressions,
  9913. for example).  The full form of our (...)? blocks are:
  9914.  
  9915.     (syntactic_predicate)? conditional_production
  9916.  
  9917. where syntactic_predicate can be any EBNF grammar construct (except a new
  9918. rule definition).  If the EBNF grammar fragment is matched on the input
  9919. stream, the conditional_production is then applied.  The short form, as
  9920. employed above, is
  9921.  
  9922.     (grammar_fragment)?
  9923.  
  9924. which is really
  9925.  
  9926.     (grammar_fragment)? grammar_fragment
  9927.  
  9928. In summary, I strongly advocate the use semantic and syntactic (guessing)
  9929. predicates in deterministic parsers and am happy that LADE and others are
  9930. of the same mind.
  9931.  
  9932. Semantic predicates in PCCTS were released in December 1992 as version
  9933. 1.06.  Version 1.07, which includes the syntactic predicates, will be out
  9934. this Summer.  Information about PCCTS can be obtained by mailing to
  9935. pccts@ecn.purdue.edu with a blank "Subject:" line.
  9936.  
  9937. Terence Parr
  9938. Purdue University Electrical Engineering
  9939. -- 
  9940. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9941. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9942.  
  9943.  
  9944. From compilers Tue Apr 20 10:08:26 EDT 1993
  9945. Xref: iecc comp.compilers:4526 comp.sys.sun.misc:7764
  9946. Newsgroups: comp.compilers,comp.sys.sun.misc
  9947. Path: iecc!compilers-sender
  9948. From: hpage@access.digex.com (Howard W Page)
  9949. Subject: Sun C and Fortran options
  9950. Message-ID: <93-04-068@comp.compilers>
  9951. Followup-To: comp.sys.sun.misc
  9952. Summary: Looking for Sun optimization flags that work best.
  9953. Keywords: C, Fortran, performance, question
  9954. Sender: compilers-sender@iecc.cambridge.ma.us
  9955. Organization: AIB Software, Inc.
  9956. Date: Tue, 20 Apr 1993 01:13:26 GMT
  9957. Approved: compilers@iecc.cambridge.ma.us
  9958.  
  9959. I'm doing research on the Sun C and Fortran comilers trying to determine
  9960. the relative effect of the optimization flags.  In addition to the
  9961. documented flags I've also found the loop unrolling option invoked by
  9962. -Qoption iropt -lN, where N is the level of unrolling.  Are there other
  9963. supposedly hidden flags that people know about that I might try? Please
  9964. respond to hpage@digex.com.
  9965.  
  9966. Thanks
  9967. -- 
  9968. Send compilers articles to compilers@iecc.cambridge.ma.us or
  9969. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  9970.  
  9971.  
  9972. From compilers Tue Apr 20 10:12:06 EDT 1993
  9973. Newsgroups: comp.compilers
  9974. Path: iecc!compilers-sender
  9975. From: Sanjay Jinturkar <sj3e@server.cs.virginia.edu>
  9976. Subject: Run time optimizations
  9977. Message-ID: <93-04-069@comp.compilers>
  9978. Keywords: optimize, question, comment
  9979. Sender: compilers-sender@iecc.cambridge.ma.us
  9980. Organization: University of Virginia Computer Science Department
  9981. Date: Tue, 20 Apr 1993 02:10:16 GMT
  9982. Approved: compilers@iecc.cambridge.ma.us
  9983.  
  9984. Compilers generate very conservative code. In absence of some information,
  9985. the compiler assumes the worst case and generates the code accordingly.
  9986. How about generating two pieces of code - one conservative and the other
  9987. with some aggressive optimizations, and then making a check at run
  9988. time(about the information that was missing at compile time) to see which
  9989. piece of code should be executed.  An example use of such technique could
  9990. be in doing an optimization which would be safe only in absence of
  9991. aliasing. The aliasing information could be checked at run time and
  9992. appropriate pice of code could be executed.  Will such techniques pay? Is
  9993. there some previous work in this area? If yes, could someone give some
  9994. pointers to such work..
  9995.  
  9996. Thanks in advance.
  9997.  
  9998. -Sanjay
  9999. [People have done this from time to time.  The HP3000 APL system in the late
  10000. 1970s generated code on the fly.  The first time you ran a function, it
  10001. generated very optimistic code that assumed that the arguments to the
  10002. function would always be of the same type and shape as they were on the first
  10003. call, with "signature" code at the beginning to check that the assumptions
  10004. were satisfied.  If not, it fell back into the compiler which generated
  10005. slower but more general code.  It worked pretty well considering how slow
  10006. the underlying machine was. -John]
  10007. -- 
  10008. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10009. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10010.  
  10011.  
  10012. From compilers Tue Apr 20 10:13:23 EDT 1993
  10013. Newsgroups: comp.compilers
  10014. Path: iecc!compilers-sender
  10015. From: chris@stokeisland.ohi.com (Chris Traynor)
  10016. Subject: Pascal grammar
  10017. Message-ID: <93-04-070@comp.compilers>
  10018. Keywords: Pascal, parse, comment
  10019. Sender: compilers-sender@iecc.cambridge.ma.us
  10020. Organization: Compilers Central
  10021. Date: Tue, 20 Apr 1993 07:07:29 GMT
  10022. Approved: compilers@iecc.cambridge.ma.us
  10023.  
  10024. All:
  10025.     Quite a while ago I saw someone ask for a pascal grammar.  The
  10026. replies indicated that they could hack one out or get a partial one from
  10027. the p2c utility.  Well, I just saw a public domain pascal grammar for ISO
  10028. Pascal at ftp.uu.net - the path is
  10029. usenet/comp.sources.unix/volume4/iso_pascal.Z The file is unfortunately
  10030. dated 1986, but should be the best starting point for a lexer and parser.
  10031. Hope this helps that person.
  10032.  
  10033. Cheers,
  10034. Christopher Traynor, |Object Horizons, Ltd.
  10035. [How much has Pascal changed since 1986? -John]
  10036. -- 
  10037. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10038. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10039.  
  10040.  
  10041. From compilers Tue Apr 20 10:13:56 EDT 1993
  10042. Newsgroups: comp.compilers
  10043. Path: iecc!compilers-sender
  10044. From: dekker@dutiag.twi.tudelft.nl (Rene Dekker)
  10045. Subject: research on transformational systems
  10046. Message-ID: <93-04-071@comp.compilers>
  10047. Keywords: translator, question
  10048. Sender: compilers-sender@iecc.cambridge.ma.us
  10049. Organization: Delft University of Technology
  10050. Date: Tue, 20 Apr 1993 08:23:43 GMT
  10051. Approved: compilers@iecc.cambridge.ma.us
  10052.  
  10053. As a PhD project I am working on transformational systems. These are
  10054. systems that can perform transformations from one language into another.
  10055. Generally you describe these transformations by rules acting on abstract
  10056. syntax trees. Examples of the kind of transformations that can be
  10057. described are: optimization, code-generation, parallellization,
  10058. reverse-engeneering. Examples of transformational systems are: PUMA (GMD
  10059. Karlsruhe), SAFE/TI (ISI) and HOPE (Darlington).
  10060.  
  10061. I am looking for literature on transformational systems. In particular,
  10062. any survey articles and recent research are welcome.
  10063.  
  10064. Thanks,
  10065. Rene.
  10066. --
  10067. Rene Dekker           dekker@dutiba.tudelft.nl             +3115-783850
  10068. Delft University of Technology    Technical Mathematics and Informatics
  10069. -- 
  10070. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10071. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10072.  
  10073.  
  10074. From compilers Tue Apr 20 10:16:55 EDT 1993
  10075. Newsgroups: comp.compilers
  10076. Path: iecc!compilers-sender
  10077. From: Paul.Klint@cwi.nl (Paul Klint)
  10078. Subject: CFD: European Conferences on Programming Research
  10079. Message-ID: <93-04-072@comp.compilers>
  10080. Followup-To: poster
  10081. Keywords: conference, question
  10082. Sender: compilers-sender@iecc.cambridge.ma.us
  10083. Organization: CWI, Amsterdam
  10084. Date: Tue, 20 Apr 1993 13:27:38 GMT
  10085. Approved: compilers@iecc.cambridge.ma.us
  10086.  
  10087.  
  10088.              CALL FOR DISCUSSION
  10089.              ===================
  10090.  
  10091.  
  10092.           Should we restructure the European
  10093.           ----------------------------------
  10094.  
  10095.                 Conferences in
  10096.                ---------------
  10097.  
  10098.             Programming Research?
  10099.                         ---------------------
  10100.  
  10101.  
  10102.  
  10103.             Paul Klint (Paul.Klint@cwi.nl)
  10104.  
  10105.  
  10106.               Spring 1993
  10107.  
  10108.  
  10109.  
  10110.                    Abstract
  10111.  
  10112.         Among some European researchers in the areas of programming
  10113.      languages, semantics and programming the concern is growing that this
  10114.      field is not adequately represented in a major, high quality, conference
  10115.      in Europe. The many conferences being organized in this and related
  10116.      fields (like, e.g., PLIP, ESOP, CC, PARLE, TAPSOFT) are competing
  10117.      with each other in a too small market and therefore they have a hard
  10118.      job in building up sufficient critical mass to become competitive with
  10119.      the big conferences in the USA.
  10120.         Can we join efforts and change this situation? In this note I pro-
  10121.      pose to create a European organization (tentatively called EAPLS ---
  10122.      European Association for Programming Languages and Systems --- pat-
  10123.      terned after the EATCS) that aims at creating a platform of researchers
  10124.      that can restructure the European conferences in the desired direction.
  10125.         This note explains this idea in more detail and invites you to par-
  10126.      ticipate in a debate on this matter.
  10127.  
  10128. 1. BACKGROUND
  10129. =============
  10130. The concern about the future direction of the ``Programming Languages
  10131. and Systems'' area has been expressed in several programme committees of
  10132. European conferences in this field. As far as I can reconstruct history, the
  10133. following people were involved in these discussions: Harald Ganzinger Chris
  10134. Hankin, Berthold Hoffman, Neil Jones, Uwe Kastens, Peter D. Mosses, Alan
  10135. Mycroft, and Reinhard Wilhelm. It was the latter who contributed the analysis
  10136. in the next section and suggested me to take the initiative to come to an
  10137. European organization in this field.
  10138.  
  10139. 2. THE CURRENT SITUATION
  10140. ========================
  10141. The situation concerning European conferences in the areas of Program-
  10142. ming Languages, Semantics, and Programming is not satisfactory. Different
  10143. groups of scientists have established conference and workshop series which
  10144. compete for a too small market.  From these only ICALP has a (more or
  10145. less) permanent carrier, i.e. the EATCS. The others were established by ES-
  10146. PRIT projects or Basic Research Actions, groups in or among the national
  10147. computer science organizations, or just groups of cooperating individuals.
  10148.    ICALP (International Colloquium on Automata, Languages, and Pro-
  10149. gramming) is the most established series; however, in the course of time it
  10150. has suffered several turns of focus. The last conferences were dominated by
  10151. papers on algorithms and complexity; few papers had to do with automata,
  10152. some with semantics of programming languages, and none with program-
  10153. ming.
  10154.    ESOP (European Symposium on Programming) has been established in
  10155. 1985 and been organized 1986 (Saarbruecken), 1988 (Nancy), 1990 (Copen-
  10156. hagen), and 1992 (Rennes). It has its strong areas in semantics, types, and
  10157. functional programming.
  10158.    PLILP (Programming Language Implementation and Logic Program-
  10159. ming) It has been organized in 1988 (Orleans), 1990 (Linkoeping), Passau
  10160. (1991) and Leuven (1992). The strive for a palindromic name has caused a
  10161. bias towards logic programming mixed with a certain amount of implemen-
  10162. tation matters.
  10163.    CC (Compiler Construction) is the continuation of a workshop series
  10164. in the former German Democratic Republic.  Its 1992 instance is run in
  10165. Paderborn. It is completely devoted to language implementation.
  10166.    PARLE (Parallel Architectures and Languages Europe) is organized in
  10167. Eindhoven by Philips. It takes place in odd years since 1987. As the name
  10168. states, it covers the combination of parallel languages and architectures.
  10169.    TAPSOFT (Theory and Practice of Software ...)
  10170.    ALP (Algebraic and Logic Programming)
  10171.    The competition of too many conferences for a rather small supply of
  10172. scientific results has prevented any of the series to really reach a high in-
  10173. ternational standing.  Frankly stated, ESOP never really makes it to the
  10174. POPL level, PLILP never to the level of ICLP, CC never to that of ACM
  10175. SIGPLAN PLDI, etc.
  10176.    This is made even worse, when two of the conferences fix their deadline
  10177. to the same day, e.g. March 1, 1992 for CC'92 and PLILP'92.
  10178.  
  10179. 3. PLAN OF ACTION
  10180. =================
  10181. We could remedy the situation sketched above by creating a scientific orga-
  10182. nization similar to EATCS that takes the responsibility to restructure the
  10183. current situation and work in the direction of a major, high quality confer-
  10184. ence. The Profile of such an organization is sketched in the next section.
  10185.    Of course, this change cannot be achieved by force but only by persua-
  10186. sion. Ideally, we start with synchronizing the dates and places of some of the
  10187. conferences. And indeed, the program committees of ESOP, CC and CAAP
  10188. have already agreed with such a synchronization and have their conferences
  10189. in the same week in Edinburgh in 1994.
  10190.    Each conference can then keep its own identity but profit from the pres-
  10191. ence of the other ones (number of attendents, increased possibilities to get
  10192. funding and sponsoring, discounts on facilities, resources available for com-
  10193. mon events, etc.) Later on, when it turns out that this synchronization is
  10194. beneficial we may transform this set of cooperating conferences into a single
  10195. conference with separate sections.
  10196.    I propose the following plan of action to investigate whether there is
  10197. enough support for this line of development.
  10198.  
  10199.    o April-May 1993: Discussion (by E-mail) of this document among
  10200.      colleagues.
  10201.  
  10202.    o June 1993:  If, the outcome of the discussion is positive:  make final
  10203.       proposal for EAPLS, and request for final comments.
  10204.  
  10205.    o July-August 1993: Official creation of EAPLS, establish board and
  10206.       scientific council.
  10207.  
  10208. 4. PROFILE OF EAPLS
  10209. ===================
  10210.    Aims
  10211.    ----
  10212.    o Act as an international professional non-profit organization represent-
  10213.      ing the interests of its members.
  10214.  
  10215.    o Promote research and education in the area of ``Programming'' here
  10216.      understood as the design, specification and implementation of pro-
  10217.      gramming languages and systems.
  10218.  
  10219.    o Promote the exchange of ideas and results in the area of Programming.
  10220.  
  10221.    o Organize an annual international conference on Programming Lan-
  10222.      guages and Systems and publish the proceedings.
  10223.  
  10224.    Actions
  10225.    -------
  10226.    o Organize and sponsor summer schools.
  10227.  
  10228.    o Sponsor specialist workshops and national meetings.
  10229.  
  10230.    o Sponsor scientific publications in the field.
  10231.  
  10232.    o Cooperate with related scientific and national societies and institu-
  10233.      tions.
  10234.  
  10235.    Members
  10236.    -------
  10237.    o Researchers.
  10238.  
  10239.    o Students.
  10240.  
  10241.    Organization
  10242.    ------------
  10243.    o A small board consisting of a president, vice-president, treasurer and
  10244.      secretary.
  10245.  
  10246.    o A larger scientific council with members from the European countries.
  10247.  
  10248. 5. HOW CAN YOU PARTICIPATE?
  10249. ===========================
  10250. Of course, you may want to react directly to the text of this document itself.
  10251. In addition, here is a list of explicit questions:
  10252.  
  10253.   1. Do you agree/disagree with the observations in Section 2 concerning
  10254.      the current situation of European conferences in the field of Program-
  10255.      ming?
  10256.  
  10257.   2. Do you support/oppose the idea of creating an organization like EAPLS
  10258.      as sketched in Section 4?
  10259.  
  10260.   3. Do you have additional suggestions for the aims, actions, members, or
  10261.      organization of EAPLS?
  10262.  
  10263. Alan Mycroft has arranged for EAPLS to be set up as a 'mailbase'. A
  10264. mailbase is a database for mail-directed communication and, inter alia,
  10265. manages membership, message archival etc.
  10266.  
  10267. I invite you all to join EAPLS by sending a one-line message of the form
  10268.       join eapls <firstname> <lastname>
  10269.  
  10270. to the e-mail address
  10271.       mailbase@mailbase.ac.uk
  10272. (the 'subject' field is ignored).
  10273.  
  10274. On joining you will receive, by e-mail, documentation on use of mailbase
  10275. (including how to remove yourself from the list and to investigate other
  10276. lists).
  10277.  
  10278. >>>>>>After joining<<<<<< you can communicate with all other members by
  10279. mailing to eapls@mailbase.ac.uk and communicate with its adminstator
  10280. by mailing to eapls-request@mailbase.ac.uk.
  10281.  
  10282. And last, but not least
  10283.  
  10284.    o forward copies of this note to colleagues of yours that might be inter-
  10285.      ested.
  10286.  
  10287.    o send us details about workshops and conferences you plan to organize
  10288.      so that we can produce an overview of planned activities.
  10289. -- 
  10290. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10291. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10292.  
  10293.  
  10294. From compilers Tue Apr 20 16:10:25 EDT 1993
  10295. Newsgroups: comp.compilers
  10296. Path: iecc!compilers-sender
  10297. From: beaver@broue.rot.qc.ca (Andre Boivert)
  10298. Subject: Lexical Analyzer for F77
  10299. Message-ID: <93-04-073@comp.compilers>
  10300. Keywords: Fortran, lex, question, comment
  10301. Sender: compilers-sender@iecc.cambridge.ma.us
  10302. Organization: Compilers Central
  10303. Date: Tue, 20 Apr 1993 16:44:21 GMT
  10304. Approved: compilers@iecc.cambridge.ma.us
  10305.  
  10306. I am looking for a lexical analyzer for Fortran 77 (!!!). I started to
  10307. write one using Lex, but it seems that it is not best way to go (is that
  10308. right?).
  10309.  
  10310. I heard of a program called 'fortlex' that could do the job.
  10311.  
  10312. If you have any sources (preferably in C), algorithms, references that
  10313. could help me, I would greatly appreciate.
  10314.  
  10315. Thank you.
  10316.  
  10317. Andre Boisvert
  10318. beaver@rot.qc.ca
  10319. [My Fortran subset parser in the compilers archives does a fairly respectable
  10320. job of tokenizing Fortran.  You can't tokenize it without doing a certain
  10321. amount of parsing as well, e.g., "10e5" is a floating point number except
  10322. in the context "do 10e5 = 1,100" where it is the statement number 10 and
  10323. the variable name e5, or "do 10e5 = 1.100" where do10e5 is a variable name.
  10324. I'd say it's not as bad as it sounds, but it is.  In the full F77 parser I
  10325. wrote for INfort 15 years ago there were at least 12 separate lexical kludges
  10326. like that. -John]
  10327. -- 
  10328. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10329. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10330.  
  10331.  
  10332. From compilers Wed Apr 21 19:24:34 EDT 1993
  10333. Newsgroups: comp.compilers
  10334. Path: iecc!compilers-sender
  10335. From: hagerman@ece.cmu.edu (John Hagerman)
  10336. Subject: Control Dependencies for Loops
  10337. Message-ID: <93-04-074@comp.compilers>
  10338. Keywords: analysis, question
  10339. Sender: compilers-sender@iecc.cambridge.ma.us
  10340. Organization: Carnegie Mellon University
  10341. Date: Tue, 20 Apr 1993 21:31:36 GMT
  10342. Approved: compilers@iecc.cambridge.ma.us
  10343.  
  10344. This definition of control dependence is fairly typical, right?
  10345.  
  10346.   DEP(x,y)  iff  !POST-DOM(y,x)
  10347.             and  there exists a path P=<x,...,y> such that
  10348.                  for all z in P (except x,y), POST-DOM(y,z)
  10349.  
  10350. Consider the following loop:
  10351.  
  10352.   while (E) do S;
  10353.  
  10354. and the corresponding CFG:
  10355.  
  10356.     [START]
  10357.        |
  10358.        v
  10359.       [E]<-+
  10360.        |   |
  10361.        v   |
  10362.     +-<?>  |
  10363.     |  |   |
  10364.     |  v   |
  10365.     | [S]  |
  10366.     |  |   |
  10367.     |  +---+
  10368.     v
  10369.   [END]
  10370.  
  10371. The above definition specifies that DEP(<?>,[E]) and DEP(<?>,[S]).  But it
  10372. seems like I should only be concerned with the dependencies within a
  10373. single iteration, so why have DEP(<?>,[E]) at all?  Is it only an artifact
  10374. of the definition?  If I change the definition so that backedges are not
  10375. permitted in P, do I shoot myself?
  10376.  
  10377. Thanks - John
  10378. --
  10379. hagerman@ece.cmu.edu
  10380. -- 
  10381. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10382. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10383.  
  10384.  
  10385. From compilers Wed Apr 21 19:25:20 EDT 1993
  10386. Newsgroups: comp.compilers
  10387. Path: iecc!compilers-sender
  10388. From: Yutaka_Kuroda@QM.SRI.COM
  10389. Subject: RPG II to C conversion tool
  10390. Message-ID: <93-04-075@comp.compilers>
  10391. Keywords: RPG, C, translator, question
  10392. Sender: compilers-sender@iecc.cambridge.ma.us
  10393. Organization: SRI International
  10394. Date: Tue, 20 Apr 1993 23:47:09 GMT
  10395. Approved: compilers@iecc.cambridge.ma.us
  10396.  
  10397.  I am looking for a tool that converts AS/400 RPG II to C language on
  10398. UNIX.  Does anybody know of one?  Alternatively, it can be a company that
  10399. has done a coversion like this before.
  10400. -- 
  10401. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10402. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10403.  
  10404.  
  10405. From compilers Wed Apr 21 19:26:52 EDT 1993
  10406. Newsgroups: comp.compilers
  10407. Path: iecc!compilers-sender
  10408. From: jwe@emx.cc.utexas.edu (John W. Eaton)
  10409. Subject: Re: Lexical Analyzer for F77
  10410. Message-ID: <93-04-076@comp.compilers>
  10411. Keywords: Fortran, lex
  10412. Sender: compilers-sender@iecc.cambridge.ma.us
  10413. Organization: The University of Texas at Austin, Austin, Texas
  10414. References: <93-04-073@comp.compilers>
  10415. Date: Wed, 21 Apr 1993 00:25:39 GMT
  10416. Approved: compilers@iecc.cambridge.ma.us
  10417.  
  10418. beaver@broue.rot.qc.ca (Andre Boivert) writes:
  10419. > I am looking for a lexical analyzer for Fortran 77 (!!!).
  10420.  
  10421. The paper
  10422.  
  10423.   J. K. Slape and P. J. L. Wallis, A Modification of Sale's Algorithm
  10424.   to Accomodate Fortran 77, The Computer Journal, Volume 34 Number 4,
  10425.   1991.
  10426.  
  10427. describes a technique for classifying Fortran statements and includes code
  10428. (about 350 lines of of Fortran) to do it.
  10429.  
  10430. Unfortunately, it isn't complete -- it classifies statement functions as
  10431. assignments, and there are several restrictions, such as requiring that
  10432. simple goto's must have at least the first digit of the label on the
  10433. initial line, and that a logical if statement which has an executable
  10434. statement part that begins with the letters `then' must have at least one
  10435. more non-blank character on the initial line.
  10436.  
  10437. Depending on what you need to do, these restrictions may be acceptable,
  10438. and you might be able to use this technique to greatly simplify your
  10439. parser.
  10440.  
  10441. Another possibility might be to use the GNU Fortran front end.  It's in
  10442. alpha test now and isn't generally available yet -- ask
  10443. fortran@gnu.ai.mit.edu for more information.
  10444. --
  10445. John W. Eaton, jwe@che.utexas.edu
  10446. -- 
  10447. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10448. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10449.  
  10450.  
  10451. From compilers Wed Apr 21 19:28:52 EDT 1993
  10452. Newsgroups: comp.compilers
  10453. Path: iecc!compilers-sender
  10454. From: Ariel Meir Tamches <tamches@wam.umd.edu>
  10455. Subject: predicate parsing
  10456. Message-ID: <93-04-077@comp.compilers>
  10457. Keywords: parse, tools
  10458. Sender: compilers-sender@iecc.cambridge.ma.us
  10459. Organization: Compilers Central
  10460. References: <93-04-044@comp.compilers> <93-04-066@comp.compilers>
  10461. Date: Wed, 21 Apr 1993 05:33:45 GMT
  10462. Approved: compilers@iecc.cambridge.ma.us
  10463.  
  10464. Just would like to add my two cents worth to the predicate parsing
  10465. discussion that has been taking place among Terence Parr
  10466. (parrt@ecn.purdue.edu) and Xorian technology (xorian@solomon.technet.sg)
  10467. with their new PCCTS and LADE parsing tools.
  10468.  
  10469. One thing that I haven't seen noted is that it's just about impossible to
  10470. add predicate parsing to any type of bottom-up parsing engine.  A formal
  10471. argument could be made by looking at LR handle generation (it depends on
  10472. the PDA stack, not leaving much room for predicates) but a more intuitive
  10473. one would simply note that top-down parsers, such as LL, have a control
  10474. flow completely analagous to "real-world" programming languages, such as C
  10475. (think "recursive descent").  If you have any version of PCCTS, examine
  10476. the C code it produces; it will look suspiciously like that which you
  10477. would have created had you been writing a recursive-descent parser from
  10478. scratch in C.  Each grammar rule is represented by exactly one C function,
  10479. which among other things made it easy even in PCCTS 1.00 to effortlessly
  10480. have inherited and synthesized attributes.  Inherited attributes are
  10481. call-by-value parameters to that procedure; synhesized variables are
  10482. call-by-reference.
  10483.  
  10484. Sure, Yacc has synthesized attributes, and there is a proof that inherited
  10485. attributes can be coaxed with the addition of extra temporary rules.  The
  10486. dragon book states (page 341) that "The impression that top-down parsing
  10487. allows more flexibility for translation is shown to be false by a proof in
  10488. Brosgol [1974] that a translation scheme based on an LL(1) grammar can be
  10489. simulated during LR(1) parsing.  Independently, Watt [1977] used marker
  10490. nonterminals to ensure that the values of inherited attributes appear on a
  10491. stack during parsing."  I would have to contest this assertion, especially
  10492. in the light of semantic predicates, which the book seems never to have
  10493. heard of.  The Dragon book may be right about being able to coax inherited
  10494. attributes in Yacc, but I don't think it can take the next big step:
  10495. having such attributes take an active role in parsing decisions.
  10496.  
  10497. To clarify, consider a conceptually simple but extremely powerful addition
  10498. to PCCTS: Taking a look at the beautiful recursive-descent C code produced
  10499. by PCCTS, one can't help but wonder if we can tap into the power of C from
  10500. our parser.  Sure, Yacc has C actions, but they are a "scam" when it comes
  10501. to making parsing decisions.  They simply can't take part in parsing,
  10502. unless one resorts to horrifying hacks such as tinkering with Yacc's PDA
  10503. stack from within a Yacc action.  Predicate parsing was relatively simple
  10504. to add to pccts 1.06 (you can clarify me on this if I'm wrong, Terence)
  10505. because all it has to do is copy the predicate right into the C code,
  10506. overriding the normal "default predicate" which is simply good 'ole LL(k)
  10507. tests of FIRST(), etc.
  10508.  
  10509. It's hard to imagine how one can insert arbitrary predicates in a
  10510. bottom-up parser; for the same reason it's hard for bottom-up parsers to
  10511. have inherited attributes - their control flow is "screwy" - top-down is
  10512. the way to go.  People used to (and maybe still do) laugh at LL parsers;
  10513. after all, LR(k) is a proper superset of LL(k).  But when we consider how
  10514. easy it is to add predicates and inherited attributes to LL, we see that
  10515. "conventional wisdom" has been wrong.
  10516.  
  10517. On a theoretical note, it is very easy to prove that the latest version of
  10518. PCCTS (1.06 - 1.07 [as long as it has predicates]) is Turing-equivalent.
  10519. (I did it by writing a TM simulator in PCCTS, which I believe is a
  10520. sufficient condition by Church's Thesis.)
  10521.  
  10522. >From another angle, consider hacks used by Yacc to get complex
  10523. (non-LALR(1)) grammars to parse: I'm still trying to decipher the tricks
  10524. and hacks used in GNU C++ and Jim Roskind's Yacc grammars.  Bottom-up
  10525. parsing is simply not the answer; with predicates used in the new breed of
  10526. top-down parsers, we now have a superior alternative.
  10527.  
  10528. Ariel Tamches
  10529. University of Maryland, College Park
  10530. tamches@cs.umd.edu
  10531. -- 
  10532. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10533. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10534.  
  10535.  
  10536. From compilers Wed Apr 21 19:29:29 EDT 1993
  10537. Newsgroups: comp.compilers
  10538. Path: iecc!compilers-sender
  10539. From: uysal@cs.umd.edu (Mustafa Uysal)
  10540. Subject: Dynamic Slices...
  10541. Message-ID: <93-04-078@comp.compilers>
  10542. Keywords: debug, question
  10543. Sender: compilers-sender@iecc.cambridge.ma.us
  10544. Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
  10545. Date: Wed, 21 Apr 1993 11:51:29 GMT
  10546. Approved: compilers@iecc.cambridge.ma.us
  10547.  
  10548.   Are there any references dealing with the generation of dynamic slices?
  10549. In particular, I'm interested in generation of a (backward) dynamic slice
  10550. given the state of the program execution (ie. variables, program counter,
  10551. etc).
  10552.  
  10553.   The idea is that, when a person writes a program that crashes, one
  10554. can(?) generate a slice that captures the part of the program causing the
  10555. crash in that particular execution. Then the programmer may concentrate on
  10556. this slice in the debugging phase. However, the information available at
  10557. the time of the crash is only the "core dump" (plus the source code). My
  10558. question is that is it possible to generate such slices (in a reasonable
  10559. time), and if yes, could you point me to relevant references?
  10560.  
  10561.   Thanks in advance,
  10562.  
  10563.   Mustafa Uysal
  10564.  (E-mail: uysal@cs.umd.edu)
  10565. -- 
  10566. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10567. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10568.  
  10569.  
  10570. From compilers Wed Apr 21 19:31:27 EDT 1993
  10571. Xref: iecc comp.arch:28218 comp.compilers:4537
  10572. Newsgroups: comp.arch,comp.compilers
  10573. Path: iecc!compilers-sender
  10574. From: S_JUFFA@IRAV1.ira.uka.de (|S| Norbert Juffa)
  10575. Subject: Optimal code sequences for signed int div/rem by powers of 2
  10576. Message-ID: <93-04-079@comp.compilers>
  10577. Keywords: arithmetic, optimize
  10578. Sender: compilers-sender@iecc.cambridge.ma.us
  10579. Organization: University of Karlsruhe, FRG
  10580. Date: Wed, 21 Apr 1993 13:49:45 GMT
  10581. Approved: compilers@iecc.cambridge.ma.us
  10582.  
  10583. This article is somewhat of a followup to the recent discussion about
  10584. integer division here comp.arch. I am also cross-posting to comp.compilers
  10585. because this stuff may be relevant for people involved with compiler code
  10586. generation.
  10587.  
  10588. Many modern RISC CPUs do not have an integer division instruction (SPARC
  10589. V7, Alpha), have only a division step instruction (AMD 29K), or have a
  10590. rather slow HW-division (microSPARC). Even if there is a division
  10591. instruction, it may fail to produce a remainder (SPARC V8).
  10592.  
  10593. Therefore, people are looking for alternatives to using division. Fast
  10594. alternatives are especially feasible if the divisor is known at compile
  10595. time (e.g. multiplication by reciprocal of divisor). Quite a few posts in
  10596. the recent discussion were involved with speeding up division by powers of
  10597. two known at compile time. This is really easy when dealing with unsigned
  10598. integers (-> shift right), but requires some correction steps for signed
  10599. integers.
  10600.  
  10601. Checking compiler output for 80x86 produced by Microsoft C 7.0 and for
  10602. SPARC by gcc 2.2.3 and the Solaris cc compiler, I find they don't use all
  10603. the optimizations possible for signed integers when the divisor is a power
  10604. of two. Especially, when the divisor is a negated power of two (i.e.
  10605. -2^i), all of these compilers will resort to divide and remainder
  10606. instructions or subroutines, although the shifting and masking approach
  10607. used for unsigned integers could be used with a few correction steps. The
  10608. Microsoft C 7.0 compiler doesn't optimize any division/remainder by 2^i or
  10609. -2^i for signed integers.
  10610.  
  10611. I wonder what the fastest instruction sequences for signed integer
  10612. division by +/- 2^n are for different machines. I know from the discussion
  10613. there are even machines that have signed integer division by powers of two
  10614. in HW (i960).
  10615.  
  10616. I am including the routines I came up with for 80x86 and SPARC for doing
  10617. signed integer division/remainder by +/- 2^i.
  10618.  
  10619. Norbert Juffa (s_juffa@iravcl.ira.uka.de)
  10620.  
  10621. CODE FOR Intel 80x86 (can easily be changed to 32-bit version for >= 386)
  10622. =========================================================================
  10623.  
  10624. / 2:             CMP   AX, 8000h  ; CY = 1, if dividend >= 0
  10625.                  SBB   AX, -1     ; inc AX, if dividend < 0
  10626.                  SAR   AX, 1      ; now do right shift
  10627.  
  10628. / 2^n:           CWD              ; DX = FFFFh if dividend < 0
  10629.                  AND   DX, 2^n-1  ; mask correction
  10630.                  ADD   AX, DX     ; apply correction if necessary
  10631.                  SAR   AX, n      ; now do right shift
  10632.  
  10633. / -2:            CMP   AX, 8000h  ; CY = 1, if dividend >= 0
  10634.                  SBB   AX, -1     ; inc AX, if dividend < 0
  10635.                  SAR   AX, 1      ; now do right shift
  10636.                  NEG   AX         ; use (x div -2) = - (x div 2)
  10637.  
  10638. / -2^n:          CWD              ; DX = FFFFh if dividend < 0
  10639.                  AND   DX, 2^n-1  ; mask correction
  10640.                  ADD   AX, DX     ; apply correction if necessary
  10641.                  SAR   AX, n      ; now do right shift
  10642.                  NEG   AX         ; use (x div -2^n) = - (x div 2^n)
  10643.  
  10644. % 2, % -2:       CWD              ; generate flag, FFFFh id divd < 0, else 0
  10645.                  AND   AX, 1      ; mask out remainder
  10646.                  XOR   AX, DX     ; negate
  10647.                  SUB   AX, DX     ;  remainder if dividend < 0
  10648.  
  10649. % 2^n, % -2^n:   CWD              ; generate mask, FFFFh if divd < 0, else 0
  10650.                  AND   DX, 2^n-1  ; mask correction
  10651.                  ADD   AX, DX     ; apply pre-correction if necessary
  10652.                  AND   AX, 2^n-1  ; mask out remainder
  10653.                  SUB   AX, DX     ; apply post-correction if necessary
  10654.  
  10655.  
  10656. CODE FOR SPARC
  10657. ==============
  10658.  
  10659. Dividing a signed integer by a positive power of two (1<<n) known at
  10660. compile time.
  10661.  
  10662. 1) for i/2:        addcc   %o1,%o1,%g0    ! carry if %o1 < 0
  10663.                    addx    %o1,%g0,%o1    ! inc %o1, if %o1 < 0
  10664.                    sra     %o1,1,%o1      ! do the shift
  10665.  
  10666.    Although this code sequence uses three instructions, just like what is
  10667.    produced by gcc now, it has the advantage that it doesn't need an
  10668.    additional register. It has the disadvantage of destroying the
  10669.    condition codes.
  10670.  
  10671.  
  10672. 2) for i/(1<<n):   sra     %o1,31,%o2     ! %o2 = 0xffffffff if %o1 < 0
  10673.                    srl     %o2,32-n,%o2   ! (1<<n)-1, if %o1<0, else 0
  10674.                    add     %o1,%o2,%o1    ! apply correction
  10675.                    sra     %o1,n,%o1      ! do the shift
  10676.  
  10677.    The advantage of this sequence is that it doesn't use a branch and has
  10678.    no problem with n>=13 since it doesn't use immediate constants for the
  10679.    correction step, also it doesn't destroy the condition codes.
  10680.  
  10681. Dividing a signed integer by a negated positive power of two (-(1<<n))
  10682. should make use of the identity x / (-(1<<n)) = -(x / (1<<n)) and then
  10683. apply the code given above. Currently, gcc 2.2.3 generates calls to .div
  10684.  
  10685. 1) for i/-2:       addcc   %o1,%o1,%g0    ! carry if %o1 < 0
  10686.                    addx    %o1,%g0,%o1    ! inc %o1, if %o1 < 0
  10687.                    sra     %o1,1,%o1      ! i / 2
  10688.                    neg     %o1            ! -(i / 2)
  10689.  
  10690. 2) for i/(-(1<<n)):sra     %o1,31,%o2     ! %o2 = 0xffffffff if %o1 < 0
  10691.                    srl     %o2,32-n,%o2   ! (1<<n)-1, if %o1<0, else 0
  10692.                    add     %o1,%o2,%o1    ! apply correction
  10693.                    sra     %o1,n,%o1      ! i / (1<<n)
  10694.                    neg     %o1            ! -(i / (1<<n))
  10695.  
  10696.  
  10697. Computing the remainder (% operator) of a division of a signed integer by
  10698. a positive power of two (1<<n) known at compile time. Currently, gcc uses
  10699. calls to .rem.
  10700.  
  10701. 1) for i%2, i%(/-2):
  10702.                    sra     %o1,31,%o2     ! 0xFFFFFFFF, if %o < 0, else 0
  10703.                    and     %o1,1,%o1      ! mask out remainder
  10704.                    xor     %o1,%o2,%o1    ! negate remainder if quotient
  10705.                    sub     %o1,%o2,%o1    !  negative (sign(quot)=sign(rem)!)
  10706.  
  10707.  
  10708. 2) for i%(1<<n), i%(-(1<<n)):
  10709.                    sub     %g0,1,%o2      ! 0xffffffff
  10710.                    srl     %o2,32-n,%o2   ! (1<<n)-1
  10711.                    sra     %o1,31,%o3     ! 0xffffffff, if %o1 < 0, else 0
  10712.                    and     %o3,%o2,%o3    ! (1<<n)-1, if %o1 < 0, else 0
  10713.                    add     %o1,%o3,%o1    ! apply correction if necessary
  10714.                    and     %o1,%o2,%o1    ! mask out remainder bits
  10715.                    sub     %o1,%o3,%o1    ! apply correction if necessary
  10716.  
  10717.    This instruction sequence is branch free, doesn't destroy the condition
  10718.    codes and has no problem with n>=13, since it doesn't use immediate
  10719.    constants in the correction step.
  10720. -- 
  10721. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10722. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10723.  
  10724.  
  10725. From compilers Wed Apr 21 19:31:55 EDT 1993
  10726. Newsgroups: comp.compilers
  10727. Path: iecc!compilers-sender
  10728. From: corbett@lupa.Eng.Sun.COM (Robert Corbett)
  10729. Subject: Re: Pascal grammar
  10730. Message-ID: <93-04-080@comp.compilers>
  10731. Keywords: Pascal, parse
  10732. Sender: compilers-sender@iecc.cambridge.ma.us
  10733. Organization: Sun
  10734. References: <93-04-070@comp.compilers>
  10735. Date: Wed, 21 Apr 1993 21:04:11 GMT
  10736. Approved: compilers@iecc.cambridge.ma.us
  10737.  
  10738. >[How much has Pascal changed since 1986? -John]
  10739.  
  10740. ISO Pascal was revised in 1990.  I believe there were about fifty changes,
  10741. ranging from minor to insignificant.  As I recall, none of the changes
  10742. affected the syntax of the language.
  10743.  
  10744. The ISO approved a standard for Extended Pascal in 1991.  Extended Pascal
  10745. has lots of syntactic extensions.
  10746.  
  10747.                     Yours truly,
  10748.                     Robert Corbett
  10749. -- 
  10750. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10751. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10752.  
  10753.  
  10754. From compilers Thu Apr 22 11:37:42 EDT 1993
  10755. Newsgroups: comp.compilers
  10756. Path: iecc!compilers-sender
  10757. From: paco@ariel.cs.rice.edu (Paul Havlak)
  10758. Subject: Re: Control Dependencies for Loops
  10759. Message-ID: <93-04-081@comp.compilers>
  10760. Keywords: analysis
  10761. Sender: compilers-sender@iecc.cambridge.ma.us
  10762. Organization: Rice University
  10763. References: <93-04-074@comp.compilers>
  10764. Date: Thu, 22 Apr 1993 12:15:47 GMT
  10765. Approved: compilers@iecc.cambridge.ma.us
  10766.  
  10767. hagerman@ece.cmu.edu (John Hagerman) writes:
  10768. >This definition of control dependence is fairly typical, right?
  10769. >
  10770. >  DEP(x,y)  iff  !POST-DOM(y,x)
  10771. >            and  there exists a path P=<x,...,y> such that
  10772. >                 for all z in P (except x,y), POST-DOM(y,z)
  10773.  
  10774.     Yes, this is pretty standard, although for this version to be precise,
  10775. POST-DOM must be strict; i.e., POST-DOM(x,x) is false for all x.
  10776.  
  10777. >    [START]
  10778. >       |
  10779. >       v
  10780. >      [E]<-+
  10781. >       |   |
  10782. >       v   |
  10783. >    +-<?>  |
  10784. >    |  |   |
  10785. >    |  v   |
  10786. >    | [S]  |
  10787. >    |  |   |
  10788. >    |  +---+
  10789. >    v
  10790. >  [END]
  10791. >
  10792. >The above definition specifies that DEP(<?>,[E]) and DEP(<?>,[S]).  But it
  10793. >seems like I should only be concerned with the dependencies within a
  10794. >single iteration, so why have DEP(<?>,[E]) at all?  Is it only an artifact
  10795. >of the definition?  ...
  10796.  
  10797.     It's not an artifact, it's the whole point.  Control dependences,
  10798. defined as above, are a powerful abstraction because they can be handled
  10799. very similarly to data dependences.  Like data dependences, control
  10800. dependences are either loop-independent or carried by a particular loop.
  10801. In your example, DEP(<?>,[E]) is loop-carried and DEP(<?>,[S]) is
  10802. loop-independent.
  10803.  
  10804. >        ... If I change the definition so that backedges are not
  10805. >permitted in P, do I shoot myself?
  10806.  
  10807.     Loop-carried control dependences, together with other control and data
  10808. dependences, can create dependence cycles (recurrences).  So they are
  10809. essential for many purposes.  Recurrences must be broken by
  10810. transformations before a loop can be run in parallel.
  10811.     However, if you never perform a transformation that could violate a
  10812. loop-carried control dependence, you may "ignore" them because they are
  10813. implicitly respected.
  10814.  
  10815. Hope this helps,
  10816. Paul
  10817. --
  10818. Paul Havlak            Dept. of Computer Science
  10819. Graduate Student        Rice University, Houston TX 77251-1892
  10820. PFC/ParaScope projects        (713) 527-8101 x2738     paco@cs.rice.edu
  10821. -- 
  10822. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10823. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10824.  
  10825.  
  10826. From compilers Thu Apr 22 11:38:15 EDT 1993
  10827. Newsgroups: comp.compilers
  10828. Path: iecc!compilers-sender
  10829. From: paco@ariel.cs.rice.edu (Paul Havlak)
  10830. Subject: Re: Dynamic Slices...
  10831. Message-ID: <93-04-082@comp.compilers>
  10832. Keywords: debug
  10833. Sender: compilers-sender@iecc.cambridge.ma.us
  10834. Organization: Rice University
  10835. References: <93-04-078@comp.compilers>
  10836. Date: Thu, 22 Apr 1993 12:44:03 GMT
  10837. Approved: compilers@iecc.cambridge.ma.us
  10838.  
  10839. uysal@cs.umd.edu (Mustafa Uysal) writes:
  10840. >  Are there any references dealing with the generation of dynamic slices?
  10841. >In particular, I'm interested in generation of a (backward) dynamic slice
  10842. >given the state of the program execution (ie. variables, program counter,
  10843. >etc).
  10844.  
  10845.     Vernon Lee did some work on dynamic slicing in his dissertation at
  10846. Rice University, advised by Hans Boehm.  Vernon is now at Zycad
  10847. (spelling?) and Hans at Xerox PARC, but I don't have their addresses
  10848. handy.
  10849.     Vernon was working on constructive real arithmetic.  The
  10850. representation allows computation to an arbitrary number of digits
  10851. (assuming sufficient computational resources).  If, for some reason, one
  10852. needs more precision on a value already computed, one would like to
  10853. recompute on a backward dynamic slice rather than repeat the whole
  10854. program.
  10855.     I think this tech report is Vernon's dissertation:
  10856.  
  10857.     Rice COMP TR91-159
  10858.     Optimizing Programs Over the Constructive Reals,
  10859.     Vernon A. Lee Jr., April 1991. ($15.00)
  10860.  
  10861.     A short presentation of the work is in
  10862.  
  10863.     Vernon Lee and Hans Boehm, "Optimizing Programs over the
  10864.     Construct Reals," SIGPLAN '90, pages 102-111.
  10865.  
  10866. Good luck,
  10867. Paul
  10868. --
  10869. Paul Havlak            Dept. of Computer Science
  10870. Graduate Student        Rice University, Houston TX 77251-1892
  10871. PFC/ParaScope projects        (713) 527-8101 x2738     paco@cs.rice.edu
  10872. -- 
  10873. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10874. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10875.  
  10876.  
  10877. From compilers Thu Apr 22 19:04:08 EDT 1993
  10878. Newsgroups: comp.compilers
  10879. Path: iecc!compilers-sender
  10880. From: hagerman@ece.cmu.edu (John Hagerman)
  10881. Subject: More on Control Dependencies for Loops
  10882. Message-ID: <93-04-083@comp.compilers>
  10883. Keywords: analysis, question
  10884. Sender: compilers-sender@iecc.cambridge.ma.us
  10885. Organization: Carnegie Mellon University
  10886. References: <93-04-074@comp.compilers>
  10887. Date: Thu, 22 Apr 1993 17:03:55 GMT
  10888. Approved: compilers@iecc.cambridge.ma.us
  10889.  
  10890. A couple of days ago I asked why "loop-carried" control dependencies
  10891. should be included.  I got a couple of responses by mail saying that
  10892. my basic blocks were wrong.  I don't think this has anything to do
  10893. with my question; the point is that I can construct a loop that will
  10894. have such a dependence.  Here's another try:
  10895.  
  10896.   do S while (E);
  10897.  
  10898. This has a control dependence from E to S through the backedge.  I
  10899. hope this comment helps to clarify my question...
  10900.  
  10901. Thanks - John
  10902. --
  10903. hagerman@ece.cmu.edu
  10904. -- 
  10905. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10906. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10907.  
  10908.  
  10909. From compilers Thu Apr 22 19:04:39 EDT 1993
  10910. Newsgroups: comp.compilers
  10911. Path: iecc!compilers-sender
  10912. From: krishna@cs.unm.edu (Ksheerabdhi Krishna)
  10913. Subject: Re: Run time optimizations
  10914. Message-ID: <93-04-084@comp.compilers>
  10915. Keywords: optimize
  10916. Sender: compilers-sender@iecc.cambridge.ma.us
  10917. Organization: Computer Science Department, University of New Mexico
  10918. References: <93-04-069@comp.compilers>
  10919. Date: Thu, 22 Apr 1993 15:54:49 GMT
  10920. Approved: compilers@iecc.cambridge.ma.us
  10921.  
  10922. David Keppel, Susan Eggers and Robert Henry have made a convincing case
  10923. for run-time code gen (RTCG) - it was out as a U of Wash, tech. report. I
  10924. cant recall the number, but that might have some references you are
  10925. looking for.
  10926.  
  10927. Partial evaluation is one way of doing some optimizations at compile time
  10928. which might be difficult to do (actually, impossible) at run-time. As
  10929. compilers get better and better, this is a technique that will find its
  10930. way in. A good reference here is a paper by Weise, Ruf, Seligman and
  10931. Conybeare called - "Automatic Online Partial Evaluation" in FPCA 91.
  10932.  
  10933. ksh
  10934. -- 
  10935. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10936. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10937.  
  10938.  
  10939. From compilers Thu Apr 22 19:05:15 EDT 1993
  10940. Newsgroups: comp.compilers
  10941. Path: iecc!compilers-sender
  10942. From: martin@CS.UCLA.EDU (david l. martin)
  10943. Subject: Test suite for C/C++ compilers (?)
  10944. Message-ID: <93-04-085@comp.compilers>
  10945. Keywords: C, testing, question
  10946. Sender: compilers-sender@iecc.cambridge.ma.us
  10947. Organization: UCLA, Computer Science Department
  10948. Date: Thu, 22 Apr 1993 18:05:34 GMT
  10949. Approved: compilers@iecc.cambridge.ma.us
  10950.  
  10951. I need to assemble a set of C and C++ source code to test the
  10952. capabilities of a compiler.  We are solely concerned to verify that it
  10953. correctly identifies the full range of legal constructs (and gives
  10954. reasonable warnings/ errors for questionable/illegal constructs); we
  10955. are NOT concerned with whether it generates fast or compact code.
  10956.  
  10957. Is there any public domain body of code which provides a good test
  10958. suite?
  10959.  
  10960. Any comments or help with this greatly appreciated.
  10961.  
  10962. Thanks.
  10963.  
  10964. - Dave Martin
  10965. - martin@cs.ucla.edu
  10966. -- 
  10967. Send compilers articles to compilers@iecc.cambridge.ma.us or
  10968. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  10969.  
  10970.  
  10971. From compilers Thu Apr 22 19:07:09 EDT 1993
  10972. Newsgroups: comp.compilers
  10973. Path: iecc!compilers-sender
  10974. From: dave@cs.arizona.edu (Dave Schaumann)
  10975. Subject: Re: predicate parsing
  10976. Message-ID: <93-04-086@comp.compilers>
  10977. Keywords: parse, tools
  10978. Sender: compilers-sender@iecc.cambridge.ma.us
  10979. Reply-To: dave@cs.arizona.edu (Dave Schaumann)
  10980. Organization: University of Arizona
  10981. References: <93-04-044@comp.compilers> <93-04-077@comp.compilers>
  10982. Date: Thu, 22 Apr 1993 17:52:36 GMT
  10983. Approved: compilers@iecc.cambridge.ma.us
  10984.  
  10985. tamches@wam (Ariel Meir Tamches) writes:
  10986. >It's hard to imagine how one can insert arbitrary predicates in a
  10987. >bottom-up parser;
  10988.  
  10989. LR parsing is based on running a dfa which recognizes handles of the
  10990. grammar, and issues the appropriate shift, reduce, or accept action on
  10991. each iteration.
  10992.  
  10993. It seems to me that we could augment this model to include test-reduce
  10994. actions to the PDA.  For instance, when you generate the parse tables for
  10995. something like this:
  10996.  
  10997.     var_name  : identifier
  10998.           ;
  10999.     type_name : identifier
  11000.           ;
  11001.  
  11002. a reduce/reduce ambiguity is introduced -- when the parser sees an
  11003. identifier, it doesn't know whether to reduce on the type_name rule or the
  11004. var_name rule.  This is where the test-reduce action would come in.  The
  11005. easiest way to implement this would be to associate a predicate with each
  11006. ambiguous production:
  11007.  
  11008.     var_name  : is_var_name ( identifier )
  11009.           ;
  11010.     type_name : is_type_name( identifier )
  11011.           ;
  11012.  
  11013. Then, when the reduce-test action is encountered, code could be executed
  11014. to test the predicate of each choice in turn, until one succeeded, and
  11015. then reducing on the associated rule.  Notice that we only need to use
  11016. this in the case of ambiguous rules; other rules can be recognized with
  11017. the usual reduce action.
  11018.  
  11019. Of course, faster and more elegant solutions are possible, but I think
  11020. this demonstrates predicates can be practically implemented in an LR
  11021. parser.
  11022.  
  11023. >[...]top-down is the way to go.  People used to (and maybe still do) laugh
  11024. >at LL parsers; after all, LR(k) is a proper superset of LL(k).  But when
  11025. >we consider how easy it is to add predicates and inherited attributes to
  11026. >LL, we see that "conventional wisdom" has been wrong.
  11027.  
  11028. Of course, LL is fine if you can do without left recursion, and you can
  11029. always determine what rule to choose next based on FIRST sets.  In a few
  11030. cases, this is not a problem.  In other cases, it forces you to mutilate
  11031. your grammar to satisfy the needs of the parser.  Certainly, you can use
  11032. the well-known algorithms to do left-factoring, and left-recursion
  11033. removal.  But you are then forced to use a grammar that is a step removed
  11034. from your original choice for each left-factoring, and for each
  11035. left-recursion you must remove.
  11036.  
  11037. >From another angle, consider hacks used by Yacc to get complex
  11038. >(non-LALR(1)) grammars to parse: I'm still trying to decipher the tricks
  11039. >and hacks used in GNU C++ and Jim Roskind's Yacc grammars.
  11040.  
  11041. I think that the problems of the various C++ grammars belong to C++ far
  11042. more than they belong to Yacc or LR parsing.
  11043. --
  11044. Dave Schaumann            dave@cs.arizona.edu
  11045. -- 
  11046. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11047. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11048.  
  11049.  
  11050. From compilers Thu Apr 22 19:11:15 EDT 1993
  11051. Newsgroups: comp.compilers
  11052. Path: iecc!compilers-sender
  11053. From: girkar@kpc.com (Milind Girkar)
  11054. Subject: Re: Control Dependencies for Loops
  11055. Message-ID: <93-04-087@comp.compilers>
  11056. Keywords: analysis, bibliography
  11057. Sender: compilers-sender@iecc.cambridge.ma.us
  11058. Organization: KPC
  11059. References: <93-04-074@comp.compilers>
  11060. Date: Thu, 22 Apr 1993 17:59:45 GMT
  11061. Approved: compilers@iecc.cambridge.ma.us
  11062.  
  11063. hagerman@ece.cmu.edu (John Hagerman) writes:
  11064.   <control dependences due to back edges>
  11065. >If I change the definition so that backedges are not
  11066. >permitted in P, do I shoot myself?
  11067.  
  11068. Something along these lines has been tried in:
  11069.  
  11070. 1. Cytron, R., M. Hind and W. Hsieh Automatic Generation of DAG
  11071. Parallelism, Proc. of 1989 SIGPLAN on Programming Language Design and
  11072. Implementation, July 89, pp 54-68.
  11073.  
  11074. 2. Hsieh, W.  Extracting parallelism from sequential programs, MS thesis,
  11075. Dept of Electrical and Computer Science, MIT, May 1988
  11076.  
  11077. - Milind
  11078. -- 
  11079. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11080. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11081.  
  11082.  
  11083. From compilers Thu Apr 22 19:12:32 EDT 1993
  11084. Newsgroups: comp.compilers
  11085. Path: iecc!compilers-sender
  11086. From: donawa@bluebeard.CS.McGill.CA (Chris DONAWA)
  11087. Subject: Re: IR Transformations
  11088. Message-ID: <93-04-088@comp.compilers>
  11089. Keywords: code
  11090. Sender: compilers-sender@iecc.cambridge.ma.us
  11091. Organization: SOCS, McGill University, Montreal, Canada
  11092. References: <93-04-058@comp.compilers>
  11093. Date: Wed, 21 Apr 1993 14:35:53 GMT
  11094. Approved: compilers@iecc.cambridge.ma.us
  11095.  
  11096. jimy@cae.wisc.edu wrote:
  11097. : Could anyone give me pointers to papers on the subject of IR
  11098. : transformations to suit code generation?
  11099.  
  11100. : More specificaly, suppose we want to generate code for x = 2 * a; The
  11101. : problem is how to know, at the IR level (before code is generated), that
  11102. : the above expression can be rewritten as x = a + a (assuming + is cheaper
  11103. : than *).  The problem is that the above transformation may be context
  11104. : dependent and not always desirable.  In other words, sometimes 2*a may be
  11105. : covered cheaper than a+a, e.g.  by a shift left, which some processors
  11106.  
  11107. For the lower level intermediate representation in our C compiler (the
  11108. McCAT C compiler), we use Bernstein's algorithm for integer
  11109. multiplications with constants.  The work is described in:
  11110.  
  11111. @Article{Bernstein86,
  11112.    Author = "Robert Bernstein",
  11113.    Title = "Multiplication by Integer Constants",
  11114.    Journal = "Software--Practice and Experience",
  11115.    Volume = 16,
  11116.    Number = 7,
  11117.    Pages = "641-652",
  11118.    Month = "July",
  11119.    Year = 1986
  11120. }
  11121.  
  11122. Essentially any integer multiplied by and integer constant can be replaced
  11123. by a series of shift/add/subtraction combinations.  The algorithm tries to
  11124. find the best combination that does not exceed a cost (specified by you,
  11125. ususally the cost of an integer multiply).
  11126.  
  11127. There are some slight typos in the implementation.  Preston Briggs posted
  11128. a corrected version of the algorithm, which formed the basis of our
  11129. converter.  If you'd like I can mail it to interested folks, or make it
  11130. available for ftp.
  11131. --
  11132. Christopher M. Donawa
  11133. Advanced Compilers, Architectures and Parallel Systems Group (ACAPS)
  11134. McGill University, Montreal PQ.
  11135. donawa@cs.mcgill.ca
  11136. -- 
  11137. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11138. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11139.  
  11140.  
  11141. From compilers Thu Apr 22 19:13:03 EDT 1993
  11142. Newsgroups: comp.compilers
  11143. Path: iecc!compilers-sender
  11144. From: Stephen J Bevan <bevan@computer-science.manchester.ac.uk>
  11145. Subject: predicate parsing
  11146. Message-ID: <93-04-089@comp.compilers>
  11147. Keywords: parse, bibliography
  11148. Sender: compilers-sender@iecc.cambridge.ma.us
  11149. Organization: Compilers Central
  11150. References: <93-04-077@comp.compilers>
  11151. Date: Thu, 22 Apr 1993 17:59:56 GMT
  11152. Approved: compilers@iecc.cambridge.ma.us
  11153.  
  11154. Ariel Meir Tamches <tamches@wam.umd.edu> writes:
  11155.    One thing that I haven't seen noted is that it's just about impossible to
  11156.    add predicate parsing to any type of bottom-up parsing engine.
  11157.  
  11158. Watt did further work on affix/attribute directed parsing :-
  11159.  
  11160. author=   D. A. Watt
  11161. title=    Rule Splitting and Attribute-Directed Parsing
  11162. crossref= Jones80
  11163. pages=    363--392
  11164.  
  11165. The following paper in the same proceedings would also seem to be
  11166. relevant :-
  11167.  
  11168. author=   Neil D. Jones and Michael Madsen
  11169. title=    Attribute-Influenced LR Parsing
  11170. crossref= Jones80
  11171. pages=    393--407
  11172.  
  11173. title=     Proceedings of a Workshop on Semantics-Directed Compiler Generation
  11174. year=      1980
  11175. editor=    Neil D. Jones
  11176. publisher= SpringerVerlag
  11177. month=     jan
  11178. note=      LNCS 94
  11179.  
  11180. -- 
  11181. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11182. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11183.  
  11184.  
  11185. From compilers Thu Apr 22 23:00:05 EDT 1993
  11186. Newsgroups: comp.compilers
  11187. Path: iecc!compilers-sender
  11188. From: Jim Reis <reis@sparc0a.cs.uiuc.edu>
  11189. Subject: dataflow analysis in C compilers
  11190. Message-ID: <93-04-090@comp.compilers>
  11191. Keywords: C, optimize, question
  11192. Sender: compilers-sender@iecc.cambridge.ma.us
  11193. Organization: Compilers Central
  11194. Date: Thu, 22 Apr 1993 23:13:09 GMT
  11195. Approved: compilers@iecc.cambridge.ma.us
  11196.  
  11197. I'm trying to find out how sophisticated C compilers are in their dataflow
  11198. analysis; especially in terms of interprocedural and aliasing algorithms.
  11199. Does anyone know the state of the following in available (i.e. not
  11200. research) C compilers ?
  11201.  
  11202.  1) Using an aliasing algorithm for intraprocedural dataflow analysis.
  11203.  
  11204.  2) Interprocedural dataflow analysis.
  11205.  
  11206.  3) Using an aliasing algorithm for interprocedural dataflow analysis.
  11207.  
  11208. Thanks,
  11209.  
  11210. Jim Reis
  11211. reis@cs.uiuc.edu
  11212. -- 
  11213. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11214. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11215.  
  11216.  
  11217. From compilers Thu Apr 22 23:04:07 EDT 1993
  11218. Newsgroups: comp.compilers
  11219. Path: iecc!compilers-sender
  11220. From: pardo@cs.washington.edu (David Keppel)
  11221. Subject: Re: Run time optimizations
  11222. Message-ID: <93-04-091@comp.compilers>
  11223. Keywords: optimize
  11224. Sender: compilers-sender@iecc.cambridge.ma.us
  11225. Organization: Computer Science & Engineering, U. of Washington, Seattle
  11226. References: <93-04-069@comp.compilers>
  11227. Date: Fri, 23 Apr 1993 01:43:57 GMT
  11228. Approved: compilers@iecc.cambridge.ma.us
  11229.  
  11230. In <93-04-069@comp.compilers>
  11231.  
  11232. Sanjay Jinturkar <sj3e@server.cs.virginia.edu> writes:
  11233. >[Generate optimistic and conservative code and do runtime checks?]
  11234.  
  11235. john@iecc.cambridge.ma.us writes:
  11236. >[Or dynamically deoptimize code as the assumptions fail.]
  11237.  
  11238. I know of three general techniques:
  11239.  
  11240. * Statically generate optimistic and conservative code, with runtime tests
  11241. to decide which to use.  Sometimes, checks can be CSE'd to further improve
  11242. performance.  Sometimes the optimized and conservative code are the same
  11243. but e.g, the code must run sequentially to be conservative but can usually
  11244. run in parallel.  Examples: loop unrolling, with a prologue to ``peel''
  11245. off some number of iterations then execute an optimized (unrolled) loop.
  11246. Runtime disambiguation [Nicolau 89], which checks for aliasing then
  11247. branches to the appropriate statically-generated case.  ``Runtime
  11248. compilation'' [Saltz, Berryman & Wu 90], which delays loop scheduling
  11249. until runtime indirection values are known (e.g., x[i] = y[a[i]] +
  11250. z[b[i]], `a' and `b' unknown at compile time) and a schedule is generated
  11251. before the loop body.  Inline the expected common part of a function,
  11252. resorting to function calls for uncommon cases [Chow 88], aka ``shrink
  11253. wrapping''.
  11254.  
  11255. * Look at runtime values and decide how to generate code that is more
  11256. optimized than the general case but still conservative given the runtime
  11257. values.  Examples: Bitblt [Pike, Locanthi & Reiser 85], OS system calls
  11258. [Pu, Massalin & Ioannidis 88], cache simulation [Przybylski, Horowitz &
  11259. Hennessy 88], virtual machines [Deutsch & Schiffman 84], executing
  11260. user-supplied commands [Chamberlin et. al. 81], etc.
  11261.  
  11262. * Generate optimisitic code with runtime checks.  When runtime checks
  11263. fail, regenerate the code.  There are three general approaches here:
  11264. discard the old code and generate code optimized to the new values
  11265. [Johnston79]; generate less-optimized code [Sall & Weiss 79] that may
  11266. still be better-optmized than conservative static code; or cache several
  11267. optimized versions and select between them, generating new versions when
  11268. the cache lookup fails [Holze, Chambers & Ungar 91].
  11269.  
  11270. Time for a plug: Since I'm a leading advocate of runtime code generation,
  11271. I suggest you (everybody!) rush right out and pick up a copy of ``A Case
  11272. for Runtime Code Generation,'' [Keppel, Eggers and Henry 91], available
  11273. via anonymous ftp from `cs.washington.edu' (128.95.1.4) in the tech
  11274. reports subdirectory, number 91-11-04.
  11275.  
  11276.     ;-D on  ( Optimizing for the com onion case )  Pardo
  11277.  
  11278.  
  11279. %A D. D. Chamberlin
  11280. %A M. M. Astrahan
  11281. %A W. F. King
  11282. %A R. Alorie
  11283. %A J. W. Mehl
  11284. %A T. G. Price
  11285. %A M. Schkolnick
  11286. %A P. Griffiths Selinger
  11287. %A D. R. Slutz
  11288. %A B. W. Wade
  11289. %A R. A. Yost
  11290. %T Support for Repetitive Transactions and Ad Hoc Queries in System R
  11291. %J ACM Transactions on Databse Systems
  11292. %V 6
  11293. %N 1
  11294. %D March 1981
  11295. %P 70-94
  11296.  
  11297. %A Fred Chow
  11298. %T Minimizing Register Usage Penalty at Procedure Calls
  11299. %J Sigplan 88 Conference on Programming Language Design and
  11300. Implementation
  11301. %D 1988
  11302. %K shrink wrapping
  11303.  
  11304. %A Peter Deutsch
  11305. %A Alan M. Schiffman
  11306. %T Efficient Implementation of the Smalltalk-80 System
  11307. %J 11th Annual Symposium on Principles of Programming Languages
  11308. (POPL-11)
  11309. %D January 1984
  11310. %P 297-302
  11311.  
  11312. %A Urs Ho\\*:lze
  11313. %A Craig Chambers
  11314. %A David Ungar
  11315. %T Optimizing Dynamically-Typed Object-Oriented Languages With
  11316. Polymorphic Inline Caches
  11317. %R Proceedings of the European Conference on Object-Oriented
  11318. Programming (ECOOP)
  11319. %D July 1991
  11320.  
  11321. %A Ronald L. Johnston
  11322. %T The Dynamic Incremental Compiler of APL\e3000
  11323. %I Association for Computing Machinery (ACM)
  11324. %J APL Quote Quad
  11325. %V 9
  11326. %N 4
  11327. %D June 1979
  11328. %P 82-87
  11329.  
  11330. %A David Keppel
  11331. %A Susan J. Eggers
  11332. %A Robert R. Henry
  11333. %T A Case for Runtime Code Generation
  11334. %R UWCSE 91-11-04
  11335. %I University of Washington Department of Computer Science and
  11336. Engineering
  11337. %D November 1991
  11338.  
  11339. %A Alexandru Nicolau
  11340. %T Run-Time Disambiguation: Coping with Statically Upredictable
  11341. Dependencies
  11342. %J IEEE Transactions on Computers
  11343. %V 38
  11344. %N 5
  11345. %D May 1989
  11346. %P 663-678
  11347.  
  11348. %A Rob Pike
  11349. %A Bart N. Locanthi
  11350. %A John F. Reiser
  11351. %T Hardware/Software Trade-offs for Bitmap Graphics on the Blit
  11352. %J Software - Practice and Experience
  11353. %V 15
  11354. %N 2
  11355. %P 131-151
  11356. %D February 1985
  11357.  
  11358. %A Steven Przybylski
  11359. %A Mark Horowitz
  11360. %A John Hennessy
  11361. %T Performance Tradeoffs in Cache Design
  11362. %J Proceedings of the 15th Annual International Symposium on Computer
  11363. Architecture
  11364. %D May 1988
  11365. %P 290-298
  11366.  
  11367. %A Calton Pu
  11368. %A Henry Massalin
  11369. %A John Ioannidis
  11370. %T The Synthesis Kernel
  11371. %J Computing Systems
  11372. %V 1
  11373. %N 1
  11374. %D Winter 1988
  11375. %P 11-32
  11376.  
  11377. %A H. J. Saal
  11378. %A Z. Weiss
  11379. %T A Software High Performance APL Interpreter
  11380. %J Quote Quad
  11381. %V 9
  11382. %N 4
  11383. %D June 1979
  11384. %P 74-81
  11385.  
  11386. %A Joel Saltz
  11387. %A Harry Berryman
  11388. %A Janet Wu
  11389. %T Multiprocessors and Runtime Compilation
  11390. %J Proceedings of the International Workshop on Compilers for Parallel
  11391. Computers
  11392. %C Paris
  11393. %D December 1990
  11394. -- 
  11395. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11396. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11397.  
  11398.  
  11399. From compilers Fri Apr 23 12:57:15 EDT 1993
  11400. Xref: iecc comp.arch:28277 comp.compilers:4550
  11401. Newsgroups: comp.arch,comp.compilers
  11402. Path: iecc!compilers-sender
  11403. From: markt@harlqn.co.uk (Mark Tillotson)
  11404. Subject: Re: Optimal code sequences for signed int div/rem by powers of 2
  11405. Message-ID: <93-04-092@comp.compilers>
  11406. Keywords: arithmetic, optimize
  11407. Sender: compilers-sender@iecc.cambridge.ma.us
  11408. Organization: Harlequin Limited, Cambridge, England
  11409. References: <93-04-079@comp.compilers>
  11410. Date: Fri, 23 Apr 1993 11:03:40 GMT
  11411. Approved: compilers@iecc.cambridge.ma.us
  11412.  
  11413. S_JUFFA@IRAV1.ira.uka.de (|S| Norbert Juffa) wrote:
  11414.  
  11415. > Therefore, people are looking for alternatives to using division. Fast
  11416. > alternatives are especially feasible if the divisor is known at compile
  11417. > time (e.g. multiplication by reciprocal of divisor). Quite a few posts in
  11418. > the recent discussion were involved with speeding up division by powers of
  11419. > two known at compile time. This is really easy when dealing with unsigned
  11420. > integers (-> shift right), but requires some correction steps for signed
  11421. > integers.
  11422.  
  11423.  
  11424. I think you are perhaps unjustifiably forcing a definition of signed
  11425. integer division at us that is neither mathematically elegant nor what
  11426. people usually want (if they *ever* want signed integer division).  Many
  11427. languages cop out of actually defining a semantics for signed integer
  11428. division anyway!
  11429.  
  11430. I think we all agree that integer division and modulo are related thus:
  11431.        (a / b) * b + (a MOD b)  ==  a
  11432.  
  11433. This by itself is under-constrained, but the simplest most elegant way to
  11434. constrain it is to limit the values of (a MOD b) to a contiguous range of
  11435. b distinct values (usually 0 .. b-1)
  11436.  
  11437. To do otherwise makes correctness proofs more complex, makes it easier to
  11438. introduce bugs.  I see it as a failing in a language to constrain the
  11439. semantics to disallow this definition.  If you feel strongly that
  11440. a/b == -(-a/b) then you are automatically saying that
  11441.  
  11442. (a+nb) MOD b  /= a MOD b
  11443.  
  11444. which is very counter-intuitive to me!!
  11445.  
  11446. M. Tillotson       Harlequin Ltd.
  11447. markt@uk.co.harlqn  Barrington Hall,
  11448. +44 223 872522       Barrington, Cambridge CB2 5RG
  11449. -- 
  11450. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11451. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11452.  
  11453.  
  11454. From compilers Fri Apr 23 12:58:05 EDT 1993
  11455. Newsgroups: comp.compilers
  11456. Path: iecc!compilers-sender
  11457. From: isckbk@nuscc.nus.sg (Kiong Beng Kee)
  11458. Subject: Re: predicate parsing
  11459. Message-ID: <93-04-093@comp.compilers>
  11460. Keywords: LALR, parse
  11461. Sender: compilers-sender@iecc.cambridge.ma.us
  11462. Organization: National University of Singapore
  11463. References: <93-04-077@comp.compilers>
  11464. Date: Fri, 23 Apr 1993 13:36:32 GMT
  11465. Approved: compilers@iecc.cambridge.ma.us
  11466.  
  11467. tamches@wam.umd.edu (Ariel Meir Tamches) writes:
  11468. : It's hard to imagine how one can insert arbitrary predicates in a
  11469. : bottom-up parser; for the same reason it's hard for bottom-up parsers to
  11470. : have inherited attributes - their control flow is "screwy" - top-down is
  11471.  
  11472. The predicates used in LADE are called 'conditionals'.  Since bottom-up
  11473. parsing is happy to accomodate more than one possibility, it does not need
  11474. predicates to tell it which nonterminal to predict.  However, it uses
  11475. conditionals to dynamically resolve shift-reduce and reduce-reduce
  11476. conflicts (rather than rules at table generation time as in YACC).
  11477.  
  11478. Inherited attributes in LADE is somewhat implicit, and quite equivalent to
  11479. global variables with (invisible) mechanisms for saving and restoring such
  11480. values.  It gets the job done efficiently, and is better than in YACC, but
  11481. maybe not as nicely as in a top-down parser.
  11482.  
  11483. Compared with a top-down approach, I suspect that the LADE approach
  11484. requires fewer predicates.
  11485. --
  11486. Kiong Beng Kee
  11487. Dept of Information Systems and Computer Science
  11488. National University of Singapore
  11489. Lower Kent Ridge Road, SINGAPORE 0511
  11490. -- 
  11491. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11492. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11493.  
  11494.  
  11495. From compilers Fri Apr 23 17:11:54 EDT 1993
  11496. Newsgroups: comp.compilers
  11497. Path: iecc!compilers-sender
  11498. From: jim@float.co.uk (James Cownie)
  11499. Subject: Re: Run time optimizations
  11500. Message-ID: <93-04-094@comp.compilers>
  11501. Keywords: optimize, vector
  11502. Sender: compilers-sender@iecc.cambridge.ma.us
  11503. Organization: Meiko World.
  11504. References: <93-04-069@comp.compilers>
  11505. Date: Fri, 23 Apr 1993 20:51:26 GMT
  11506. Approved: compilers@iecc.cambridge.ma.us
  11507.  
  11508. The technique of generating multiple posible implementations of a
  11509. particular piece of source, and then choosing the correct one at run time
  11510. based on the actual circumstances present at the time is fairly standard
  11511. in high performance vectorising compilers. These often generate both
  11512. vector and scalar code and then choose which to use based on the loop
  11513. length at run time. The technique is also used to allow vectorisation of
  11514. operations which may have a data dependancy for some values of a variable,
  11515. but not for others e.g.
  11516.  
  11517.     do i = 2,10
  11518.        a(i+j) = a(i)+1
  11519.     end do
  11520.  
  11521. which certainly vectorises if j <= 0 or j >= 9 but does not for 1 <= j <= 8
  11522.  
  11523. -- Jim
  11524. James Cownie
  11525. Meiko Limited, 650 Aztec West, Bristol BS12 4SD, England
  11526. Meiko Inc., Reservoir Place, 1601 Trapelo Road, Waltham MA 02154
  11527. Phone : +44 454 616171 or +1 617 890 7676
  11528. FAX   : +44 454 618188 or +1 617 890 5042
  11529. E-Mail: jim@meiko.co.uk   or    jim@meiko.com
  11530. -- 
  11531. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11532. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11533.  
  11534.  
  11535. From compilers Fri Apr 23 17:13:10 EDT 1993
  11536. Xref: iecc comp.compilers:4553 comp.lang.lisp:7322 comp.lang.misc:9758 comp.lang.prolog:5390 comp.lang.smalltalk:5661 comp.lang.scheme:5574 comp.lang.icon:844 comp.lang.apl:2225
  11537. Newsgroups: comp.compilers,comp.lang.lisp,comp.lang.misc,comp.lang.prolog,comp.lang.smalltalk,comp.lang.scheme,comp.lang.icon,comp.lang.apl
  11538. Path: iecc!compilers-sender
  11539. From: gudeman@cs.arizona.edu (David Gudeman)
  11540. Subject: Representations of Dynamic Type Information
  11541. Message-ID: <93-04-095@comp.compilers>
  11542. Keywords: question, types
  11543. Sender: compilers-sender@iecc.cambridge.ma.us
  11544. Organization: U of Arizona CS Dept, Tucson
  11545. Date: Fri, 23 Apr 1993 21:04:06 GMT
  11546. Approved: compilers@iecc.cambridge.ma.us
  11547.  
  11548. I'm preparing a document that is intended to be an encyclopedic summary
  11549. of all of the different ways of encoding the type of a value in
  11550. dynamically typed languages.  In order to make this list as comprehensive
  11551. as possible, I thought I'd post to some relevant groups on the net to see
  11552. if anyone has a technique I'm not aware of.  Instead of asking for
  11553. techniques and having to go through all of the responses looking for new
  11554. ones, I thought I'd list the ones I know about and hope that some
  11555. implementers will be willing to go through my list looking for their own
  11556. favorite technique, and let me know if it is missing.  Also, many of these
  11557. techniques are either folk-lore, or (probably re-)invented by me, so I
  11558. would appreciate knowing if anyone can give me references that have some
  11559. claim to originiality.
  11560.  
  11561. I don't need to know about cdr-coding or other methods to represent data,
  11562. I'm only interested in methods to encode dynamic type information.
  11563.  
  11564. If you can help I prefer to get replies by mail.  If you post a follow-up
  11565. to this article, please notice that there are a lot of groups in the
  11566. subject line, and some replies may not be relevant for some groups (I
  11567. recommend comp.lang.misc for general discussions of representational
  11568. schemes).
  11569.  
  11570. Any and all help is greatly appreciated.
  11571.  
  11572. The LIST:
  11573.  
  11574. tagged-words (type information is in the machine word)
  11575.   tag fields (word is broken up into tag and data fields)
  11576.     tag field in high end (most-significant bits) of word
  11577.        use tag of all zeros for one type to avoid tagging cost
  11578.        negative ints get a tag of all ones, non-negative ints
  11579.                                   get a tag of all zeros
  11580.        use sign bit for one type
  11581.          use sign-bit = 0 for one type and optimize another type by
  11582.                                   giving it the tag of all ones in the
  11583.                                   high end and tagging by negation.
  11584.     tag field in low end of word
  11585.       use two-bit tags to represent word pointers to avoid shifting
  11586.         use the tag 00 for word pointers to save the cost of tagging
  11587.       use all zeros to optimize integer arithmetic
  11588.       optimize integer arithmetic by adding/subtracting tag
  11589.                                   after subtraction/addition
  11590.     tag field in both ends of word
  11591.        various combinations of tricks from the other two options
  11592.   partitioning by magnitude (type is encoded in the magnitude
  11593.                              of the word used to represent it)
  11594.     simple range tests to identify types
  11595.     segments with statically determined types
  11596.     segments with dynamically determined types
  11597.       use BIBOP to identify types
  11598.       identify type in the segment itself
  11599.         first word of segment
  11600.         last word of segment
  11601. object-pointers (untagged pointers refering to self-identifying blocks
  11602.                  on the heap)
  11603.   combinations of this scheme with the tagged-word scheme
  11604. descriptors (two-word data elements divided into a type word and a
  11605.              value word)
  11606.   encoding a qualifier in a descriptor
  11607.   encoding a cons cell in a descriptor
  11608. --
  11609. David Gudeman
  11610. gudeman@cs.arizona.edu
  11611. -- 
  11612. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11613. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11614.  
  11615.  
  11616. From compilers Sat Apr 24 11:43:44 EDT 1993
  11617. Newsgroups: comp.compilers
  11618. Path: iecc!compilers-sender
  11619. From: haahr@mv.us.adobe.com (Paul Haahr)
  11620. Subject: Re: Run time optimizations
  11621. Message-ID: <93-04-096@comp.compilers>
  11622. Keywords: optimize, architecture
  11623. Sender: compilers-sender@iecc.cambridge.ma.us
  11624. Organization: Compilers Central
  11625. References: <93-04-069@comp.compilers> <93-04-091@comp.compilers>
  11626. Date: Sat, 24 Apr 1993 03:18:33 GMT
  11627. Approved: compilers@iecc.cambridge.ma.us
  11628.  
  11629. David Keppel <pardo@cs.washington.edu> writes:
  11630. > * Look at runtime values and decide how to generate code that is more
  11631. > optimized than the general case but still conservative given the runtime
  11632. > values.  Examples: Bitblt [Pike, Locanthi & Reiser 85]
  11633.  
  11634. One data point here: i had written, back when i was in school, a 680n0 (n
  11635. >= 2) compile-on-the-fly bitblt.  It ran at (roughly) memory bandwidth on
  11636. my 68020-based sun3/60, and generally moved 3-5x as many bits per second
  11637. as an ``interpretive'' bitblt.  I was pretty pleased with this code.  ;-)
  11638.  
  11639. I recently compiled it and timed on on my 68040-based nextstation.
  11640. the compile-on-the-fly version and the interpretive version ran
  11641. in the same amount of time, reproducible within 10%.  In some cases,
  11642. the compiling bitblt was faster, in others it was slower, seemingly
  11643. due to the i-cache flushing that was going on before jumping into
  11644. the actual copying routine.
  11645.  
  11646. My explanations for what's going on, which are all in the form of
  11647. first impressions and could easily be completely mistaken, are:
  11648.  
  11649.     + The 68040 outruns the memory by a lot.  No matter how much
  11650.       other work you do in bitblt, performance is most directly
  11651.       related to memory bandwidth and you have cycles to spare.
  11652.  
  11653.     + The 68040 is (internally) clock-doubled, so you already
  11654.       have twice as many instruction cycles as you have chances
  11655.       to get at the memory buses.  That means that a loop with
  11656.       two memory references that are not coming out of cache can
  11657.       effectively have two other completely ``free'' instructions.
  11658.       This makes loop-unrolling, one of the prime advantages of
  11659.       the compile-on-the-fly code, much less important.
  11660.  
  11661.     + There's much more of a penalty on the 68040 for flushing
  11662.       the icache:  the cache is an order of magnitude larger and
  11663.       almost certainly has useful code from outside the bitblt
  11664.       in it, not to mention advantages stemming from repeated
  11665.       bitblts being cached.
  11666.  
  11667.     + The icache is bigger, so you don't need the incredibly
  11668.       density of the compile-on-the-fly code to keep the entire
  11669.       inner loop in cache.  (In fact, I suspect that the inner
  11670.       loop typically fits entirely in the 68020s 256 byte icache,
  11671.       but i'm note sure.)
  11672.  
  11673. Anyway, I don't want to disparage the approach of run-time code
  11674. generation, but do want to remind people that as hardware changes,
  11675. engineering trade-offs change.
  11676.  
  11677. paul
  11678. -- 
  11679. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11680. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11681.  
  11682.  
  11683. From compilers Sat Apr 24 14:14:45 EDT 1993
  11684. Xref: iecc comp.compilers:4555 comp.unix.ultrix:17442
  11685. Newsgroups: comp.compilers,comp.unix.ultrix
  11686. Path: iecc!compilers-sender
  11687. From: raynor@cs.scarolina.edu (Harold Brian Raynor)
  11688. Subject: How to force gcc to dump core on FP error
  11689. Message-ID: <93-04-097@comp.compilers>
  11690. Summary: How can I make GCC coredump on FP error
  11691. Keywords: GCC, debug, question
  11692. Sender: compilers-sender@iecc.cambridge.ma.us
  11693. Organization: USC  Department of Computer Science
  11694. Date: Sat, 24 Apr 1993 17:27:16 GMT
  11695. Approved: compilers@iecc.cambridge.ma.us
  11696.  
  11697. Is there any compiler switch that will force either GCC or the MIPS C
  11698. compiler (supplied with Ultrix) to coredump when a floating point error
  11699. occurs?
  11700.  
  11701. I am writing a 3D Graphics package and at the moment am having a lot of
  11702. things calculated to be Infinity or Nan.  This should never happen in the
  11703. program.
  11704.  
  11705. Without dissecting every line of code with a debugger (or putting a TON of
  11706. printfs), it would be nice if I could just get a core dump whenever this
  11707. happened.  Then I would know exactly where it occured.  It does this with
  11708. integer divide by zeros, etc.  There outta be a way to do it with FP (all
  11709. are floats, no doubles).
  11710.  
  11711. I am using a DECstation 2100 (believe it is MIPS 2000).
  11712.  
  11713. Any help would be greatly appreciated...
  11714.  
  11715. Thanks,
  11716. Brian Raynor
  11717. -- 
  11718. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11719. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11720.  
  11721.  
  11722. From compilers Mon Apr 26 12:51:52 EDT 1993
  11723. Newsgroups: comp.compilers
  11724. Path: iecc!compilers-sender
  11725. From: Mark_Kuschnir@gec-epl.co.uk
  11726. Subject: C Preprocessor
  11727. Message-ID: <93-04-098@comp.compilers>
  11728. Keywords: C, parse, question
  11729. Sender: compilers-sender@iecc.cambridge.ma.us
  11730. Organization: Compilers Central
  11731. Date: Mon, 26 Apr 1993 08:10:54 GMT
  11732. Approved: compilers@iecc.cambridge.ma.us
  11733.  
  11734. Is it more usual to concatenate adjacent string literals in the
  11735. preprocessing pass or afterwards ?
  11736. -- 
  11737. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11738. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11739.  
  11740.  
  11741. From compilers Mon Apr 26 12:59:03 EDT 1993
  11742. Newsgroups: comp.compilers
  11743. Path: iecc!compilers-sender
  11744. From: simonh@swidev.demon.co.uk (Simon Huntington)
  11745. Subject: Re: predicate parsing
  11746. Message-ID: <93-04-099@comp.compilers>
  11747. Keywords: parse
  11748. Sender: compilers-sender@iecc.cambridge.ma.us
  11749. Reply-To: simonh@swidev.demon.co.uk
  11750. Organization: SoftWare Interrupt Developments
  11751. References: <93-04-077@comp.compilers>
  11752. Date: Fri, 23 Apr 1993 15:27:51 GMT
  11753. Approved: compilers@iecc.cambridge.ma.us
  11754.  
  11755. Re regarding predicate parsing:
  11756.  
  11757. What exactly are predicates? I've had a look at the *excellent* PCCTS
  11758. which uses predicates, but I don't see how they can help very much. I'm
  11759. trying to write a C++ parser (something simple to start with :-)), but
  11760. predicate parsing would have to look-ahead many tokens to decipher
  11761. ambiguities wouldn't it?
  11762.  
  11763. I wrote a backtracking LALR parser which basically recursively 'trial'
  11764. parses (similar method to Gary Merrill, but trial parsing is specified
  11765. with the grammar). I've managed to get it to parse almost all C++,
  11766. including templates and exceptions, but it's pretty big (>950states). I
  11767. also needed error repair which is why I **had** to write my own parser.
  11768.  
  11769. I'd have liked to use LL since it is much easier to understand but seemed
  11770. to run into so many problems. Firstly, I wanted it to be as fast as
  11771. possible. I can write the parser driver in assembler to read the tables.
  11772. Second, I needed error repair. LL parsers seem to have a hard-time
  11773. repairing errors. Thirdly, I couldn't parse-out those lovely ambiguities
  11774. in C++ :-).
  11775.  
  11776.  
  11777. .. So, would predicates help or what? Are they for simpler things?
  11778.  
  11779.  
  11780. --
  11781. James Huntington
  11782. Software Interrupt Developments, Leeds, UK.
  11783. -- 
  11784. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11785. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11786.  
  11787.  
  11788. From compilers Mon Apr 26 13:00:06 EDT 1993
  11789. Xref: iecc comp.unix.wizards:14952 comp.sys.sun.misc:7878 comp.compilers:4558
  11790. Newsgroups: comp.unix.wizards,comp.sys.sun.misc,comp.compilers
  11791. Path: iecc!compilers-sender
  11792. From: troy@molson.ho.att.com
  11793. Subject: Finding the return address in a Sparc stack frame
  11794. Message-ID: <93-04-100@comp.compilers>
  11795. Followup-To: comp.unix.wizards
  11796. Keywords: sparc, debug
  11797. Sender: compilers-sender@iecc.cambridge.ma.us
  11798. Organization: AT&T Bell Laboratories, Holmdel NJ
  11799. Date: Mon, 26 Apr 1993 15:31:50 GMT
  11800. Approved: compilers@iecc.cambridge.ma.us
  11801.  
  11802. Hi,
  11803.  
  11804. I'm trying to hack a debugging version of malloc that tracks who
  11805. called it for each piece of memory doled out.  To determine who
  11806. called it, I want to figure out the return address by following
  11807. the argument's address to the stack frame.
  11808.  
  11809. My starting point is a version that runs on 386's and 3B2's,
  11810. which has the following unstructured hack.  "nbytes" is the
  11811. argument to malloc.
  11812.  
  11813.     #ifdef debug
  11814.         /* reuse nextfree as pointer to caller */
  11815.         struct header **argptr = (struct header **)&nbytes;
  11816.     #if defined(i386)
  11817.         blk->nextfree = *(argptr-1);
  11818.     #else
  11819.         blk->nextfree = *(argptr+1);    /*u3b2*/
  11820.     #endif
  11821.     #endif
  11822.  
  11823. I'm having trouble interpreting the Sparc stack frame.  I've examined
  11824. stack frames using gdb and the structure found in /usr/include/frame.h
  11825. (below), but can't find anything that looks correct in fr_savpc.
  11826.  
  11827.     struct frame {
  11828.         int     fr_local[8];            /* saved locals */
  11829.         int     fr_arg[6];              /* saved arguments [0 - 5] */
  11830.         struct frame    *fr_savfp;      /* saved frame pointer */
  11831.         int     fr_savpc;               /* saved program counter */
  11832.         char    *fr_stret;              /* struct return addr */
  11833.         int     fr_argd[6];             /* arg dump area */
  11834.         int     fr_argx[1];             /* array of args past the 6th*/
  11835.     };
  11836.  
  11837. I also could not decipher the gdb source.  I'm guessing that there is
  11838. some indirection at some level that I'm missing.  I've seen references
  11839. to "stack windows", but I've yet to find a detailed explanation.
  11840.  
  11841. Any help with this problem would be appreciated.
  11842.  
  11843. -troy
  11844. troy@molson.ho.att.com
  11845. -- 
  11846. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11847. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11848.  
  11849.  
  11850. From compilers Tue Apr 27 16:46:57 EDT 1993
  11851. Newsgroups: comp.compilers
  11852. Path: iecc!compilers-sender
  11853. From: mauney@csljon.csl.ncsu.edu (Jon Mauney)
  11854. Subject: Re: predicate parsing
  11855. Message-ID: <93-04-101@comp.compilers>
  11856. Keywords: parse
  11857. Sender: compilers-sender@iecc.cambridge.ma.us
  11858. Organization: NCSU
  11859. References: <93-04-077@comp.compilers> <93-04-099@comp.compilers>
  11860. Date: Tue, 27 Apr 1993 03:43:47 GMT
  11861. Approved: compilers@iecc.cambridge.ma.us
  11862.  
  11863. simonh@swidev.demon.co.uk (Simon Huntington) writes:
  11864. >I'd have liked to use LL since it is much easier to understand but seemed
  11865. >to run into so many problems. Firstly, I wanted it to be as fast as
  11866. >possible. I can write the parser driver in assembler to read the tables.
  11867. >Second, I needed error repair. LL parsers seem to have a hard-time
  11868. >repairing errors. Thirdly, I couldn't parse-out those lovely ambiguities
  11869. >in C++ :-).
  11870.  
  11871. Can't let this go by without comment.
  11872. A) LL parsers can be as fast as anything else.
  11873. 2) LL Parsers are to be *preferred* when repair is an issue.
  11874.   The simple structure of the data on the stacks makes life
  11875.   much easier.
  11876.  
  11877. I'm not going to stick my neck out on III, however.
  11878. --
  11879. Jon Mauney                   mauney@csc.ncsu.edu
  11880. Mauney Computer Consulting   (919)828-8053
  11881. -- 
  11882. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11883. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11884.  
  11885.  
  11886. From compilers Wed Apr 28 12:40:36 EDT 1993
  11887. Newsgroups: comp.compilers
  11888. Path: iecc!compilers-sender
  11889. From: jeremy@sw.oz.au (Jeremy Fitzhardinge)
  11890. Subject: Re: Run time optimizations
  11891. Message-ID: <93-04-102@comp.compilers>
  11892. Keywords: optimize, architecture
  11893. Sender: compilers-sender@iecc.cambridge.ma.us
  11894. Organization: Softway Pty Ltd
  11895. References: <93-04-069@comp.compilers> <93-04-096@comp.compilers>
  11896. Date: Wed, 28 Apr 1993 11:23:27 GMT
  11897. Approved: compilers@iecc.cambridge.ma.us
  11898.  
  11899. haahr@mv.us.adobe.com (Paul Haahr) writes:
  11900. >[runtime code gen for bitblt was a win on the 68020, no better than
  11901. >interpreted on 68040, probably due to cache effects]
  11902. >Anyway, I don't want to disparage the approach of run-time code
  11903. >generation, but do want to remind people that as hardware changes,
  11904. >engineering trade-offs change.
  11905.  
  11906. Good points.  However, it does depend on what you are generating code for.
  11907. I spend quite a lot of time playing with Byron Rakitzis' pico
  11908. implementation, in particular an optimiser pass.
  11909.  
  11910. Pico was originally written at Bell Labs.  It took as input a C-like
  11911. language that describes a set of transformations to be performed on an
  11912. image.  Transformations can involve simple arithmatic, logical ops, polar
  11913. or rectangular coords, trig operations, conditionals, etc.  It compiled
  11914. the user input into native machine code and ran it.  The Bell
  11915. implementation generated Vax and WD32000 code I think; Byron's more
  11916. limited implementation generates Sparc and Mips code.
  11917.  
  11918. Byron's original code was a literal translation into assembly with no
  11919. attempt at optimisation.  I added strength reduction, constant folding,
  11920. loop invarient motion and simple peephole optimisation.  After I'd
  11921. finished, there was no way an interpretive version was going to get within
  11922. an order of magnitude of the compiled code on a Sparc Station 1.  There
  11923. was all the same sort of tradeoffs as your case, but because there were at
  11924. least 512x512 operations (for that sized image) there was a high payoff
  11925. for reducing loop overhead, as well as operation time per pixel.
  11926.  
  11927. For blit-type operations, there are relatively few variations, so it can
  11928. pay just to have one function per operation, each of which encompasses all
  11929. the loops.  Pico, by its nature, can't do that, so either you interpret
  11930. the user input or compile it.  The runtime compiler code is not as good
  11931. as, say, gcc, but it generates quickly and its results are always going to
  11932. be faster than a gcc-compiled interpreter.  (Just to blur the distinction,
  11933. I added a "portable option" that would generate C source as output, and
  11934. pass it to gcc, then map the resulting .o into the address space and run
  11935. it.  This would have worked modulo bugs in Sun's runtime linking
  11936. routines.)
  11937.  
  11938. In conclusion, runtime code generation pays off when there are too many
  11939. possibilities at runtime to encode into the compiled source.
  11940.  
  11941.     J
  11942. -- 
  11943. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11944. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11945.  
  11946.  
  11947. From compilers Thu Apr 29 01:53:15 EDT 1993
  11948. Newsgroups: comp.compilers
  11949. Path: iecc!compilers-sender
  11950. From: hadad@cs.uh.edu (Ben S. Hadad)
  11951. Subject: automata book recommendations wanted
  11952. Message-ID: <93-04-103@comp.compilers>
  11953. Keywords: books, theory, question
  11954. Sender: compilers-sender@iecc.cambridge.ma.us
  11955. Organization: Computer Science dept.,  Univ. of Houston (Main Campus)
  11956. Date: Wed, 28 Apr 1993 17:01:33 GMT
  11957. Approved: compilers@iecc.cambridge.ma.us
  11958.  
  11959. Folk:
  11960.    I am looking for a book on Automata Theory as part of a
  11961. self-study program in preparation for the Computer Science
  11962. section of the GRE.  I already have the excellent book by
  11963. Hopcroft and Ullman, "Intro to Automata Theory, Languages, and
  11964. Computation", which I find admirable in its rigor and
  11965. thoroughness, but a bit short on solved problems.  Any other
  11966. introductory texts out there that you folk can recommend?  If
  11967. you'd e-mail me with your answer, I'll post a summary when the
  11968. answers stop coming in.
  11969.  
  11970.    Thanks in advance for the advice.
  11971.  
  11972.    Yours,
  11973.  
  11974.    Ben Hadad, aka
  11975.    hadad@cs.uh.edu
  11976. -- 
  11977. Send compilers articles to compilers@iecc.cambridge.ma.us or
  11978. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  11979.  
  11980.  
  11981. From compilers Thu Apr 29 01:55:44 EDT 1993
  11982. Newsgroups: comp.compilers
  11983. Path: iecc!compilers-sender
  11984. From: isckbk@nuscc.nus.sg (Kiong Beng Kee)
  11985. Subject: Re: predicate parsing
  11986. Message-ID: <93-04-104@comp.compilers>
  11987. Keywords: parse
  11988. Sender: compilers-sender@iecc.cambridge.ma.us
  11989. Organization: National University of Singapore
  11990. References: <93-04-099@comp.compilers>
  11991. Date: Wed, 28 Apr 1993 18:43:27 GMT
  11992. Approved: compilers@iecc.cambridge.ma.us
  11993.  
  11994. simonh@swidev.demon.co.uk (Simon Huntington) writes:
  11995. : What exactly are predicates? I've had a look at the *excellent* PCCTS
  11996. : which uses predicates, but I don't see how they can help very much. I'm
  11997. : trying to write a C++ parser (something simple to start with :-)), but
  11998. : predicate parsing would have to look-ahead many tokens to decipher
  11999. : ambiguities wouldn't it?
  12000.  
  12001. I see predicates as being used to help the parser resolve ambiguites.  In
  12002. top-down parsing, it points out the path to take for rules with common
  12003. prefixes.  A multi-token lookahead could be one way; semantic attributes
  12004. is another.
  12005.  
  12006. In bottom-up parsing, these predicates point out which reduction to take
  12007. (when there is a reduce-reduce conflict) or whether to reduce at all (when
  12008. there is a shift-reduce conflict).
  12009.  
  12010. Intuitively, one needs fewer and simplier(?) predicates in bottom- up
  12011. parsing because these are invoked later in the case of bottom-up parsing
  12012. when the context is better known; rather than the top-down case when it
  12013. must guide the parser.
  12014.  
  12015. : I wrote a backtracking LALR parser which basically recursively 'trial'
  12016. : parses (similar method to Gary Merrill, but trial parsing is specified
  12017. : with the grammar). I've managed to get it to parse almost all C++,
  12018. : including templates and exceptions, but it's pretty big (>950states). I
  12019. : also needed error repair which is why I **had** to write my own parser.
  12020.  
  12021. I know that xorian@solomon.technet.sg has a C++ parser, and I heard it is
  12022. small.  However, I do not know how many states.  They also incorporate the
  12023. FMQ method of error repair into the parser generation process, but I think
  12024. the FMQ method for bottom-up parsing (as in Fischer's book) is somewhat
  12025. less clever than the one for top-down parsing.  Top-down parsing always
  12026. have the benefit when it comes to error-repair since the parsing context
  12027. is already on the stack.  The same cannot be said for bottom-up parsing --
  12028. so I do not see how LL parsers are disadvantaged in error repair.
  12029. --
  12030. Kiong Beng Kee
  12031. Dept of Information Systems and Computer Science
  12032. National University of Singapore
  12033. Lower Kent Ridge Road, SINGAPORE 0511
  12034. -- 
  12035. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12036. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12037.  
  12038.  
  12039. From compilers Thu Apr 29 01:56:21 EDT 1993
  12040. Newsgroups: comp.compilers
  12041. Path: iecc!compilers-sender
  12042. From: max@nic.gac.edu (Max Hailperin)
  12043. Subject: test at top ==> test at bottom
  12044. Message-ID: <93-04-105@comp.compilers>
  12045. Keywords: optimize, question
  12046. Sender: compilers-sender@iecc.cambridge.ma.us
  12047. Reply-To: Max Hailperin <max@nic.gac.edu>
  12048. Organization: Gustavus Adolphus College, St. Peter, MN
  12049. Date: Wed, 28 Apr 1993 19:15:10 GMT
  12050. Approved: compilers@iecc.cambridge.ma.us
  12051.  
  12052. While working my way through the literature on certain forms of loop
  12053. optimization, it occurred to me that I haven't seen much in the literature
  12054. on transformations that will turn test-at-the-top loops into
  12055. test-at-the-bottom loops.  Yet unless you've done so, you can't safely
  12056. assume the loop will be done at least once.
  12057.  
  12058. I know some compilers may leave the loop structurally alone but prove
  12059. separately that it is done at least once, or may move some invariants out
  12060. of loops even without being sure that the loop is done at least once.
  12061. These aren't the approaches I'm interested in.
  12062.  
  12063. What I *am* interested in is approaches that literally transform the
  12064. structure of the loop.  The basic approach seems to be to make two copies
  12065. of the test block (one for when the loop is initially entered, one for
  12066. subsequent iterations) and then try to optimize away the copy that is done
  12067. on the first iteration.  This description leaves open all sorts of
  12068. questions about how to efficiently do it and how to avoid doing it where
  12069. it would involve replicating lots of code.
  12070.  
  12071. If you know of any good material on this topic, would you be so kind as to
  12072. send me a citation?
  12073.  
  12074. Thanks.
  12075. -- 
  12076. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12077. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12078.  
  12079.  
  12080. From compilers Thu Apr 29 01:56:59 EDT 1993
  12081. Newsgroups: comp.compilers
  12082. Path: iecc!compilers-sender
  12083. From: wendt@CS.ColoState.EDU (alan l wendt)
  12084. Subject: Chop Available for FTP
  12085. Message-ID: <93-04-106@comp.compilers>
  12086. Keywords: code, FTP, available
  12087. Sender: compilers-sender@iecc.cambridge.ma.us
  12088. Organization: Colorado State University, Computer Science Department
  12089. Date: Wed, 28 Apr 1993 20:42:17 GMT
  12090. Approved: compilers@iecc.cambridge.ma.us
  12091.  
  12092. The source code for the chop fast automatically-generated code generator
  12093. system is now available for anonymous ftp.  Chop is described in "Fast
  12094. Code Generation Using Automatically-Generated Decision Trees", ACM SIGPLAN
  12095. '90 PLDI, and other publications cited there.
  12096.  
  12097. The current revision, 0.6, is interfaced with Fraser and Hanson's lcc
  12098. front end.  The result is a highly fast C compiler with good code
  12099. selection and no global optimization.
  12100.  
  12101. Project Status: Chop compiles and runs a number of small test programs on
  12102. the Vax.  I'm currently updating the NS32k and 68K retargets for lcc
  12103. compatibility.  After I get them working, I'll work on getting the system
  12104. to compile itself, get struct assignments working, improve the code
  12105. quality and compile speed, and run the SPEC benchmarks.  That will be rev
  12106. 1.0.  This is rev 0.6.
  12107.  
  12108. Rev 0.6 is available by ftp from beethoven.cs.colostate.edu.  Download the
  12109. file "~ftp/pub/chop/0.6.tar.Z.
  12110.  
  12111. Alan Wendt
  12112. -- 
  12113. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12114. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12115.  
  12116.  
  12117. From compilers Thu Apr 29 01:58:01 EDT 1993
  12118. Newsgroups: comp.compilers
  12119. Path: iecc!compilers-sender
  12120. From: Trevor Jenkins <tfj@apusapus.demon.co.uk>
  12121. Subject: predicate parsing
  12122. Message-ID: <93-04-107@comp.compilers>
  12123. Keywords: parse
  12124. Sender: compilers-sender@iecc.cambridge.ma.us
  12125. Organization: Job hunters use Parachute
  12126. References: <93-04-101@comp.compilers>
  12127. Date: Wed, 28 Apr 1993 22:43:28 GMT
  12128. Approved: compilers@iecc.cambridge.ma.us
  12129.  
  12130. mauney@csljon.csl.ncsu.edu writes:
  12131. > A) LL parsers can be as fast as anything else.
  12132.  
  12133. Indeed Fraser and ? at Bell Labs wrote a recursive descent (LL(1)) based
  12134. parser for their new C compiler. (from memory) They said "LALR parsers (ie
  12135. yacc generated ones) are too slow".
  12136.  
  12137. > 2) LL Parsers are to be *preferred* when repair is an issue.
  12138. >   The simple structure of the data on the stacks makes life
  12139. >   much easier.
  12140.  
  12141. It is generally acknowledged that in an LR based parser error recovery is
  12142. real messy. As to the data on the stack that has nothing to do with the
  12143. error recovery procedure of either LL or LR parsers.
  12144.  
  12145. > I'm not going to stick my neck out on III, however.
  12146.  
  12147. I'm not a C++ theologian but both of you seem to be confusing language
  12148. with grammar. Just because a language is described by an *LR(1) grammar
  12149. soes not necessarily mean that it the LANGUAGE is not LL(1). If it can be
  12150. described by an LL(1) grammar but the langauge designer decides to publish
  12151. a grammar in the LR family that is there choice but does not restict an
  12152. implementation to using that grammar form.
  12153.  
  12154. Regards, Trevor.
  12155. --
  12156. Trevor Jenkins
  12157. 134 Frankland Rd, Croxley Green, RICKMANSWORTH, WD3 3AU, England
  12158. email: tfj@apusapus.demon.co.uk   phone: +44 (0)923 776436     radio: G6AJG
  12159. -- 
  12160. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12161. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12162.  
  12163.  
  12164. From compilers Thu Apr 29 23:39:00 EDT 1993
  12165. Newsgroups: comp.compilers
  12166. Path: iecc!compilers-sender
  12167. From: mauney@csljon.csl.ncsu.edu (Jon Mauney)
  12168. Subject: Re: predicate parsing
  12169. Message-ID: <93-04-108@comp.compilers>
  12170. Keywords: parse
  12171. Sender: compilers-sender@iecc.cambridge.ma.us
  12172. Organization: NCSU
  12173. References: <93-04-101@comp.compilers> <93-04-107@comp.compilers>
  12174. Date: Thu, 29 Apr 1993 12:59:05 GMT
  12175. Approved: compilers@iecc.cambridge.ma.us
  12176.  
  12177. mauney@csljon.csl.ncsu.edu writes:
  12178. > 2) LL Parsers are to be *preferred* when repair is an issue.
  12179. >   The simple structure of the data on the stacks makes life
  12180. >   much easier.
  12181.  
  12182. Trevor Jenkins <tfj@apusapus.demon.co.uk> writes:
  12183. >It is generally acknowledged that in an LR based parser error recovery is
  12184. >real messy. As to the data on the stack that has nothing to do with the
  12185. >error recovery procedure of either LL or LR parsers.
  12186.  
  12187. Having implemented error-repair for both LL and LR parsers, I must
  12188. disagree.  Since the parse stack contains the definition of the valid
  12189. continuations of the input, I consider it to be essential to good error
  12190. repair.  Even quick and dirty panic-mode recovery methods look at the
  12191. stack to the extent of skipping input to a symbol that can be read, and/or
  12192. popping to a configuration that can read the current symbol.
  12193.  
  12194. >I'm not a C++ theologian but both of you seem to be confusing language
  12195. >with grammar. Just because a language is described by an *LR(1) grammar
  12196. >soes not necessarily mean that it the LANGUAGE is not LL(1). If it can be
  12197. >described by an LL(1) grammar but the langauge designer decides to publish
  12198. >a grammar in the LR family that is there choice but does not restict an
  12199. >implementation to using that grammar form.
  12200.  
  12201. Being a proponent of LL parsing, I frequently make the same speech to
  12202. people who state that X cannot be done with LL(1).  In this case, however,
  12203. numerous people have complained about the difficulty in writing an LALR
  12204. grammar for C++.  Not having tried it myself (yet), I'm not going to claim
  12205. that it is easy to do with LL.  ( In theory, of course, C++ contains the
  12206. dangling-else problem and is not an LL language.  But that one is easy to
  12207. work around)
  12208. --
  12209. Jon Mauney                   mauney@csc.ncsu.edu
  12210. Mauney Computer Consulting   (919)828-8053
  12211. -- 
  12212. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12213. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12214.  
  12215.  
  12216. From compilers Thu Apr 29 23:40:05 EDT 1993
  12217. Newsgroups: comp.compilers
  12218. Path: iecc!compilers-sender
  12219. From: preston@dawn.cs.rice.edu (Preston Briggs)
  12220. Subject: Re: test at top ==> test at bottom
  12221. Message-ID: <93-04-109@comp.compilers>
  12222. Keywords: optimize, bibliography
  12223. Sender: compilers-sender@iecc.cambridge.ma.us
  12224. Organization: Rice University, Houston
  12225. References: <93-04-105@comp.compilers>
  12226. Date: Thu, 29 Apr 1993 15:24:33 GMT
  12227. Approved: compilers@iecc.cambridge.ma.us
  12228.  
  12229. Max Hailperin <max@nic.gac.edu> writes:
  12230. >While working my way through the literature on certain forms of loop
  12231. >optimization, it occurred to me that I haven't seen much in the literature
  12232. >on transformations that will turn test-at-the-top loops into
  12233. >test-at-the-bottom loops.  Yet unless you've done so, you can't safely
  12234. >assume the loop will be done at least once.
  12235.  
  12236. I haven't ever seen much besides 1-liners saying "just do it."  Depending
  12237. on the source language, there may be several approaches.  It's possible to
  12238. get the front end to generate the desired code for DO loops and WHILE
  12239. loops (DO - WHILEs or REPEAT - UNTILs are already fine).  For example,
  12240. instead of translating
  12241.  
  12242.     a
  12243.     WHILE p DO b END
  12244.     c
  12245.  
  12246. into
  12247.  
  12248.     a
  12249. L1:    if (!p) goto L2
  12250.     b
  12251.     goto L1
  12252. L2:    c
  12253.  
  12254. we'd prefer to see
  12255.  
  12256.     a
  12257.     if (!p) goto L2
  12258. L1:    b
  12259.     if (p) goto L1
  12260. L2:    c
  12261.  
  12262. which (as Hailperin points out) allows much more optimization.  If you've
  12263. got a language like Fortran or C that allows programmers to build loops
  12264. out of goto's, then the optimizer will have to fix loops on its own.  I
  12265. can think of a couple of approaches.
  12266.  
  12267.      1) If the loop header block has a successor block outside
  12268.     the loop, then clone the loop header block.
  12269.  
  12270.      2) Peel an entire iteration of the loop.
  12271.  
  12272. Let's reconsider our example, rewritten slightly
  12273.  
  12274.     a
  12275.     goto L1
  12276.  
  12277. L1:    if (p) goto L2 else goto L3
  12278.  
  12279. L2:    b
  12280.     goto L1
  12281.  
  12282. L3:    c
  12283.  
  12284. The loop header is L1 and the other block in the loop is L2.
  12285. Cloning the header gives
  12286.  
  12287.     a
  12288.     goto L1
  12289.  
  12290. L1:    if (p) goto L2 else goto L3
  12291.  
  12292. L2:    b
  12293.     goto L1'
  12294.  
  12295. L1':    if (p) goto L2 else goto L3
  12296.  
  12297. L3:    c
  12298.  
  12299. Note that we leave the original loop header block in place and make a copy
  12300. of it (called L1').  All back edges (edges from within the loop to the
  12301. loop header) are repointed to the clone.
  12302.  
  12303. When we straighten the mess out a little, we get
  12304.  
  12305.     a
  12306.     if (p) goto L2 else goto L3
  12307. L2:    b
  12308.     if (p) goto L2 else goto L3
  12309. L3:    c
  12310.  
  12311. which is just what's desired.
  12312.  
  12313. The second approach, peeling an iteration of the loop, is rather more
  12314. violent.  On the other hand, if we peel and then perform global common
  12315. subexpression elimination (using value numbering, for example), then we
  12316. effectively move all loop invariant in front of the loop.
  12317.  
  12318. Peeling our example gives
  12319.  
  12320.     a
  12321.     goto L1
  12322.  
  12323. L1:    if (p) goto L2 else goto L3
  12324.  
  12325. L2:    b
  12326.     goto L1'
  12327.  
  12328. L1':    if (p) goto L2' else goto L3
  12329.  
  12330. L2':    b
  12331.     goto L1'
  12332.  
  12333. L3:    c
  12334.  
  12335. Cleaning it up a little would give
  12336.  
  12337.     a
  12338.     if (p) goto L2 else goto L3
  12339. L2:    b
  12340. L1':    if (p) goto L2' else goto L3
  12341. L2':    b
  12342.     goto L1'
  12343. L3:    c
  12344.  
  12345. which is obviously not the same result as achieved by cloning.  However,
  12346. the higher-level goal is achieved; that is, we have a place to put
  12347. loop-invarient code -- in fact, we have already made a copy of all the
  12348. loop-invariant code (and everything else).  The downside of this approach
  12349. is that we can consume lots of space (if not in the final result, at least
  12350. in out intermediate representation).
  12351.  
  12352. A relevant paper is
  12353.  
  12354.   title="Code Motion of Control Structures in High-Level Languages",
  12355.   author="Ron Cytron and Andy Lowry and F. Kenneth Zadeck",
  12356.   booktitle=popl13,
  12357.   year=1986,
  12358.   month=jan,
  12359.   pages="70--85"
  12360.  
  12361. Preston Briggs
  12362. -- 
  12363. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12364. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12365.  
  12366.  
  12367. From compilers Thu Apr 29 23:40:48 EDT 1993
  12368. Newsgroups: comp.compilers
  12369. Path: iecc!compilers-sender
  12370. From: oz@ursa.sis.yorku.ca (Ozan S. Yigit)
  12371. Subject: Re: automata book recommendations wanted
  12372. Message-ID: <93-04-110@comp.compilers>
  12373. Keywords: theory, bibliography
  12374. Sender: compilers-sender@iecc.cambridge.ma.us
  12375. Organization: York U. Student Information Systems Project
  12376. References: <93-04-103@comp.compilers>
  12377. Date: Thu, 29 Apr 1993 17:09:10 GMT
  12378. Approved: compilers@iecc.cambridge.ma.us
  12379.  
  12380. Ben S. Hadad writes [in part]:
  12381.       I am looking for a book on Automata Theory as part of a
  12382.    self-study program ...
  12383.  
  12384. There is an excellent book by Lewis+Papadimitriou[1], and there
  12385. is the classic volume by Minsky[2].
  12386.  
  12387. oz
  12388. ---
  12389. [1] Harry R. Lewis and Christos H. Papadimitriou.
  12390.     Elements of the theory of computation.
  12391.     Prentice-Hall, Englewood Cliffs, N.J.
  12392.     1981.
  12393.  
  12394. [2] Marvin L. Minsky.
  12395.     Computation: finite and infinite machines.
  12396.     Prentice-Hall, Englewood Cliffs, N.J.
  12397.     1967.
  12398. -- 
  12399. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12400. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12401.  
  12402.  
  12403. From compilers Thu Apr 29 23:55:39 EDT 1993
  12404. Newsgroups: comp.compilers
  12405. Path: iecc!compilers-sender
  12406. From: oz@ursa.sis.yorku.ca (Ozan S. Yigit)
  12407. Subject: parsing references [req]
  12408. Message-ID: <93-04-111@comp.compilers>
  12409. Keywords: parse, question, comment
  12410. Sender: compilers-sender@iecc.cambridge.ma.us
  12411. Organization: York U. Student Information Systems Project
  12412. Date: Thu, 29 Apr 1993 17:17:40 GMT
  12413. Approved: compilers@iecc.cambridge.ma.us
  12414.  
  12415. I would like to have a good bibliography on parsing. I have various
  12416. bits and pieces of references, but I would prefer something much more
  12417. comprehensive. If you have such a bibliography [in any format] you
  12418. would like to share, I would much appreciate it.
  12419.  
  12420. please reply via e-mail. thanks in advance.
  12421.  
  12422. oz
  12423. ---
  12424. electric: oz@sis.yorku.ca, ph:[416] 736 2100 x 33976
  12425. [I'm always happy to add bibliographies to the compilers archive.  Feel
  12426. free to send 'em in. -John]
  12427. -- 
  12428. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12429. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12430.  
  12431.  
  12432. From compilers Fri Apr 30 00:05:28 EDT 1993
  12433. Newsgroups: comp.compilers
  12434. Path: iecc!compilers-sender
  12435. From: Boum Belkhouche <bb@rex.cs.tulane.edu>
  12436. Subject: CFP: IEEE CS Computer Languages Conf., France May 1994
  12437. Message-ID: <93-04-112@comp.compilers>
  12438. Keywords: CFP
  12439. Sender: compilers-sender@iecc.cambridge.ma.us
  12440. Organization: Compilers Central
  12441. Date: Thu, 29 Apr 1993 17:06:03 GMT
  12442. Approved: compilers@iecc.cambridge.ma.us
  12443.  
  12444.                             CALL FOR PAPERS
  12445.    IEEE Computer Society 1994 International Conference on Computer Languages
  12446.  
  12447.                  Toulouse, France, May 16-19, 1994
  12448.  
  12449. Sponsored by the IEEE Computer Society Technical Committee on Computer
  12450. Languages In cooperation with ACM SIGPLAN and IRIT
  12451.  
  12452. Areas of particular interest include but are not limited to:
  12453.  
  12454. Implementation/optimization          Theory/semantics
  12455. Abstract interpretation              Dataflow analysis
  12456. Partial evaluation
  12457. Parallel/distributed languages       Object-oriented languages
  12458. Functional/logic languages           Multiparadigm languages
  12459. Real-time/fault-tolerant languages   Reqm'ts/design/specification languages
  12460. Visual/graphical languages           Application-specific languages
  12461.  
  12462. Papers should be at most 20 double-spaced pages (10 pt on 16 pt) in
  12463. length, should have an abstract of approx, 250 words, and a separate cover
  12464. page indicating the title, authors, and a list of keywords. Papers will be
  12465. judged on the basis of their relevance, significance, originality,
  12466. correctness, and clarity.  Accepted papers will appear in a full
  12467. proceedings published by the IEEE Computer Society Press, for which
  12468. authors will be expected to sign a copyright release form.  A selection of
  12469. best papers will be published in a journal.
  12470.  
  12471.  
  12472. Submit 5 copies of papers or 3 copies of panel session proposals by
  12473. September 24, 1993 to Dr. Henri Bal, program committee chair Submissions
  12474. should be accompanied by a cover letter that includes a return mailing
  12475. address, telephone number and email address.  Authors will be notified of
  12476. acceptance or rejection by December 8, 1993.  Camera ready versions of
  12477. accepted papers will be due January 12, 1994.
  12478.  
  12479. For more information contact: bb@cs.tulane.edu
  12480.  
  12481. or    Dr. Henri Bal
  12482.         Vrije Universiteit
  12483.         Dept. of Mathematics and Computer Science
  12484.         De Boelelaan 1081a
  12485.         1081 HV Amsterdam, The Netherlands
  12486.         +31 20 5485574, bal@cs.vu.nl
  12487.         Fax: +31 20 6427705
  12488. -- 
  12489. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12490. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12491.  
  12492.  
  12493. From compilers Fri Apr 30 00:06:44 EDT 1993
  12494. Newsgroups: comp.compilers
  12495. Path: iecc!compilers-sender
  12496. From: andrewd@winnie.cs.adelaide.edu.au (Andrew Dunstan,,2285592,)
  12497. Subject: Re: predicate parsing
  12498. Message-ID: <93-04-113@comp.compilers>
  12499. Keywords: parse, performance
  12500. Sender: compilers-sender@iecc.cambridge.ma.us
  12501. Reply-To: andrewd@cs.adelaide.edu.au
  12502. Organization: The University of Adelaide
  12503. References: <93-04-101@comp.compilers>
  12504. Date: Thu, 29 Apr 1993 12:37:13 GMT
  12505. Approved: compilers@iecc.cambridge.ma.us
  12506.  
  12507. > A) LL parsers can be as fast as anything else.
  12508.  
  12509. This is an understatement. Other things being equal, they are faster than
  12510. bottom-up parsers. (See Fischer & LeBlanc for an analysis.)
  12511.  
  12512. > 2) LL Parsers are to be *preferred* when repair is an issue.
  12513. >   The simple structure of the data on the stacks makes life
  12514. >   much easier.
  12515.  
  12516. Right, again, but for the wrong reason. Intuitively, LL parsers provide
  12517. better error recovery possibilities because they are predictive, i.e. you
  12518. know where you are going, whereas in L??R parsers, you don't always know
  12519. for sure where you are going till you've got there. The power of this
  12520. parsing method comes precisely from the ability to delay this decision.
  12521.  
  12522.  
  12523. [III is how to deal with ambiguities in C++]
  12524.  
  12525. Let's go back to the start of this thread. Using predicates in parsing,
  12526. either predictive or not, can add to the power of the parsing method.
  12527. Perhaps more importantly, they can reduce the extent to which the grammar
  12528. must be massaged in order to fit the parsing method. This is significant
  12529. in difficult grammars such as C++ and Ada.
  12530.  
  12531. At the GNAT project at NYU (which will produce GNU Ada), Robert Dewar is,
  12532. as I understand it, using a recursive descent parser with backtracking,
  12533. written in Ada83, with excellent recovery characteristics and blindingly
  12534. fast. So these methods are not just of "academic" interest.
  12535. --
  12536. #  Andrew Dunstan
  12537. #  net:
  12538. #    adunstan@steptoe.adl.csa.oz.au
  12539. #  or: andrewd@cs.adelaide.edu.au
  12540. -- 
  12541. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12542. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12543.  
  12544.  
  12545. From compilers Fri Apr 30 00:07:31 EDT 1993
  12546. Newsgroups: comp.compilers
  12547. Path: iecc!compilers-sender
  12548. From: psychlo@bagabolts.eecs.umich.edu (John-David Wellman)
  12549. Subject: Code Scheduling for Multi-Issue Machines
  12550. Message-ID: <93-04-114@comp.compilers>
  12551. Keywords: optimize, architecture, question
  12552. Sender: compilers-sender@iecc.cambridge.ma.us
  12553. Organization: University of Michigan EECS Dept., Ann Arbor
  12554. Date: Thu, 29 Apr 1993 21:22:27 GMT
  12555. Approved: compilers@iecc.cambridge.ma.us
  12556.  
  12557. Hi,
  12558.  
  12559.   We are working on several projects here, and many of them would benefit
  12560. from some insights into the compilation of code for a multi-issue
  12561. architecture.  We understand that most compiler work is pretty generally
  12562. applicable, but there are some issues in the jump from a single-issue
  12563. machine to a multiple-issue machine, and yet we are having some difficulty
  12564. finding a good set of publications which address these issues.  Thus, this
  12565. is a general call for either references which discuss the generation of
  12566. code schedules for a superscalar or multi-issue machine (and particularly
  12567. one which can have more than two instructions issue, and is statically
  12568. scheduled), or general insights and knowledge (experiences) about this
  12569. subject.
  12570.  
  12571.   Thank you for any help you can provide.  Please either post or send
  12572. email (or both, if you'd like).
  12573. ---
  12574. John-David Wellman -- (psychlo@eecs.umich.edu)
  12575. EECS Graduate Research Assistant
  12576. The University of Michigan
  12577. -- 
  12578. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12579. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12580.  
  12581.  
  12582. From compilers Fri Apr 30 00:11:59 EDT 1993
  12583. Xref: iecc comp.object:10055 comp.compilers:4573 comp.benchmarks:3123 comp.databases.object:111
  12584. Newsgroups: comp.object,comp.compilers,comp.benchmarks,comp.databases.object
  12585. Path: iecc!compilers-sender
  12586. From: "Jeff P. Lankford" <jpl@nrtc.northrop.com>
  12587. Subject: Have CORBA IDL compiler -- will trade 4 regression test suite
  12588. Message-ID: <93-04-115@comp.compilers>
  12589. Followup-To: comp.object
  12590. Keywords: benchmarks
  12591. Sender: compilers-sender@iecc.cambridge.ma.us
  12592. Organization: Northrop Research and Technology Center
  12593. Distribution: comp
  12594. Date: Thu, 29 Apr 1993 22:04:26 GMT
  12595. Approved: compilers@iecc.cambridge.ma.us
  12596.  
  12597. I'm finishing up an IDL compiler and am seeking a test set of IDL
  12598. "programs".  The examples in the CORBA spec manual are skimpy, and
  12599. i'd like some hefty input to really stress the compiler.  Any
  12600. suggestions?  Please reply directly via e-mail.
  12601. jpl
  12602.  
  12603. -- 
  12604. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12605. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12606.  
  12607.  
  12608. From compilers Fri Apr 30 00:19:25 EDT 1993
  12609. Newsgroups: comp.compilers
  12610. Path: iecc!compilers-sender
  12611. From: gudeman@cs.arizona.edu (David Gudeman)
  12612. Subject: Summary: Representations of Dynamic Type Information
  12613. Message-ID: <93-04-116@comp.compilers>
  12614. Keywords: types, summary
  12615. Sender: compilers-sender@iecc.cambridge.ma.us
  12616. Organization: U of Arizona CS Dept, Tucson
  12617. References: <93-04-095@comp.compilers>
  12618. Date: Fri, 30 Apr 1993 02:31:35 GMT
  12619. Approved: compilers@iecc.cambridge.ma.us
  12620.  
  12621. Well, thanks for all of the responses.  I got several new ideas, and got
  12622. reminded of several things I had forgotten to include.  It would be a
  12623. little impractical for me to "summarize" the entire report here, since it
  12624. is 26 pages long.  However, there is a fairly complete draft available (at
  12625. 26 pages it ought to be fairly complete :-), and if anyone is interested
  12626. in reading it, it is available in compressed postscript by anonymous ftp
  12627. from cs.arizona.edu in the file "/usr/ftp/janus/jc/tags.ps.Z".  If anyone
  12628. has trouble getting this or needs an uncompressed file, or wants the latex
  12629. source, let me know.  I haven't had time to discuss all of the ideas I got
  12630. from the net, so I've included draft notes in the text to give a hint
  12631. about these (and I've tried to credit the people who wrote me).  A few of
  12632. the draft notes are essentially the remainders of my outline.  Since I
  12633. have to go on to other work, the report is probably going to remain in
  12634. this unfinished state for a while.
  12635.  
  12636. For those who are curious, but not curious enough to read a 26-page
  12637. report, here is a rough outline of the methods (this does not include all
  12638. of the tricks and special cases)
  12639.  
  12640. tagged-words (type information is in the machine word)
  12641.   tag fields (word is broken up into tag and data fields)
  12642.     tag field in high end (most-significant bits) of word
  12643.        use tag of all zeros for one type to avoid tagging cost
  12644.        negative ints get a tag of all ones, non-negative ints
  12645.                                   get a tag of all zeros
  12646.        use sign bit for one type
  12647.          use sign-bit = 0 for one type and optimize another type by
  12648.                                   giving it the tag of all ones in the
  12649.                                   high end and tagging by negation.
  12650.     tag field in low end of word
  12651.       use n-bit tags to represent pointers data aligned on n-byte boundaries
  12652.                                   this allows tagging without shifting
  12653.         use a tag of all zeros to avoid tagging and untagging
  12654.       use tags that contain only one non-zero bit to make testing faster
  12655.       use all zeros to optimize integer arithmetic
  12656.       optimize integer arithmetic by adding/subtracting tag
  12657.                                   after subtraction/addition
  12658.     tag field in both ends of word
  12659.        various combinations of tricks from the other two options
  12660.   partitioning by pattern (type is encoded in the representation of the value,
  12661.                            no boxing/unboxing is done, usually words are
  12662.                            partitioned into ranges of numbers they rep.)
  12663.     simple range tests to identify types
  12664.     segments with statically determined types (a segment is a range of
  12665.                            numbers that can be identified by an
  12666.                            initial field in the bit-patterns used to
  12667.                            represent them).
  12668.     segments with dynamically determined types
  12669.       use BIBOP (table indexed by segments) to identify types
  12670.       identify type in the segment itself
  12671.         first word of segment
  12672.         last word of segment
  12673.       on a segmented architecture like the 80x86, one location has
  12674.                            many addresses so the (machine) segment
  12675.                            part of the address can be set to the
  12676.                            (representation) segment of the data type
  12677.                            being represented, and the offset can be
  12678.                            set in such a way that any object can be in
  12679.                            any machine segment.
  12680.       on machines that ignore the high bits of pointer, these bits can
  12681.                            be used for free boxing/unboxing
  12682.   make everything a legal IEEE float, using the NaN bit patterns to
  12683.                            encode all other types of data.
  12684.  
  12685. object-pointers (untagged pointers refering to self-identifying blocks
  12686.                  on the heap)
  12687.   combinations of this scheme with the tagged-word scheme
  12688.  
  12689. descriptors (two-word data elements divided into a type word and a
  12690.              value word)
  12691.   encoding a qualifier (address+length representation of a sequence)
  12692.                            in a descriptor
  12693.   encoding a cons cell in a descriptor
  12694.   direct representation of floats
  12695.  
  12696. segregated type codes (type information is kept elsewhere)
  12697.   type information for globals kept in a global area
  12698.   type information for locals kept in stack frame
  12699.   type information kept in header of aggregate objects
  12700.  
  12701. Thanks to Paul Tarau, Richard Fateman, Mikael Pettersson, Nick Thompson,
  12702. Andrew Wright, Benjamin Goldberg, Aubrey Jaffer, Eric Benson, Marc
  12703. Brandis, Kelvin Nilsen, Stavros Macrakis, Alexandr Kopilovich, Pekka
  12704. Pirinen, William Griswold, David Keppel, Marc-Michael Brandis, Mark
  12705. Tillotson, Richard Brooksby, cowan@magpie.linknet.com, Hintermeier Claus,
  12706. Hendrik Boom, and Tim Lindholm for your help.
  12707. --
  12708.                     David Gudeman
  12709. gudeman@cs.arizona.edu
  12710. -- 
  12711. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12712. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12713.  
  12714.  
  12715. From compilers Fri Apr 30 12:02:07 EDT 1993
  12716. Newsgroups: comp.compilers
  12717. Path: iecc!compilers-sender
  12718. From: Pat Terry  <CSPT@giraffe.ru.ac.za>
  12719. Subject: COCO/R bug fix
  12720. Message-ID: <93-04-117@comp.compilers>
  12721. Keywords: tools, LL(1)
  12722. Sender: compilers-sender@iecc.cambridge.ma.us
  12723. Organization: Compilers Central
  12724. Date: Fri, 30 Apr 1993 20:37:26 GMT
  12725. Approved: compilers@iecc.cambridge.ma.us
  12726.  
  12727. John Gough has reported a bug in Coco/R (the LL(1) parser generator that
  12728. originated from Hanspeter Mossenbock in Zurich).  It exists in my MS-DOS
  12729. port (version 1.27), which I know several readers of this group have used,
  12730. and I suspect exists in the Oberon version too.  A simple input that will
  12731. set it off is the following
  12732.  
  12733.      COMPILER E
  12734.  
  12735.      PRODUCTIONS
  12736.        E = % |  % .
  12737.      END E.
  12738.  
  12739. The problem occurs when there are unrecognisable symbols (like %) in the
  12740. alternatives for a production.  It does not always cause trouble; when it
  12741. does, the system loops infinitely.
  12742.  
  12743. The fix is as follows:
  12744.  
  12745. In CRP.MOD the code for PROCEDURE Term currently allows one to leave the
  12746. procedure without assigning proper values to the parameters gL and gR if
  12747. an unrecognisable terminal is encountered.  A simple extra line sorts that
  12748. out
  12749.  
  12750.     PROCEDURE  Term (VAR gL, gR: INTEGER);
  12751.       VAR
  12752.         gL2, gR2: INTEGER;
  12753.       BEGIN
  12754.         gL := 0; gR := 0;            (* <= =============== add line here *)
  12755.         IF In(symSet[2], sym) THEN   (* This is the DOS version; Oberon
  12756.                                         one is slightly different here *)
  12757.           Factor(gL, gR);
  12758.  
  12759. The simplest fix is to alter CR.ATG.  If you do this as below you can
  12760. generate a new CRP.MOD file by a bootstrap process:
  12761.  
  12762.    CR.ATG :  we need to get the extra line generated   ======
  12763.              so the attribute grammar needs fixing           |
  12764.                                                              |
  12765. Term<VAR gL, gR: INTEGER>    (.VAR                           |
  12766.                                  gL2, gR2: INTEGER;.)        |
  12767. =                            (.gL := 0; gR := 0.)       <----- add here
  12768. ( Factor <gL, gR>
  12769.     { Factor <gL2, gR2>      (.CRT.ConcatSeq(gL, gR, gL2, gR2).)
  12770.     }
  12771.   |                          (.gL := CRT.NewNode(CRT.eps, 0, 0); gR := gL.)
  12772.   ).
  12773.  
  12774. Pat Terry, Computer Science, Rhodes University, GRAHAMSTOWN 6140, RSA
  12775. cspt@alpha.ru.ac.za  or  cspt@giraffe.ru.ac.za  or pdterry@psg.com
  12776. -- 
  12777. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12778. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12779.  
  12780.  
  12781. From compilers Fri Apr 30 12:02:40 EDT 1993
  12782. Newsgroups: comp.compilers
  12783. Path: iecc!compilers-sender
  12784. From: jourdan@minos.inria.fr (Martin Jourdan)
  12785. Subject: Re: Dynamic Slices...
  12786. Message-ID: <93-04-118@comp.compilers>
  12787. Keywords: debug
  12788. Sender: compilers-sender@iecc.cambridge.ma.us
  12789. Organization: INRIA, Rocquencourt, France
  12790. References: <93-04-078@comp.compilers>
  12791. Date: Fri, 30 Apr 1993 15:09:34 GMT
  12792. Approved: compilers@iecc.cambridge.ma.us
  12793.  
  12794. Peter Fritzson and his team at Linko"ping Univ. in Sweden have done quite
  12795. a bit of work on dynamic slicing.  In particular, they have recently
  12796. published a survey on static and dynamic slicing which might be of
  12797. interest to you.  Contact Peter (paf@ida.liu.se).
  12798.  
  12799. Martin Jourdan <Martin.Jourdan@inria.fr>, INRIA, Rocquencourt, France.
  12800.     Phone +33-1-39-63-54-35, fax +33-1-39-63-53-30
  12801. -- 
  12802. Send compilers articles to compilers@iecc.cambridge.ma.us or
  12803. {ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
  12804.  
  12805.