HDTenEightyP/NetNews huggingface dataset:
From: acha@CS.CMU.EDU (Anurag Acharya)
Newsgroups: comp.compilers
Subject: Re: Pros and cons of high-level intermediate languages
Keywords: storage, C, question
Date: 24 Jul 92 15:28:33 GMT
Reply-To: acha@CS.CMU.EDU (Anurag Acharya)
Organization: School of Computer Science, Carnegie Mellon University

Olivier.Ridoux@irisa.fr (Olivier Ridoux)
writes about something called abstract memory that solves problems relating
to GC as well as tail recursion.

I would like to know more about "abstract memory" and how it solves these
problems.

>>An optimistic final note.  On one hand, the generated code seems to break
> the admitted dimensions of human programming: huge identifiers made of
> several layers of prefixes, tags or module names, huge expression (e.g. in
> our scheme the unification subprogram of every clause is made in a single
> conjunctive expression (&&)), etc.>On the other hand, it is hard knowing
> the limits of an actual C compiler.  However, we never met them.  In our
> experiments, we only met problems with cpp.

I am surprised. You must definitely be lucky. C compilers have a host of
limitations. Off the top of my head:

1. Size of individual functions
2. Number of cases in a switch statement (many compilers allow 500)
3. Number of typedefs ina file (one compiler had a quaint limit, 768. )
4. Size of source file
5. Size of static initializations
6. Number of symbols in initializations

Some compilers allow you to modify these limits by using obscure undocumented
options which differ from compiler to compiler.

Wish list:

1. label variables. Any kind of label variables with any resonable
restrictions

   (statically scoped, no jumping to inside blocks etc.). This would
   greatly facilitate compilation of both functional languages and parallel
   languages. It would also facilitate parallelizing compilers for other
   languages. To this, add a C compiler that does not limit the size
   of individual functions and you are close to using C as an assembly
   language

2. A portable way of looking at the stack. Supporting  garbage collection
   and call/cc (user-level continuations) would be easier if one could 
   traipse up and down the C stack. Currently, such schemes are machine and
   compiler dependent. 

3. Some form of global register assignment. Some annotation scheme that
   allows me to indicate to the C compiler that I would like a particular
   global variable to be stuck in a register (may be a particular register
   if I am willing to give up portability).

anurag
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: scott@bbx.basis.com (Scott Amspoker)
Subject: Re: Pros and cons of high-level intermediate languages
Reply-To: scott@bbx.basis.com (Scott Amspoker)
Organization: BASIS International, Ltd., Albuquerque NM USA
Date: Sat, 25 Jul 1992 22:49:57 GMT
Keywords: C, translator

graham@maths.su.oz.au (Graham Matthews) writes:
>As to high-level intermediate languages the biggest problem I see is
>making sure that the user gets meaningful errors. On many languages I have
>used that translate into C one gets C compiler error messages at times as
>part of the language level error messages. YUK!

That's what I meant when I said to approach such "front ends" as full
compilers.  To generate C code, a proper front end must understand
everything being being fed to it and how the C compiler will deal
with it.  Generated code must *never* have compile errors.

-- 
Scott Amspoker
Basis International, Albuquerque, NM

scott@bbx.basis.com

-- 
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
From: zmadan@saathi.ernet.in (P. Madhan)
Subject: Cross-Compiler for 68HC11A1
Reply-To: zmadan@saathi.ernet.in (P. Madhan)
Organization: National Centre for Software Technology, Bombay, India.
Date: Thu, 23 Jul 1992 04:06:08 GMT
Keywords: C, question

Does anybody know of an available C- cross compiler for 
  68HC11A1 Micro-controller  on DOS environment.
  Any pointers to FTP sites would also be helpful.
  Thanks in advance..
[I'm sure I've seen 6800 cross compilers advertised in Byte. -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: Elliot H. Mednick <elliot@wellspring.com>
Subject:   Interactive stamtment execution
Reply-To: Elliot H. Mednick <elliot@wellspring.com>
Organization: Wellspring Solutions
Date: Wed, 29 Jul 1992 17:32:49 GMT
Keywords: yacc, interpreter, question

I am writing an interpreter that uses YACC to parse the language.  I want
the interpreter to also be able to execute statements interactively.  I
would like to use the same YACC description file to parse both the program
and the interactive statements, which are identical to the procederal
statements.  However, there are some difficulties.

The language that is to be parsed includes header and declarative
information that YACC needs to know about, as well as the procedural
statements.  In "interactive mode", entering declarations would be
illegal; only the statements would be allowed.  At the top level, a common
YACC description might look something like this:

S
 : program
 | statement
 ;

program
 : header declaration statment_list
 ;
...

However, I want YACC to distinguish between parsing a program file and
parsing interactively: i.e. flag syntax errors if a program does not have
declaration and header info and if declaration info is typed
interactively.

The obvious alternative is to use two YACC descriptions.  The big problem
with two descriptions is that the vast majority of the description would
be common between the two files, since the same statements are used and
they would have the same actions.  I am considering using BISON since the
sources are avalable, and modifying it to support file inclusion; except
that the interpreter would be sold commercially.

Are there techniques for using the SAME YACC file for parsing different
aspects of a langauge, while excluding undesired aspects?  If not, is
there a way to use a common description for two YACC files?  And if not
for that, any suggestions on a small source control mechanism for ensuring
both files are up to date w.r.t each other?

Thanks in advance.
-Elliot
-- 
Elliot H. Mednick                                        P.O. Box 150
Wellspring Solutions                                     Sutton, MA. 01590
elliot@Wellspring.com                                    +1 508 865 7271
[The easiest technique is to use a fake initial token to distinguish the
two cases, e.g.:

toplevel: FAKE1 single-statement | FAKE2 statement-list ;

and have the lexer return the appropriate initial fake statement.  A harder
problem is to have the lexer return an end marker at the end of a single
statement when the syntax doesn't make that obvious. -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: andrewd@cs.adelaide.edu.au (Andrew Dunstan)
Subject: Efficient generation of LALR(1) look-aheads in Parser Generators
Reply-To: andrewd@cs.adelaide.edu.au (Andrew Dunstan)
Organization: Compilers Central
Date: Mon, 27 Jul 1992 06:01:00 GMT
Keywords: yacc, performance, question


Berkeley yacc uses the algorithm from DeRemer and Pennello.  So does
Bison.  Original yacc uses an old and horribly inefficient algorithm.


There was a paper later than DeRemer and Penello by Park etc., which
apparently had a much more efficient algorithm, although the paper
itself is even harder to follow than that of DeRemer and Pennello,
which is saying something!

Does anybody know of a publicly available implementation of this
algorithm?


-- 
Andrew Dunstan
Department of Computer Science
University of Adelaide
South Australia
net: andrewd@cs.adelaide.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: henry@zoo.toronto.edu (Henry Spencer)
Subject: Re: Pros and cons of high-level intermediate languages
Reply-To: henry@zoo.toronto.edu (Henry Spencer)
Organization: U of Toronto Zoology
Date: Thu, 23 Jul 1992 17:03:03 GMT
Keywords: C, optimize

shankar@sgi.com (Shankar Unni) writes:
>This is totally bogus. Let us assume that the ANSI spec were to say: local
>variables are guaranteed to retain their values when a longjmp() takes you
>back to the stack.
>
>Now how would this be done on a machine with several registers ...

The right way to do it is to have the compiler recognize the presence of
setjmp() -- ANSI C carefully restricts setjmp() usage so this is
guaranteed to be possible -- and take suitable precautions.

That is a little tricky in a simple one-pass compiler.  What such a
compiler can do, however, is note the presence of the <setjmp.h> header,
and take worst-case precautions for code compiled with that header
visible.

Historical practice is to say that variables marked "register" can lose
their values, and others can't.  Any compiler smart enough to silently
promote variables into registers ought to be able to handle one of the
above strategies.

And yes, some of us said these things to X3J11, but they didn't listen...
-- 
Henry Spencer @ U of Toronto Zoology, henry@zoo.toronto.edu  utzoo!henry
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: quanstro@stolaf.edu (goon)
Subject: Re: Interactive stamtment execution
Reply-To: quanstro@stolaf.edu (goon)
Organization: St. Olaf College, Northfield, MN USA
Date: Thu, 30 Jul 1992 13:40:20 GMT
Keywords: interpreter, yacc

elliot@wellspring.com (Elliot H. Mednick) writes:
 [how can I use one parser for both interactive and batch parsing?]

 The language that is to be parsed includes header and declarative
 information that YACC needs to know about, as well as the procedural
 statements.  In "interactive mode", entering declarations would be
 illegal; only the statements would be allowed.  At the top level, a common
 YACC description might look something like this:

   S
    : program
    | statement
    ;

   program
    : header declaration statment_list
    ;

Just modify the productions.

   header
    : ...			{ if (interactive) YYERROR; ...}

   declaration
    : ...			{ if (interactive) YYERROR; ...}


Or if you want to get really fancy, then make the lexer
interactiveness-aware.

PS: Whenever designing a language that is supposed to be interactive _and_
batch, I think long and hard about doing anything dependent on the output
of isatty(). It's awful confusing for the user, especially when something
typed in interactively gives errors when cut-and-pasted into a file, or
conversely If you can manage to get along without the headers and
declarations in interactive mode, why bother? If you allow headers and
declarations in batch mode, why bother making them illegal in interactive
mode.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: Olivier.Ridoux@irisa.fr (Olivier Ridoux)
Newsgroups: comp.compilers
Subject: Re: Pros and cons of high-level intermediate languages
Keywords: C, translator
Date: 23 Jul 92 08:18:04 GMT
Article-I.D.: comp.92-07-074
Reply-To: Olivier.Ridoux@irisa.fr (Olivier Ridoux)
Organization: Compilers Central


ssp@csl36h.csl.ncsu.edu (Santosh Pande) writes:
>	I am interested in knowing the pros and cons of using an
>intermediate language (IL) in general. In particular I find 'C' has been
>used extensively as the IL in many situations: Modula, SISAL, AT&T Cfront
>for C++ etc.

My comment is based on using C as an IL for compiling LambdaProlog.
However, the specifics of LambdaProlog do not matter here.

boehm@parc.xerox.com (Hans Boehm):
> I know of three problems:
> a) (the one I'd personally most like to see fixed) The treatment of source
> languages that require garbage collection is tricky.  It appears that the
> only way not to lose appreciably in performance (and this is a bit
> controversial) is to use a conservative garbage collector.  

We use another way.  All the memory management has been packaged into an
abstract memory.  What the generated C programs do is to use this memory.

> b) Languages such as Scheme that "require" tail recursion elimination are
> problematic.  

Like Prolog, LambdaProlog has a procedural semantics.  Though we map
LambdaProlog procedures (predicates) on C functions, we do not map
LambdaProlog procedure calls on C function calls.  In other words, we do
not map LambdaProlog stack on the C stack.  We use instead the abstract
memory mentioned above.

My general idea is that when two concepts are only approximately
equivalent it is asking for problems to try mapping one onto the other.

> c) It's hard to efficiently implement a
> compilation strategy that allocates activation records in the heap.  Some
> of the cleverer implementations of first-class-continuations are hard to
> express in C code.

The abstract memory again does the job.  Our execution scheme is
continuation based.  The continuations (there are four of them because of
non-determinism and other things) are all first-class objects.

I like to add a fourth problem:

d) There is no first-class label data-type.  One can neither store and
read labels, nor goto stored labels.  I know about switch-statements, but
it usually breaks the structure of the generated code.  For this problem,
PL/1 would be a far better IL.

An optimistic final note.  On one hand, the generated code seems to break
the admitted dimensions of human programming: huge identifiers made of
several layers of prefixes, tags or module names, huge expression (e.g. in
our scheme the unification subprogram of every clause is made in a single
conjunctive expression (&&)), etc.  On the other hand, it is hard knowing
the limits of an actual C compiler.  However, we never met them.  In our
experiments, we only met problems with cpp.

Olivier Ridoux
(ridoux@irisa.fr)
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: suzi@linus.mitre.org
Subject: Flex question
Reply-To: suzi@linus.mitre.org
Organization: Compilers Central
Date: Fri, 31 Jul 1992 01:05:44 GMT
Keywords: flex, question

I have been trying to determine what it is in flex rules that causes the
yy_nxt and yy_chk tables to increase in size, but am not getting anywhere.
Can anyone suggest any rules of thumb to keep these tables at a minimum?
I'm under a deadline and would appreciate suggestions as quickly as
possible, so please email me in addition to posting to the net so everyone
can see the answers.  Thank you for your help!

suzi@mitre.org
(617) 271-8963
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: graham@maths.su.oz.au (Graham Matthews)
Subject: Re: Pros and cons of high-level intermediate languages
Reply-To: graham@maths.su.oz.au (Graham Matthews)
Organization: Sydney University Computing Service, Sydney, NSW, Australia
Date: Sat, 25 Jul 1992 01:57:13 GMT
Keywords: translator, design

(Santosh Pande) writes:
>I am interested in knowing the pros and cons of using an
>intermediate language (IL) in general. In particular I find 'C' has 
>been used extensively as the IL in ..
>..
>	(1) I am looking for examples in which using C as IL will lead to
>inefficiencies,

(Hans Boehm) writes:
>a) (the one I'd personally most like to see fixed) The treatment of 
>source languages that require garbage collection is tricky.  It 
>appears that the only way not to lose appreciably in performance 
>(and this is a bit controversial) is to use a conservative garbage 
>collector.  But the C standard does not guarantee that C compiler 
>optimizations are safe in the presence of such a collector. 

I am not sure I understand what you are talking about here Hans.  As far
as I can see if the C code you produce is not safe in the presence of
garbage collection then you are generating incorrect C code. There is
nothing in C that makes it "garbage collection unsafe" even with a
non-conservative garbage collection.

For example say you have something of the form

	access_to_memory = function_that_causes_garbage_collection

Now if you compile this directly into C you are in trouble as C
does not define the order of evaluation of the lhs with respect
to the rhs (if the rhs is done first you are ok otherwise you
have problems).

However this problem can be handled by compiling into C code of
the form,

	temp = function_that_causes_garbage_collection;
	access_to_memory = temp;

This construction forces the order of evaluation you require.  If an
optimizer "optimises" this code back to the original form then your
optimiser is incorrect.

So as far as I can see C is not unsafe in the presence of garbage
collection as long as you are careful in your code emission. Your code
will not be as fast as native C but then as far as I can see there is no
way to avoid forcing the order of evaluation in any general solution to
the above probelm so C will do no worse than any other system.

Perhaps you have some specific problems in mind ...

graham
--
Graham Matthews
Pure Math, Uni.Sydney, Oz
graham@maths.su.oz.au
[The usual problem is to identify all possible live data, notably that
pointed to by variables on the stack and in registers. -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: hoekstra@cs.utwente.nl (Aarnoud Hoekstra)
Subject: compiler for GAL
Reply-To: hoekstra@cs.utwente.nl (Aarnoud Hoekstra)
Organization: University of Twente, Dept. of Computer Science
Date: Mon, 27 Jul 1992 07:53:19 GMT
Keywords: hardware, question

Hi there,

I'm looking for a compiler which compiles boolean expressions
into JEDEC code. I need it in order to be able to program 
programmable logic devices (e.g. GAL, PAL etc.).

Is there anyone who is able to telle me if there is such a
compiler (P.D.) ?

8-)

Aarnoud Hoekstra
Department of Computer Science
University of Twente
hoekstra@cs.utwente.nl
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: bertele@eniac.seas.upenn.edu (George K. Bertele)
Subject: C compiler info needed
Reply-To: bertele@eniac.seas.upenn.edu (George K. Bertele)
Organization: University of Pennsylvania
Date: Mon, 27 Jul 1992 23:50:00 GMT
Keywords: C, IBM, question


Hi out there, I was looking for any information on where to get a C
compiler for the IBM AS/400.  The obvious answer is of course to get one
from IBM.  We did get that one here at work, but we would like to compare
and contrast with other compilers to get a better idea of the various
features/speeds/etc of some other packages.  

If anyone out there could either tell me about a C Compiler that they use
or know of, that would be great, or if anyone could tell me where to get
this type of information, that would help also.  Infact, even a company
out there that does programming in C on the 400 might also be of
help....so the point is, any info. is appreciated.  Please send e-mail
replies if at all possible.

                                    Thanks,
			            George Bertele
                                    bertele@eniac.seas.upenn.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: Paul H J Kelly <phjk@doc.imperial.ac.uk>
Subject: Software address translation - request for info
Reply-To: Paul H J Kelly <phjk@doc.imperial.ac.uk>
Organization: Compilers Central
Date: Tue, 28 Jul 1992 22:25:54 GMT
Keywords: architecture, question

We need a way of applying a non-trivial mapping to every data address
issued by a C program.

One reason why we need this is to simulate the effect of a page table so
we can run VM programs (in particular prototypes of an operating system)
on machines without memory management hardware.

The mapping we want to apply varies:
 - sometimes just adding each address to a base value (which might 
   change during execution),
 - more generally indirecting through a full address translation
   table.

We have considered several approaches:
 1) Post-process the assembler and intercept all loads and store
    instructions.
 2) modify the back end of a retargetable compiler (e.g. gcc) to
    generate C instead of assembler, so we can then redefine
    a couple of macros used in the generated C to change the mapping,
 3) Write a front-end preprocessor, which modifies the C concrete or
    abstract syntax to introduce the mapping,
 4) Run standard binary as emitted by the C compiler, under a
    simulator (e.g. spim) - then modify spim to perform address 
    translation.

These all have different advantages and disadvantages.  My favourite is
(2), as it seems most flexible.

Can anyone provide me with any pointers to existing tools which can help
us?  Surely we're not the first with this requirement!

I will of course try to produce a summary of responses.

Yours with many thanks,

        Paul Kelly
 
 Dept. of Computing, Imperial College, 180 Queen's Gate, London SW7 2BZ, UK
 (telephone (+44 71) 589 5111 extension 5028, fax: +44 71 581 8024)
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: gt0554c@prism.gatech.edu (MCCONNELL)
Newsgroups: comp.compilers
Subject: Low level intermediate representations.
Keywords: question
Date: 22 Jul 92 23:08:16 GMT
Reply-To: gt0554c@prism.gatech.edu (MCCONNELL)
Organization: Georgia Institute of Technology

Where can I get more detailed information about low level IR's? I know
about tuples and stack representations in general but I was hoping for
some more detailed information. Can someone suggest some journal articles
perhaps?

Thanks,
Dwayne McConnell
gt0554c@hydra.gatech.edu
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers