HDTenEightyP/NetNews huggingface dataset:
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Pros and cons of high-level intermediate languages
Reply-To: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Organization: Computer Science, University of Melbourne, Australia
Date: Sat, 25 Jul 1992 10:21:32 GMT
Keywords: storage, C, question

acha@CS.CMU.EDU (Anurag Acharya) writes:

>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

If you are willing to restrict yourself to gcc 2.X then I think that you
will find what you need here. gcc 2.X supports label variables and
reportedly has no limits on function size. Beware though, that many
optimizers (and I think gcc falls in this category) use algorithms that
are O(n^2) time & space or worse, where n is the length of a function, so
you may find that even though there are no arbitrary hard limits,
compilation becomes unacceptably slow.  (In the worst case, the compiler
thrashes itself to death for a few hours before running out of virtual
memory :-( ).

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

Again, if you are willing to restrict youself to gcc 2.X then this
facility is provided. Unfortunately you *have* to specify which particular
register, so porting will require a bit more work with #if's and so forth.
[You could specify that for machine X, use register A1, for machine Y, use
register SI, for any other machines don't use a register - that way the
code will port easily to any machine, and the extra work is only required
if you want it to be efficient.]

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.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: moss@cs.umass.edu (Eliot Moss)
Subject: Re: Pros and cons of high-level intermediate languages
Reply-To: moss@cs.umass.edu (Eliot Moss)
Organization: Dept of Comp and Info Sci, Univ of Mass (Amherst)
Date: Sat, 25 Jul 1992 13:06:51 GMT
Keywords: C, storage

acha@CS.CMU.EDU (Anurag Acharya) said:

> Wish list:

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

Available from gcc 2.0 and higher; we use it to good effect in our Smalltalk
interpreter (single largest speed improvement we've ever gotten!). So you have
something that's portable from machine to machine, but specific to a given
family of compilers.

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

Sorry, I don't know of any way to do that. And you have to include registers
in the model, too.

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

gcc supports this, but the incantation and possible bad side effects do vary
from machine to machine.
--

		J. Eliot B. Moss, Associate Professor
		Department of Computer Science
		Lederle Graduate Research Center
		University of Massachusetts
		Amherst, MA  01003
		(413) 545-4206, 545-1249 (fax); Moss@cs.umass.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: sja@psg.npl.co.uk (Simon Ashford)
Subject: Re: TTCN and ASN.1 status?
Reply-To: sja@psg.npl.co.uk (Simon Ashford)
Organization: National Physical Laboratory, UK
Date: Mon, 27 Jul 1992 10:54:43 GMT
Keywords: syntax, question


CHUYU%TWNMOCTL.BITNET@pucc.Princeton.EDU writes:
>Is there any one know about TTCN(Tree and Tabular Combined Notation) and ASN.1
>(Abstract Syntax Notation Number One) current status?

The TTCN standard (ISO 9646-3) has reached IS status, and has been
submitted for publication by ISO; extensions to cover concurrency are also
being progressed (not sure of the status of this)

ISO 8824/8825 - ASN.1 Syntax and Basic Encoding Rules - were published as
International Standards in 1990; extensions to the syntax are also being
worked on (8824/DAM1).

>Is there any source code available from academe or Industry?

ISODE (the ISO Development Environment) contains various ASN.1 based
tools, and is freely available. I don't know of any specific TTCN
compilers currently available.

Here at NPL we have been working on a set of tools aimed at making the
production of TTCN test suites easier, using a new form of the notation
called "Developer's TTCN". This can then be turned into standard TTCN when
needed. I'll send you more details if interested.

Hope that helps.

Simon.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: jwo@cs.cornell.edu (John W. O'Leary)
Newsgroups: comp.compilers
Subject: Re: looking for language design help
Keywords: design, bibliography
Date: 21 Jul 92 16:13:48 GMT
Article-I.D.: comp.92-07-067
Reply-To: jwo@cs.cornell.edu (John W. O'Leary)
Organization: Cornell Univ. CS Dept, Ithaca NY 14853

>	Hints on Programming Language Design
>	C. A. R. Hoare
>	Stanford University, Computer Science Department
>	TR CS-73-403, December 1973

This paper is also reprinted in the 1989 collection

    C.A.R. Hoare and C.B. Jones (ed)
    Essays in Computing Science
    Prentice-Hall International Series in Computer Science
    ISBN 0-13-284027-8

-- John O'Leary
-- 
John W. O'Leary jwo@ee.cornell.edu  Ph. 607-255-4323  FAX 607-255-9072
School of Electrical Eng, 338 Theory Ctr, Cornell U, Ithaca, NY  14853
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: tmb@idiap.ch
Subject: Re: Pros and cons of high-level intermediate languages
Reply-To: tmb@idiap.ch
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle Perceptive)
Date: Thu, 23 Jul 1992 20:25:40 GMT
Keywords: C, translator, optimize

boehm@parc.xerox.com (Hans Boehm) writes:

   [various specific problems with generating C code as the output
   of a compiler, related to GC, tail-recursion optimization, etc.]

   My impression is that for vaguely Pascal-like languages (e.g. Mesa),
   compiling through C generally loses very little performance, and may in
   fact win, if it's done sufficiently carefully.  For Scheme or ML-like
   languages, life is a little harder.  You either lose some performance, or
   you have to make some other compromises.

Since C does seem to be accepted and popular as an intermediate
language, it might be worth trying to get the C standard to
incorporate some features that make this particular use easier.

				Thomas.
[How about some suggestions?  Standards are supposed to codify existing
practice, though I freely admit that hasn't often been the case lately. -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: grspangler@ualr.edu
Subject: found language design help
Reply-To: grspangler@ualr.edu
Organization: University of Arkansas at Little Rock
Date: Mon, 27 Jul 1992 15:54:25 GMT
Keywords: design, bibliography, summary

Thanks to everyone that responded.  I received many recommendations and
after wandering around the stacks, because the catalog didn't list any of
the recommended sources, I came across the third edition of _PROGRAMMING
LANGUAGES A Grand Tour_.  It is a collection of articles and it contains
several of the ones mentioned in your messages.  Again, thanks for your
help.

===========================================================================
USMailNet: Guy R. Spangler  2801 S University Ave  Little Rock, AR  72204
AT&TNet:   (501)569-3345
InterNet:  GRSPANGLER@UALR.EDU
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: e86jh@efd.lth.se (Jens Hansson)
Newsgroups: comp.compilers
Subject: Re: looking for language design help
Keywords: design
Date: 22 Jul 92 20:32:12 GMT
Article-I.D.: comp.92-07-071
Reply-To: e86jh@efd.lth.se (Jens Hansson)
Organization: Lund Institute of Technology, Sweden

CTRL-Z <grspangler@ualr.edu> writes:

>I have some vague ideas floating around in my head
>that I'd like to develop, but I don't have the first clue about how a
>language is designed or the things I should consider when designing it.

There were two articles in comp.compilers dated 18. Aug 91 & 19. Aug 91
with the subject 'Re: Writing fast compilers II  rs/6000' covering some
important questions on programming language design. I suppose you can find
them in the archives.

Greetings!
*****************************************************************
Jens Hansson   e-mail: e86jh@efd.lth.se Phone int+46-(0)46-112295
snail-mail:    Skarpskyttev 6B,      S-22242 Lund,         Sweden
[See messages 91-08-079, 91-08-080, and 91-08-086. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: sewardj@cs.man.ac.uk (Julian Seward)
Subject: Re: Pros and cons of high-level intermediate languages
Reply-To: sewardj@cs.man.ac.uk (Julian Seward)
Organization: Department of Computer Science, University of Manchester
Date: Sun, 26 Jul 1992 11:30:52 GMT
Keywords: bibliography, translator

Graham Matthews writes:

| (Olivier Ridoux) writes:
| >d) There is no first-class label data-type.  One can neither store and
| >read labels, nor goto stored labels.  
|
| I think you will find that gcc 2.X allows you to have arrays of labels.
| Any gcc experts out there to confirm this?

I am surprised no-one has picked up on this.  Sure, C doesn't allow labels
as first class citizens, but procedure names *are*.  The Glasgow Haskell
Compiler uses C as a back end.  Each basic block is compiled into a
parameter-less C procedure.  When a basic block is done, it *returns* the
address of the next block to be executed (which is some C procedure).  The
whole system is driven by a magic 1-line "interpreter" like this:

   while (TRUE) { cont = (*cont)(); }

so that "cont" is the address of the next code block to be executed.  This
works, is uses no non-standard extensions, but is somewhat inefficient.
At the cost of portability, one can use non-standard extensions in GCC
1.XX and 2.X to genuinely to direct jumps from one code block to the next,
and various other optimisations like suppressing register load/saves.

All this magic is described in Simon L Peyton Jones's paper.

It should be pointed out this is not a new idea.  Apparently Guy Steele
used this in the Rabbit compiler for Scheme, and also for a SML compiler
in the reference below.

Jules

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

D Tarditi, A Acharya and P Lee [March 1991]. "No assembly required:
compiling Standard ML to C", School of Computer Science, 
Carnegie Mellon University.

Simon L Peyton Jones [1992].  "Implementing lazy functional languages on
stock hardware: the Spineless Tagless G-machine".  Department of Computing
Science, University of Glasgow, UK.  To appear in the Journal of
Functional Programming, and available by anonymous FTP from
ftp.dcs.glasgow.ac.uk:/pub/glasgow-fp/papers/spineless-tagless-gmachine.dvi
[This is known as continuation passing form; Andrew Appel's book which was
discussed here recently is all about how he built an ML compiler that works
that way.  -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: ssp@csl36h.csl.ncsu.edu (Santosh Pande)
Subject: C as IL on parallel platforms
Reply-To: ssp@csl36h.csl.ncsu.edu (Santosh Pande)
Organization: Compilers Central
Date: Wed, 29 Jul 1992 05:12:45 GMT
Keywords: C, translator, summary

Thanks to everyone who replied to my posting about the 'Pros and cons of
higher level intermediate languages'. From the responses, it appears that:

	(1) C is the most popular IL in use,
	(2) Garbage collection / exception handling features in original
language do not get efficiently mapped to C due to its inherent
limitations,
	(3) As far as other issues are concerned, one could generate an
efficient C code (free of aliases etc) by styling the output of the
translator properly,
	(4) One might sometimes benefit due to the fact that C compilers
are well-tuned to the target architecture.
	
	Interestingly I didn't receive any response on C as IL for
parallel platforms!!
	If aliases prevent interprocedural and other optimizations for
RISC/ sequential machines; unless one is EXTRA careful, even the best of
the compilers can prohibit parallelization/vectorization in the presence
of pointers due to a hard dependence analysis at compile time!!
	Fortunately with some C compilers, one can resort to mixing
compiler directives (like nodepchk, noassoc, vector/concur etc. on
Alliant, iPSC (icc)) that allow the translator to force certain
optimizations in the presence of typical C referencing like pointers. 
	My experience with C as IL for SISAL on iPSC/860 is quite
satisfactory mainly due to fact that icc allows directives and does not
give you a packaged black-box!! I would like to know from others about
other platforms. 
-- 
 Santosh Pande, 				
 Box. 7911, 				
 Computer Systems Laboratory,  	 
 Dept. Of Electrical & Computer Engg.           
 North Carolina State University, Raleigh,     
 NC-27695-7911
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: grspangler@ualr.edu
Subject: design help reference
Reply-To: grspangler@ualr.edu
Organization: University of Arkansas at Little Rock
Date: Thu, 30 Jul 1992 08:52:22 GMT
Keywords: design, bibliography

QA
76.7    Programming languages, a grand tour /
.P78      Ellis Horowitz, editor. -- 3rd ed. --
1987      Rockville, MD : Computer Sciences
          Press, c1987.
          viii, 512 p. : ill. ; 28 cm. --
        (Computer software engineering series,
        ISSN 0888-2088)
          Bibliography: p. 503-508.
          Includes index.
          ISBN 0-88175-142-1 (pbk.)


          1. Programming languages (Electronic
        computers)  I. Hororwitz, Ellis.


===========================================================================
USMailNet: Guy R. Spangler  2801 S University Ave  Little Rock, AR  72204
AT&TNet:   (501)569-3345
InterNet:  GRSPANGLER@UALR.EDU
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: gat@forsight.jpl.nasa.gov (Erann Gat)
Newsgroups: comp.compilers
Subject: Re: Pros and cons of high-level intermediate languages
Keywords: translator, design, C, Scheme
Date: 29 Jul 92 17:04:36 GMT
Reply-To: gat@forsight.jpl.nasa.gov (Erann Gat)
Organization: Jet Propulsion Laboratory

tarvydas@tsctrl.guild.org (tarvydas) writes:
>>I am looking for examples in which using C as IL
>>will lead to inefficiencies.

[Long list of complaints about C deleted.]

Richard Kelsey wrote a dissertation about using a subset of Scheme as an
intermediate language for compilation.  It seems like an elegant approach
to me (though to be perfectly honest I don't really have the background to
evaluate it properly).  Is anyone familar enough with this work to offer a
more educated opinion on it?

Erann Gat
gat@robotics.jpl.nasa.gov

P.S.  Kelsey's dissertation can be obtained from the Yale CS department.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: jfc@athena.mit.edu (John F Carr)
Subject: Re: Pros and cons of high-level intermediate languages
Reply-To: jfc@athena.mit.edu (John F Carr)
Organization: Massachusetts Institute of Technology
Date: Sat, 25 Jul 1992 15:06:25 GMT
Keywords: C, translator

	graham@maths.su.oz.au (Graham Matthews) writes:

>I think you will find that gcc 2.X allows you to have arrays of labels.
>Any gcc experts out there to confirm this?

In gcc you can take the address of a label:

	foo:
	...
	void *labelp = &&foo;

There is a design flaw in this language extension: labels are represented
as (void *) rather than having a distinct type.  Until very recently, the
FSF only cared about traditional 32 bit single address space processors*.
On such machines, when label pointers are implemented as pointers to an
instruction, label pointers are the same size as data pointers.


* From the GNU coding standards document: "You can assume that all
pointers have the same format, regardless of the type they point to, and
that this is really an integer.  There are some weird machines where this
isn't true, but they aren't important; don't waste time catering to them."

--
    John Carr (jfc@athena.mit.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: lacey@cps.msu.edu
Subject: Problems with f2c
Reply-To: lacey@cps.msu.edu
Organization: Compilers Central
Date: Wed, 29 Jul 1992 04:23:15 GMT
Keywords: C, Fortran, question

I am unhappy with how f2c hands PARAMETER statements, and I am wondering
if there is anybody out there that has written a patch to make it somewhat
more sane, if such a patch could be written easily, and if neither of
those, if anybody has a suggestion on how to work around it.  The problem
is, if you have:
	PARAMETER (MAXXI=100)
	...
	INTEGER XI(MAXXI)

it gets translated to:
	integer xi[100];

What I would _like_ to see is:

	#define MAXXI 100

	integer xi[MAXXI];

The project I am currently working on consists of building an X-windows
interface onto an old Fortran program, which is converted to C with f2c,
and then portions are modified.  There are 55,000 lines of Fortran, in
around 45 files, along with another 12 common block files, in which the
PARAMETER statements appear.  The optimum result would be for each .F file
to be translated to a .c file, each .CBK (common block) file translated
into a .c file (this can be done with the -E option, I think it is), and
then a .h file created fopr each common block with the #define's for
PARAMETER statements, along with extern's for all of the common block
data.

I can't think of a work-around that actually works.  One approach I tried
was to replace each of the values in a PARAMETER statement with some
unique prime number, and then use 'sed' to replace occurances of the value
with a string.  This didn't work because of the fact that these parameters
are often multiplied together by f2c, and the result is a different
number, which often contains a substring of another number.  I could get
this to work if I could figure out how to make sed replace a string of
digits, strictly surrounded by non-digits, with a string (i.e. not replace
sub-strings of digits).  The parameters also, of course, show up in the
Fortran source code (if they didn't I could solve things pretty easily, by
hand).

Any help would be appreciated.  Please send e-mail rather than posting.

Thanks,

Mark M. Lacey
[lacey@cps.msu.edu]
[Try sed 's/\([^0-9]\)1234\([^0-9]\)/\1 MAXXI \2/' -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: vern@horse.ee.lbl.gov (Vern Paxson)
Newsgroups: comp.compilers
Subject: Re: Using FLEX to do macro processing - enhancement to include ...
Summary: use unput()
Keywords: flex, macros
Date: 24 Jul 92 05:35:51 GMT
Reply-To: vern@horse.ee.lbl.gov (Vern Paxson)
Organization: Lawrence Berkeley Laboratory, Berkeley

cdh@world.std.com (Charles D Havener) writes:
> Has there been any discussion about using FLEX to handle macro expansion
> as opposed to just #include type processing as descriobed in the Flex
> manual?
> 
> For example, can I use yy_create_buffer(FILE *file,int size) with a NIL
> FILE * and merely unput() the macro text into this buffer?

This should work as long as you redefine YY_INPUT, too, to not try to read
from yyin.  You could instead just use unput() directly with the current
buffer (this is how flex itself expands {name} definitions).

> [Plain unput() might work, though I imagine it'd be more robust to
> redefine YY_INPUT to copy in expanded text when it's reading from a
> buffer corresponding to expanded text. -John]

I'm not sure what's meant here by "more robust".  The amount of text that
can be pushed back will be limited to the amount of free space in the
buffer.  Except for pathological cases, this will be at least 8KB, as the
buffer is by default 16KB and is filled 8KB at a time.

In general it's hard solving this problem with YY_INPUT instead of
unput(), because the scanner will have already loaded its internal buffer
with quite a bit of data and will have to work its way through it before
it gets around to calling YY_INPUT again.  If there are difficulties I'm
missing with just using unput() I'd like to hear about them ...

		Vern

	Vern Paxson				vern@ee.lbl.gov
	Computer Systems Engineering		ucbvax!ee.lbl.gov!vern
	Lawrence Berkeley Laboratory		(510) 486-7504
[Some PC versions of flex have a much smaller input buffer, on the order
of 256 bytes, which won't always be enough unput space.  Agreed, with the
standard 8K buffers unput is perfectly adequate. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: cdh@world.std.com (Charles D Havener)
Newsgroups: comp.compilers
Subject: Using FLEX to do macro processing - enhancement to include processing
Keywords: flex, macros, question
Date: 23 Jul 92 13:21:24 GMT
Reply-To: cdh@world.std.com (Charles D Havener)
Organization: The World Public Access UNIX, Brookline, MA

Has there been any discussion about using FLEX to handle macro expansion
as opposed to just #include type processing as descriobed in the Flex
manual?

For example, can I use yy_create_buffer(FILE *file,int size) with a NIL
FILE * and merely unput() the macro text into this buffer? Then I could
use yy_switch_buffer(..) to switch to the macro buffer. I haven't tried
this. Is there some other recommended way? I really don't want to write
the expanded macro out to a disk file and then read it back in.

Charlie Havener at Epsilon - Burlington , Mass. 617-273-2630 x6064
cdh@world.std.com
[Plain unput() might work, though I imagine it'd be more robust to
redefine YY_INPUT to copy in expanded text when it's reading from a
buffer corresponding to expanded text. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: CHUYU%TWNMOCTL.BITNET@pucc.Princeton.EDU
Newsgroups: comp.compilers
Subject: TTCN and ASN.1 status?
Keywords: syntax, question
Date: 23 Jul 92 21:30:00 GMT
Reply-To: CHUYU%TWNMOCTL.BITNET@pucc.Princeton.EDU
Organization: Compilers Central

Is there any one know about TTCN(Tree and Tabular Combined Notation) and ASN.1
(Abstract Syntax Notation Number One) current status?

Is there any source code available from academe or Industry?

Best wishes,

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