HDTenEightyP/NetNews huggingface dataset:
From: eric@pencom.com
Newsgroups: comp.compilers
Subject: Re: yacc or bison?
Keywords: yacc, design
Date: 16 Apr 92 13:57:41 GMT
Reply-To: eric@pencom.com
Organization: Pencom Software

pkeddie@axion.bt.co.uk (Paul Keddie) writes:
>[what are relative merits of yacc, bison, etc.]

Well, I have not used Bison, but I can certainly put my 2 cents in about
yacc.

It is avaliable pretty much in pure form on all systems.  It works well
but ....

It allows productions to "return" values, but does not allow the "passing"
of values to productions.  This makes some things VERY difficult to
manage.  Global variables abound.

You can not easily use 2 yacc descriptions in the same program.  This
really bit me once when a library I was using used yacc when I wanted to.
Totally bogus.  Lex is the same way.  I am amazed that Lex and Yacc have
not been fixed to this day.

It is very difficult to determine why a grammar might be ambiguous.  A
debugging file can be printed out, but it looks like gibberish.  It seems
that an English description of ambiguities could be printed out, but is
not.

Yacc code does not lint cleanly.

[Inherited attributes can often be handled using the $0 and $-1, Bison and
Posix yacc address the multiple parser problem by letting you change the
"yy" prefixes in the generated parser via command line switches.  There
are variety of ways to fake it with older versions of yacc, see messages
90-08-085, 90-09-029, 90-09-007, 90-08-076, and 90-08-101. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: pardo@cs.washington.edu (David Keppel)
Subject: Re: binary-compiler from Apple?
Keywords: assembler, translator
Reply-To: pardo@cs.washington.edu (David Keppel)
Organization: Computer Science & Engineering, U. of Washington, Seattle
Date: Wed, 8 Apr 1992 01:58:15 GMT

taihou@iss.nus.sg (Tng Tai Hou) writes:
>[Binary->binary cross-compilation?]

I can find a reference but I can't find the orginal... on 9 Nov. 1988,
John Mashey (at MIPS) posted an article (to comp.arch, I think)
descrbing a particularly cute use of binary-binary cross-compilation.

At one time MIPS had compiler tools and they were working on getting
code up and running.  They had no MIPS silicon.  They could have built
MIPS binaries and run them on a simulator ... slow ... or compiled them
to run on their VAXen ... which doesn't test the compiler tools.  What
they did was generate MIPS binaries, cross-compile them to VAX binaries
and then run them.

John estimated that if the VAX was running at the same speed as the
MIPS, they would have seen less than a 2X performance blowup, and they
weren't even trying super-hard to make the binary-binary compilation
generate good VAX code.

	;-D oN  ( Software solutions to hardware problems )  Pardo
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: bliss@sp64.csrd.uiuc.edu (Brian Bliss)
Subject: Re: Wanted: a program that calulates the maximal stack depth
Keywords: storage
Reply-To: bliss@sp64.csrd.uiuc.edu (Brian Bliss)
Organization: UIUC Center for Supercomputing Research and Development
Date: Thu, 9 Apr 1992 17:49:34 GMT

samuel writes:
> I'm developing an application where the use of stack space is crucial.

Assumming you have a language which supports stack-allocated locals, C in
this example, why not just keep track of the min/max address of a local
var upon subroutine entry?  It won't work very well if you are dynamically
allocating large arrays on the stack in leaf procedures, but usually
provides a very good approximation.  I used something similar to this to
help debug a multitasking package I wrote (when modifying the context
switch routine, where the stacks kept getting all messed up).

#ifdef STACK_CHECK
char *main_address;
char *min_address;
#endif

main () {
#ifdef STACK_CHECK
   char ch;
   main_address = min_address = &ch;
#endif
   .
   .
   .
   printf ("stack usage = 0x%x\n", main_address - min_address);
   /* assume stack grows downward */
}

then in each subroutine, put:

int sub () {
#ifdef STACK_CHECK
   char ch;
   if (&ch < min_address) min_address = &ch; /* assume stack grows downward */
#endif
   .
   .
   .
}
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: pkeddie@axion.bt.co.uk (Paul Keddie)
Subject: yacc or bison?
Keywords: yacc, parse, question
Reply-To: pkeddie@axion.bt.co.uk (Paul Keddie)
Organization: British Telecom Research Labs
Date: Wed, 15 Apr 1992 13:47:41 GMT

Dear all,
          No doubt this question has been asked before, but here goes.  I
am about to write a simple C parser using yacc or bison (both of which are
available to me). My question is simple. Which do I use? What are the pros
and cons of both?  Also, do people feel put off using bison because bison
grammars can only be used in programs that are free software (or has this
now changed)?  My boss is particular worried by this last point!  Cheers
in advance,

Paul
Software Maintenance Group, Software Technology Division, BT
Research Labs, Martlesham Heath, Ipswich, IP5 7RE, UK
E-mail:  pkeddie@axion.bt.co.uk
Phone:  +44 473 649154 Fax:    +44 473 643019 
[There are actually three versions of yacc commonly available for Unix
systems -- the original AT&T yacc, bison, and Robert Corbett's Berkeley
yacc.  Bison is derived from an earlier version of Corbett's work but is
now considerably different from Berkeley yacc.  Each has different legal
status: AT&T yacc is subject to AT&T license but parsers created from it
may be distributed without restriction, bison is free but bison parsers
are subject to the GNU copyleft, and Corbett's work is in the public
domain.  Technically, bison has more sophisticated error recovery and
fancier debugging than the other two.  Personally, I'd use Berkeley yacc.
-John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: jao@red6.acpub.duke.edu (JOSEPH OSWALD)
Subject: Include files and yacc grammars
Keywords: design, question
Reply-To: jao@red6.acpub.duke.edu (JOSEPH OSWALD)
Organization: Compilers Central
Date: Wed, 15 Apr 1992 02:27:05 GMT

I'm creating a simple interpreter for a Pascal/C-like language.

One of the important features that I want the language to have is an
include facility. However, since this language is going to be used by
beginners, I want the include directive appear like a statement, like so:

  include("a.init"); /* contains statement that initializes a */
  print ("Variable a is ", a);

rather than some exceptional notation like #include that might be
confusing.

I would like for it to be an ordinary statement in the grammar:

  statement: IDENTIFIER '(' args ')' ';' /* procedure call */
	   | INCLUDE '(' arg ')' ';' 
               { tell lexer to insert file "arg" into the token stream. }

	   | IF condition ......
	   ;

The problem with this is that I can't figure out how to make sure that the
include file's contents properly synchronize with the grammar. What do I
do with the lookahead token (if there is one??), since it belongs to the
main file, and I want to start parsing the include file.

(Note. I am very willing to restrict the include file's contents to be
complete declarations and statements, as opposed to code fragments.)

The solution I'm using is for the lexical analyzer to recognize the sequence
  INCLUDE '(' QUOTEDSTRING ')' ';'

  and replace it with the following:

  BEGININC ...tokenized input file contents... ENDINC ...rest of main file..
   
  where BEGININC and ENDINC are marker tokens.

In order that the include be recognized only when it is a proper
statement, my grammar is set up thus:

actionlist:   /* empty */
	    | BEGININC actionlist ENDINC
	    | action
	    | actionlist action
	    ;

action:		declaration
	     | statement

(and the include statements is NOT part of the grammar.)

This works (so far as I can tell.), but requires that the lexical analyzer
do some parsing to recognize the include. 

Is there a better way; i.e., one that permits me to put it in the grammar?

(One thing that worries me about my approach, other than its kludginess is
handling an error parsing the include statement, like missing the final
semicolon...)

--Thanks
Joe Oswald	
[I suppose you could muck around in the parser and try to save and restore
the lookahead token, but handling the include feature in the lexer is
probably the best way to go. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:751 comp.lang.ada:1187
From: kleinjf@rosalind.cs.rose-hulman.edu (Joel F. Klein)
Newsgroups: comp.compilers,comp.lang.ada
Subject: Implementing packages for Ada compiler
Keywords: Ada, question
Date: 6 Apr 92 13:55:24 GMT
Reply-To: kleinjf@rosalind.cs.rose-hulman.edu (Joel F. Klein)
Organization: Rose-Hulman Institute of Technology


	Has anyone out there implemented packages for an Ada compiler?  I  
am facing the task at the moment and would like to hear any warnings,  
horror stories, and bits of advice that folks might offer.  I prefer that
you reply via email.
[Please send responses to compilers as well if of general interest. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers,comp.lang.c,gnu.gcc.help
From: s902151@yallara.cs.rmit.OZ.AU (James R Boyle)
Newsgroups: comp.compilers
Subject: Wanted: Pascal BNF
Keywords: Pascal, parse, LL(1)
Date: 16 Apr 92 21:40:41 GMT
Reply-To: s902151@yallara.cs.rmit.OZ.AU (James R Boyle)
Organization: Compilers Central

I am in need of a LL(1) grammar for Standard Pascal, one that can be
easily hard coded into a recursive descent parser.

    I would prefer one that is already single symbol lookahead or at least
the conflicts can be resolved by type checking. 

    As another request does anyone have an algorithm or code (preferably C
or Pascal) for checking the single symbol look ahead property of for
making a LL grammar single symbol lookahead.

Email rather than news please
Thanks

- James Boyle

s902151@yallara.cs.rmit.oz.au jboyle@godzilla.cgl.citri.edu.au
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: meissner@osf.org
Newsgroups: comp.compilers
Subject: 88open OCS
Keywords: code, 88000, registers
Date: 16 Apr 92 16:11:15 GMT
Reply-To: meissner@osf.org
Organization: Compilers Central

Stuart D. Gathman complains that the 88open OCS is braindead with regard
to the calling sequence on the 88k.

Yes, the calling sequence is suboptimal, and yes I was peeved at this when
I worked on the 88k GNU compiler for Data General (1.37 time frame).  At
the time the decision was made, there were two compilers shipping to 88k
developers that I know of:

   1)	The Motorola PCC port; (and)
   2)	The Greenhills port.

My memory is fuzzy as to whether or not, DG had committed to the GNU C
compiler publically at that time -- I don't believe I had it was stable
enough back then.  I also don't think the Tadpole compiler was released
either at that point (I don't remember what other 88k C compilers existed
at the time).

Anyway, the Motorola PCC port's calling sequence was the same as the
original FSF GNU C compiler (pass the first 8 words in registers, and pass
everything else on the stack), and the Greenhills used more or less the
current OCS calling sequence.  The difference between OCS and the original
Greenhills calling sequence was how 1 word registers were returned (and
maybe passed).  Since most of the vendors at the OCS meeting were using
Greenhills as the system compiler, the choice was clear.  Greenhills
supposedly could not deal with splitting structures between the register
pool and the save area (even though one approach would have been to copy
the structures into the save area, like now, and then just before the
call, do 1-8 loads, to reload the registers).  It evidently was an
emotional meeting, though I wasn't there.

Usually, no matter how bad a standard calling sequence is, it is better to
use the standard sequence and be able to share libraries, and such, rather
than to stand off in a corner throwing a temper tantrum.

Also, I'm surprised you were getting good results out of 1.xx.  I seem to
recall that there were plenty of changes needed to get it to host itself
(those changes were deemed too large for GCC 1.xx, and were not folded in
until GCC 2.00).

| P.S.
| 	My 1.40 88k port did insn scheduling in the assembler.  Doing it
| in the compiler can better schedule across basic blocks, but the assembler
| pass was almost as good and resulted in a much smaller and faster
| compiler.  Any opinions on this?  I can post my (small and simple) asopt
| pass if anyone is interested.

Sure, go ahead and post it.  Tom Wood and I had added hooks in the 1.37
compiler to allow it to call an assembler optimizer between the compiler
proper and the assembler, but this was never used, since Motorola's
attempt at a scheduler (in the 0.6 release of the tools, removed in the
1.0 release) was extremely buggy.
--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: haddad@pa.dec.com (Ramsey Haddad)
Newsgroups: comp.compilers
Subject: Re: Is there a way of generating code for x/const without division?
Keywords: optimize, arithmetic
Date: 7 Apr 92 23:22:56 GMT
Article-I.D.: comp.92-04-036
Reply-To: haddad@pa.dec.com (Ramsey Haddad)
Organization: DEC Western Research Lab, Palo Alto, CA

In article <92-04-026@comp.compilers> moss@cs.umass.edu (Eliot Moss) writes:
>The question was: if one is dividing by a constant or taking modulus by a
>constant, might one do better than using a general divid instruction,
>analogous to doing some shifts and adds to replace a multiply?

>Basically, one replaces the division by multiplication times the inverse.

>Perhaps other respondents can provide citations in the literature

Robert Alverson.  "Integer division using reciprocals", in 10th IEEE
Symposium on Computer Arithemtic, pages 186-190, June 1991. IEEE pub code
CH3015-5/91/0000/0186.

The paper discusses the approach followed by Tera Computers.  It covers all
divisions, with division by constants outlined as a special case.

For signed division by constants on a DEC Alpha, you can use the method
outlined in his paper.  For unsigned division, Tera uses some extra
hardware support that is also useful for general divisions.  Since this
extra hardware support is not in the specification for the DEC Alpha, some
other method must be used.  If you want the details, send me email.

-- 
Ramsey Haddad <haddad@decwrl.dec.com>
[Similar notes from Tim Peters <tim@ksr.com>, and from Bob Alverson himself
<bob@tera.com>.  -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: muthukri@cis.uab.edu (PRAKASH KUMAR)
Subject: "Denotational Semantics for Occam" paper wanted
Keywords: denotational semantics
Reply-To: muthukri@cis.uab.edu (PRAKASH KUMAR)
Organization: Compilers Central
Date: Thu, 9 Apr 1992 21:41:54 GMT

Hi netter,
  I am looking for the following paper. 
  "Denotational Semantics for Occam" by Roscoe,A.W.

Unfortunately, i don't know the journal in which it appeared. I am sure that
somebody out there knows the journal in which it appeared. If so, please
let me know.

Thanks in advance,
Prakash K Muthukrishnan
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:745 comp.lang.functional:470
From: bhatiaa@polly.cs.rose-hulman.edu (Amit Bhatiani)
Newsgroups: comp.compilers,comp.lang.functional
Subject: Compiler for Toy/Ada in SML/NJ
Keywords: ML, Ada, FTP
Date: 2 Apr 92 20:25:49 GMT
Reply-To: bhatiaa@polly.cs.rose-hulman.edu (Amit Bhatiani)
Organization: Rose-Hulman Institute of Technology

Hi,
    I have been getting requests for our compiler...a little more than I
had expected...:-). So, I am going to make the sources and the
documentation available via ftp. They should be at the following site in a
couple of days.  Latest by Monday. 

master.cs.rose-hulman.edy
137.112.40.10

pub/compiler.tar.Z
pub/compiler-docs.tar.Z

The docs will be in ascii format. We also have them in WriteNow for those
of you using NeXT's...

If there are people that cannot get to the above site, send me mail and I
will see what I can do.

Thanks.

Amit Bhatiani
bhatiaa@cs.rose-hulman.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: pardo@cs.washington.edu (David Keppel)
Newsgroups: comp.compilers,comp.lang.c,gnu.gcc.help
Subject: Re: Info needed (Sparc C compiler w/o register window)
Keywords: registers, sparc
Date: 16 Apr 92 15:28:46 GMT
Reply-To: pardo@cs.washington.edu (David Keppel)
Organization: Computer Science & Engineering, U. of Washington, Seattle

>>[I'm no fan of register windows, but is it really that hard to handle the
>>over- and underflow? -John]

torek@horse.ee.lbl.gov (Chris Torek) writes:
>On the SPARCstation, the answer is `yes'.  The reason is a bit
>complicated, ...

For an other explanation, with essentially the same conclusion, see my TR
via anonymous ftp from `cs.washington.edu' (128.95.1.4) in
`pub/pardo/sparc-threads.ps.Z'.  It's a rather long-winded description of
why you can't write a truly user-space threads package on the SPARC and
how to do a job that's close.  It also has an appendix on assigning one
register window to each thread and doing context switches by switching
windows and why that's rarely a win compared to just saving and restoring
registers manually from user space.

	;-D oN  ( Thread light and bool )  Pardo
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: paulb@travis.csd.harris.com (Paul Beusterien)
Newsgroups: comp.compilers
Subject: Re: Recovering control flow information
Keywords: optimize
Date: 14 Apr 92 14:51:13 GMT
Article-I.D.: comp.92-04-056
Reply-To: paulb@travis.csd.harris.com (Paul Beusterien)
Organization: Harris Computer Systems Division

>[how to find function boundaries and branch tables in compiler output?]

>[This information is clearly available to the compiler, so I'd take the
>direct approach and have the compiler put some comments into the file that
>identify entry points, function boundaries, and branch tables. -John]

This is the approach I have taken in our 88k instruction scheduler.  The
compiler outputs scheduler directives to identify function start-points
and computed branch tables.  I also use directives for several other
things including alias information, volatile information, and register
lifetime information into and out of functions calls.
--
Paul Beusterien                          paulb@ssd.csd.harris.com
Harris Computer Systems 
Ft. Lauderdale, FL                       voice: (305) 973 5270

-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: rcg@lpi.liant.com (Rick Gorton)
Newsgroups: comp.compilers
Subject: Re: Pascal Compiler Test Suite
Keywords: Pascal, testing
Date: 10 Apr 92 13:24:16 GMT
Article-I.D.: comp.92-04-045
Reply-To: rcg@lpi.liant.com (Rick Gorton)
Organization: Compilers Central

>krp@SEI.CMU.EDU (Keith Pierce) writes:
>Over the last three years comp.compilers has received four postings
>requesting test suites for pascal compilers, apparently with no response.
>This post asks the question again.

Try BSI Quality Assurance in the U.K.

	BSI Quality Assurance
	PO Box 375
	Milton Keynes MK14 6LL
	United Kingdom

	Tel: +44 908 220908
	Telex: 827682 BSIQA G
	Fax: (0908) 220671

Their test suite tests for conformity to ISO 7185.

Richard Gorton               rcg@lpi.liant.com  (508) 626-0006
Liant Software Corp.         Framingham, MA 01760 USA
Project leader: LPI-BASIC, LPI-FORTRAN, LPI-Pascal, LPI-PL/I
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: Andrew Sao-Chun Huang <ahuang@faraday.ece.cmu.edu>
Subject: Recovering control flow information
Keywords: optimize, parallel, question
Reply-To: Andrew Sao-Chun Huang <ahuang@faraday.ece.cmu.edu>
Organization: Compilers Central
Date: Mon, 13 Apr 1992 21:00:32 GMT

I'm working on a code scheduler that produces scheduled code for a
parallel architecture.  The scheduler takes as its input the assembly
listing produced by a modified, sparc GCC frontend.  I would like to do
some global dataflow analysis on the input file before scheduling it.  But
I run into the following 2 problems when I try to reconstruct the control
flow graph:

Note: The architechture has no call instruction.  Function calls are
performed by storing the return address in the register (rp) and then
branching to the function.  So the first thing I do is to distinguish
branchs from calls by detecting modifications to rp.  Predecessor/succ-
essor relationships are due to branches, not calls.

1) Identifying the first basic block of each function.  The input file
consists of many basic blocks.  I would like to partition them into
different groups such that each group contains basic blocks from one
function.  I can say that any basic block without a predecessor is the
first basic block of some function.  But this would be wrong since it may
be the target of a compute branch.  Actually, this problem is solved once
problem 2 is resolved.

2) Computed branches.  Sometimes 'switch' statements get compiled into a
computed branch where the targets are store in a table in data memory.  I
need to add control flow arcs from the basic block that contains the
computed branch to each of the target basic blocks. 

Has anyone worked on a similar problem?  I would appreciate any advice or
pointers to books/articles that discuss this problem.

-Andrew
--
Andrew Huang			      ahuang@faraday.ece.cmu.edu
Electrical & Computer Engineering     (412) 268-7101
Carnegie Mellon University
[This information is clearly available to the compiler, so I'd take the
direct approach and have the compiler put some comments into the file that
identify entry points, function boundaries, and branch tables. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: pbk@arkesden.Eng.Sun.COM (Peter B. Kessler)
Newsgroups: comp.compilers
Subject: Re: Wanted: a program that calulates the maximal stack depth
Keywords: storage
Date: 10 Apr 92 16:53:25 GMT
Article-I.D.: comp.92-04-046
Reply-To: pbk@arkesden.Eng.Sun.COM (Peter B. Kessler)
Organization: Compilers Central


    On unix machines, what about writing your own version of mcount that
keeps track of the maximum stack size.  Then compile your program for
profiling (which puts a call to mcount at the top of every procedure, and
uses libraries that similarly call mcount).  Depending on how clean you
wanted to be there could be more or less collusion between your mcount
routine and your main program to extract the maximum stack size before
exiting.

    This still only gets you the stack size for the sample runs you make,
not the theoretical limit for your program.

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