HDTenEightyP/NetNews huggingface dataset:
From: eggert@twinsun.com (Paul Eggert)
Newsgroups: comp.compilers
Subject: Re: constant folding vs exceptions
Keywords: parse, optimize
Date: 28 Aug 92 20:59:16 GMT
Article-I.D.: comp.92-08-174
Reply-To: eggert@twinsun.com (Paul Eggert)
Organization: Twin Sun, Inc

henry@zoo.toronto.edu (Henry Spencer) writes:
> In fact, ANSI C handed down a much stricter line on this:....
> The only restriction is that if overflows are
> visible, optimizations can't add or remove overflows.

Actually, in ANSI C, the behavior on overflow is undefined, so a
conforming implementation optimization can remove overflows.

Spencer's right that the Ritchie compiler's treatment of integer overflow
was broken, but unfortunately the C Standard lets a compiler behave in
this way.  (C's not alone in this regard, of course; e.g. the Fortran
standard has the same problem.)  That's too bad, since the problems that
it leads to can be quite mysterious.  For example, in the following code:

	i = 0;
	if (0 < j)
		i = j;
	assert (0 <= i);

integer overflow can cause the assertion to fail!

There's a trick to this, of course.  Here's a complete C program
containing the above code.  Assume a 32-bit int.

	#include <assert.h>
	int big = 2147483647;
	main() {
		int i, j;
		j = big + 1;  /* This overflows.  */

		i = 0;
		if (0 < j)
			i = j;
		assert (0 <= i);
	}

Suppose the compiler optimizes `main's body into something like this:

		j = big + 1;  /* This overflows.  */

		i = 0;
		if (0 <= big)
			i = j;
		assert (0 <= i);

The C Standard allows this optimization, because it works when `big + 1'
does not overflow, and the code can do anything it pleases when `big + 1'
_does_ overflow.  However, I suspect most programmers would say this
optimization is incorrect, because it gives `i' a negative value when
`big' is INT_MAX.

This is not a contrived example.  I derived the above program from a bug I
encountered when building DEC SRC Modula-3 with GCC 2.2.2 -O on a Sparc.
Happily, though, the GCC maintainers are programmers, not language
lawyers; they've agreed that this behavior is a bug, and it'll be fixed in
the next release.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: daveg@fairfax.com (David Gorsline)
Newsgroups: comp.compilers
Subject: Re: Error productions in YACC/Bison
Keywords: yacc, errors, bibliography
Date: 25 Aug 92 13:02:40 GMT
Reply-To: daveg@fairfax.com (David Gorsline)
Organization: Compilers Central

ertle@newton.emba.uvm.edu (Jim Ertle) writes:
> Are there any good books on YACC/Bison that have chapters on error
> productions?

I recommend Schreiner and Friedman, _Introduction to Compiler Construction
with UNIX_ (Prentice-Hall, 1985) (sometimes known as "the unicorn book").
I use their technique in the commercial 4GL I'm writing.
--
David L. Gorsline           Fairfax Software Corp.         (703)222-3500 (vox)
dgorsline@fairfax.com       12450 Fair Lakes Cir           (703)222-8433 (fax)
uunet!fairfax!dgorsline     Fairfax, VA 22033 USA
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: daniel@dolores.stanford.edu (Daniel Weise)
Newsgroups: comp.compilers
Subject: Online Bibliography for Macro Processors for HL languages sought.
Keywords: macros, comment
Date: 25 Aug 92 20:13:43 GMT
Reply-To: daniel@dolores.stanford.edu (Daniel Weise)
Organization: Computer Systems Laboratory, Stanford University

I've been doing research on adding syntax macros to modern languages.  I'm
about to type in 25 or so references, and thought that maybe someone out
there already has an online (latex) bibliography I could use.  If you have
an extensive bibliography that includes work from the 60's (eg,
Leavenworth's 1966 paper on Syntax Macros, and Cheatham's 1966 AFIPS
paper) and 70's (eg, Cole's monograph on macro processors), could I have a
copy?  On a super long-shot: anyone have a copy of J. Vidart's PhD thesis
"Extensions syntaxiques dans une contexts LL(1)," 1974?

Thanks,
Daniel Weise

PS. if anyone is working in this field (it's only been abandoned
now for about 15 years!), I'd like to know of it.

PPS. "Syntax Macros" are macros that run during parse time, and where
the matching, substitutions, and manipulations are based on AST's, not
on character strings.
[It's my impression that people gave up on them in languages with
conventional syntax because they gave you the ability to devise a language
that was arbitrarily obscure and hard to read while no more powerful than
it was before you started.  That was my experience with IMP72.  But I
suspect that people in the Lisp community would be surprised to hear that
syntax macros are dead.  Lisp macros are very useful because they're fully
integrated with the rest of Lisp.  You can do semantically interesting
things with them.  -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: wang@minos.inria.fr
Newsgroups: comp.compilers
Subject: interaction between loop scheduling and register allocation
Keywords: registers, optimize
Date: 26 Aug 92 08:08:20 GMT
Reply-To: wang@minos.inria.fr
Organization: INRIA, Rocquencourt

I am working on loop scheduling and register allocation and try to
combine these two phases into a single phase. Would you please tell me
whether or not there is any published paper about the interaction between
loop scheduling and register allocation and the algorithms for combining 
these two parts?

Sincerely,
Jian Wang
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: khattra@sfu.ca (Taj Khattra)
Newsgroups: comp.compilers
Subject: Re: Dealing with Multiple Inheritence in an Object-Oriented Language
Keywords: OOP, design, bibliography
Date: 3 Sep 92 05:36:02 GMT
Reply-To: khattra@sfu.ca (Taj Khattra)
Organization: Simon Fraser University, Burnaby, B.C., Canada

"Ed Cynwrig Dengler" <eadengle@watcgl.uwaterloo.ca> writes:
>I am trying to find references to articles that deal with the problems of
>dealing with and representing multiple inheritence in a compiled program.

You may want to take a look at -

   Stroustrup, Bjarne, _Multiple Inheritance for C++_, Proceedings of
   the EUUG Spring Conference, May 1987.

(It is reprinted in _AT&T C++ Language System Selected Readings_) 
--
Taj Khattra
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: horst@techfak.uni-bielefeld.de (Horst Hogenkamp)
Newsgroups: comp.compilers
Subject: Re: Parsing wars
Keywords: parse, LR(1)
Date: 2 Sep 92 13:58:53 GMT
Reply-To: horst@techfak.uni-bielefeld.de (Horst Hogenkamp)
Organization: Universitaet Bielefeld, Technische Fakultaet.

In article <92-09-006@comp.compilers>, dww@inf.fu-berlin.de writes:
> The parsing is called shift-reduce parsing, and I thought I had understood
> that. What happens on a reduction though is, instead of pushing the
> nonterminal of the lhs of the reduced production onto a symbol stack and
> digging through the goto table for the appropriate state to push onto the
> state stack, the nonterminal is *prepended* to the input sequence of
> tokens and parsing resumes as normal. The other actions, shift, accept and
> error are as expected, an action shiftreduce combines the normal shift and
> the strange reduce.


In the traditional Aho-Sethi-Ullman-parser (p.219) there is an implicit
shift appended to every reduce.  This is some kind of partial evaluation
because it is not always possible to write things back to your input.


> [It sounds to me like a way to combine the shift and goto tables, since
> pushing the nonterminal and then shifting it would be equivalent to a
> goto.  -John]


Exactly this is the case.  Terminal symbols and nonterminal symbols are
not distinguished.  The goto table is merged into the action table such
that "goto[s,A]=i" becomes "action[s,A]=shift i".  This can make things
easier.

Now you can have terminal symbols as well as nonterminals in the input,
which is needed for example in program transformation systems.
Consider the rule:
    EVAL(E:expr "+" "0") => EVAL(E)
The the parser's input for the lhs would be:
    expr "+" "0"
This would be impossible to parse with a traditional shift-reduce parser.

I have done this (as well as other things) in my masters thesis in 1988/89
and it works very well but I reinvented the wheel.  I once saw an article
on exactly this topic but I forgot the reference.

Horst Hogenkamp
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: hws@sagitta.csis.dit.csiro.au (Heinz Schmidt)
Newsgroups: comp.compilers
Subject: Representing unions of Cartesian products
Keywords: theory, design
Date: 3 Sep 92 05:21:51 GMT
Reply-To: hws@sagitta.csis.dit.csiro.au (Heinz Schmidt)
Organization: CSIRO Div Info Tech & Australian Ntl Univ, Canberra


  > I am looking for an efficient way to store and manipulate unions of
  > Cartesian products. 

Sounds similar to object-oriented type lattices to me, with your Cartesian
products corresponding to constructor types at the bottom and abstract or
virtual types forming the unions. I may be way off though.

Take a look at      Ait-Kaci et al:
                    Efficient Implementation of Lattice Operations 
                    Toplas 11(1), 1/89.

  > represents C_1 - C_2.  (The operator - denotes the subtraction of sets ...

They also consider relative complements (set difference / but-not).  At
least for inheritance lattices (which I tend to visualize as low-degree
except for artificial bottom and top, broad and flat, with few outlyers in
depth), they achieve near O(1) meet, join and relative complement
operations on bit vectors representing compressed transitive closures. A
further compaction called modulation results in O(N log N) space
requirements but may hit efficiency of meet and rel complement depending
on the structure of the lattice.

Heinz W. Schmidt                  hws@csis.dit.csiro.au
CSIRO, Div Information Technology tel ++61 6 275-0974
and                               fax ++61 6 257-1052
Aus Natl Univ, Dept Comp Science  Canberra, Australia   
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
Newsgroups: comp.compilers
Subject: Re: Semantics Tools
Keywords: theory, bibliography, comment
Date: 28 Aug 92 22:11:48 GMT
Article-I.D.: comp.92-08-175
Reply-To: eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig)
Organization: The Johns Hopkins University CS Department

Jonathan.Bowen@prg.oxford.ac.uk (Jonathan Bowen) writes:
>eifrig@beanworld.cs.jhu.edu (Jonathan Eifrig) writes:
>>	Curiously, I was wondering something related: How many people are
>>using formal semantic methods to either (1) generate a compiler or (2)
>>prove a compiler correct in "real life?"

>At Oxford, we are studying the verification of compiling specifications,
>and their rapid prototyping using logic programming.

	I think perhaps you're misinterpreting my posting, and I just want
to clarify my question: I'm curious as to whether or not any of the
semantics-based techniques for compiler generation have made it
"off-campus" into the real world.  My rule of thumb is whether or not some
scheme has generated a compiler that is intrinsically interesting to
someone other than those who made it.

	For example, the ORBIT compiler for Scheme was actually used at
Yale as its installed Scheme compiler, I believe, as part of its T system;
this is the earliest example of a continuation-passing style compiler that
I know of that made it out into the real world.  (Earlier examples
welcomed!)  Hundreds, if not thousands, of commercial products have been
made with lex/yacc parsers, moving LALR parsing into the real world.

	But has anyone used, say, Lee's MESS system to make something like
the "Gorgunza C" compiler?  And if not, why not?

ObRefs:

@string{scc86 = "Proceedings of the 1986 ACM SIGPLAN Symposium on Compiler
	Construction"}

@inproceedings{kranz86,
author = "David Kranz and Richard Kelsey and Jonathan Rees and Paul Hudak
	and James Philbin and Norman Adams",
title = "ORBIT: An Optimizing Compiler for Scheme",
booktitle = scc86,
year = 1986,
pages = "219--253"
}

@book{lee89,
author = "Peter Lee",
title = "Realistic Compiler Generation",
publisher = "MIT Press",
year = 1989,
series = "Foundations of Computing"
}
[Yes, ORBIT is the compiler in T.  My impression from reading Lee's book
is that MESS is indeed pretty messy, not well enough packaged for others
to use.  And packaging is important: yacc became the most widely used
parser generator not because it broke any new ground in LR parsing ("ya"
stands for "yet another", after all) but because it was a lot easier to
use than any of the others available in the early 1970s. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: fm04@rummelplatz.uni-mannheim.de
Newsgroups: comp.compilers
Subject: Re: A Non-LALR(1) Parser Generator
Keywords: parse, LALR, LL(1), comment
Date: 25 Aug 92 14:55:46 GMT
Reply-To: fm04@rummelplatz.uni-mannheim.de
Organization: RUM

There's also another Non-LALR parser generetor: "ell". It's part of a
compiler toolbox and processes LL-Grammars with EBNF notation.  Here's an
extract of the README file from the distribution:

	     Lalr is a LALR(1) parser generator accepting grammars  writ-
	ten  in  extended BNF notation which may be augmented by semantic
	actions expressed by statements of the target language.	[...]

	     Ell is a LL(1) parser generator accepting the same  specifi-
	cation  language  as  Lalr except that the grammars must obey the
	LL(1) property. It  is  possible  to  evaluate  an  L-attribution
	during parsing. The generated  parsers  include  automatic  error
	recovery,  error  messages,  and  error  repair  like  Lalr.  The
	parsers are implemented following the  recursive  descent  method
	and  reach a speed of 810,000 lines per minute. The possible tar-
	get languages are again C and Modula-2."

You get get the sources & documentation from:
	iraun1.ira.uka.de (/pub/programming/cocktail)

Look at the README file for Information about Authors, Copyrights, Instal-
lation, etc.

	- Michael
-- 
Michael Utech, Max-Planck-str.26, 6806 Viernheim, Germany (06204/4031)
email:	fm04@rummelplatz.uni-mannheim.de, utech@informatik.uni-kl.de, 
[See message 92-03-025 for more details on Cocktail. -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: "Ed Cynwrig Dengler" <eadengle@watcgl.uwaterloo.ca>
Subject: Dealing with Multiple Inheritence in an Object-Oriented Language
Reply-To: "Ed Cynwrig Dengler" <eadengle@watcgl.uwaterloo.ca>
Organization: Compilers Central
Date: Tue, 1 Sep 1992 14:05:23 GMT
Keywords: OOP, design

Greetings!

I am trying to find references to articles that deal with the problems of
dealing with and representing multiple inheritence in a compiled program.
I am also interested in any articles that deal with how large typical
object-oriented classes get (ie. how many features/routines does a typical
class define, how many classes are typically inherited from, how deep the
inheritence tree gets, how often a feature is renamed).

The only reference I have currently is "An Object Addressing Mechanism for
Statically Typed Languages with Multiple Inheritence" by R.C.H.  Conner,
A. Dearle, R. Morrison, and A.L. Brown.

The reason for this request is that I am doing a project evaluating
modification of the "map" system presented in the above article, and would
like to compare the original "map" system and the modified one to any
other methods out there.

For example, assuming I had the following class structure:
                A.a
                 .b
               /   \
             B.c   C.d (renamed from A's b)
              .e    .c
               \   /
                D.f
                D.g (renamed from C's c)

where: class A has the features a,b
       class B has the features a,b,c,e
       class C has the features a,d,c
       class D has the features a,b,c,d,e,f,g

I am trying to find answers to the following questions:
    a) What other schemes are there?
    b) How is multiple inheritence handled (this includes what restrictions
       the scheme forces on multiple inheritence)?
    c) If an object is assigned to a variable that is of an inherited class
       type, how is the object changed to allow correct addressing of the
       fields/features/routines (eg. an object x of class D is assigned
       to variable y of class C, how is y.c handled)?
    d) Approximately how long would it take to do the assignment and/or
       find a given feature in a variable?
    e) How much space does the cheme take up?

Any references to articles would be greatly appreciated!

Thanks in advance,
Ed Dengler
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:1482 comp.lang.c:13058
From: g89r4255@hippo.ru.ac.za (Lt Sajid Rahim)
Newsgroups: comp.compilers,comp.lang.c
Subject: Require source code for Micro-C. (Request).
Summary: Micro-C
Keywords: C, question
Date: 31 Aug 92 11:47:59 GMT
Reply-To: g89r4255@hippo.ru.ac.za (Lt Sajid Rahim)
Organization: Rhodes University, Grahamstown, South Africa

I am desperately looking for the source code for the Micro-C compiler. 

Can anyone other, having the code for the 8088 processor please
uuencode a copy please.

Appreciate all the help.

Sincerely

Sajid
--   Sajid Rahim, Dept of Computer Science, Rhodes University,     --
--   Grahamstown, South Africa. Internet : g89r4255@hippo.ru.ac.za --
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: nickh@CS.CMU.EDU (Nick Haines)
Newsgroups: comp.compilers
Subject: Re: Online Bibliography for Macro Processors for HL languages sought.
Keywords: macros, bibliography
Date: 26 Aug 92 15:20:02 GMT
Reply-To: nickh@CS.CMU.EDU (Nick Haines)
Organization: School of Computer Science, Carnegie Mellon University

On the subject of macros, the paper

Abstract Value Constructors, William E. Aitken & John H. Reppy, ACM
SIGPLAN Workshop on ML and its Applications, 1992

presents an extension to SML which provides useful typesafe macro-like
forms for use in pattern-matching.

Nick Haines nickh@cs.cmu.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: ae24@iamk4516.mathematik.uni-karlsruhe.de (Peter Januschke)
Newsgroups: comp.compilers
Subject: Re: IEEE Floating-Point Package?
Keywords: Pascal, C, arithmetic
Date: 26 Aug 92 08:32:39 GMT
Reply-To: ae24@iamk4516.mathematik.uni-karlsruhe.de (Peter Januschke)
Organization: University of Karlsruhe, Germany

steele@vlsi.cs.caltech.edu (Craig Steele) writes:
> Can anyone point me to a readily available software implementation
> package of IEEE floating-point arithmetic?  C or Pascal source
> would be ideal, but assembly language would do.  Thanks.

Our institute has developed a PASCAL to C compiler for scientific
applications. Its runtime system contains a floating point package based
on the IEEE 754 standard, which is completely written in C.  If you have
interest in the package you should contact the following address :

  Numerik Software GmbH
  P.O. Box 2232
  W-7570 Baden-Baden
  Germany

Dipl.-Math. Peter Januschke
Institute for Applied Mathematics
University of Karlsruhe, Germany
e-mail :   ae24@iamk4516.mathematik.uni-karlsruhe.de  (129.13.129.16)
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: db@dcs.ed.ac.uk (Dave Berry)
Newsgroups: comp.compilers
Subject: Re: Semantics Tools
Keywords: parse, optimize, semantics
Date: 26 Aug 92 15:15:40 GMT
Reply-To: Dave Berry <db@dcs.ed.ac.uk>
Organization: Laboratory for the Foundations of Computer Science, Edinburgh U

We've done some work on producing tools from operational semantics.  In
our case we've looked at debuggers (which are harder than compilers).  In
my thesis I looked at the definition of evaluation step in terms of
operational semantics, and described a system that generated animating
interpreters from an operational semantics.  Fabio da Silva is just
completing his thesis on another, more rigorous, approach.  He includes an
algorithm from generating a deterministic semantics from a certain class
of non-deterministic semantics.

Both our systems require some form of determinacy restriction on the
semantics.  I distinguish between a truly operational semantics, and one
written in the natural semantics style but that doesn't have an immediate
operational interpretation.

Unfortunately neither of us have published much.  I just haven't had the
time since completing my thesis.  We hope to produce a joint paper
sometime.  As yet this is still theoretical work, but something may come
of it someday.

Dave.

-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: chased@rbbb.Eng.Sun.COM (David Chase)
Newsgroups: comp.compilers
Subject: Re: -O4 in SunOS compiler
Keywords: sparc, optimize, C
Date: 1 Sep 92 23:10:58 GMT
Reply-To: chased@rbbb.Eng.Sun.COM (David Chase)
Organization: Sun Microsystems, Mt. View, Ca.

wismuell@Informatik.TU-Muenchen.DE (Roland Wismueller) writes:
>So -O4 has several consequences:
   ...
>  * The compiler may produce 'wrong' code

>The last item is common to all optimizing compilers (at least for C),
>since aliasing analysis relies on some assumptions that must hold for a
>program, e.g.  the sequence 'p = &i; *(p+offset) = 123;' will access (a
>component of) i, but no other variable. Of course, you cannot enforce this
>in C.

What you have there is a case of "undefined behavior" (as specified by the
ANSI and ISO C language standards).  When this is the case, it is not
"wrong" to produce code that has different results depending upon the
optimization level.  Detecting such code is difficult, but not impossible.
(Example implementation -- generate a map for all of memory, and check
each instance of pointer arithmetic and dereferencing to ensure that it
conforms to the C standard.  You may find this too costly, but it is not
at all impossible.)

David Chase
Sun
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: bburshte@pyrps5.eng.pyramid.com (Boris Burshteyn)
Newsgroups: comp.compilers
Subject: USSA object oriented state language
Keywords: FTP, OOP
Date: 26 Aug 92 18:48:45 GMT
Reply-To: bburshte@pyrps5.eng.pyramid.com (Boris Burshteyn)
Organization: Compilers Central

[From the moderator:]
Boris Burshteyn has sent along a paper on his USSA lanuage in postscript
form.  It's too big for the mail server, but will shortly be in the FTP
archive at primost.cs.wisc.edu under the name ussa.ps.Z.

He says it is not clear how soon Pyramid will make USSA available
outside of the company.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.