HDTenEightyP/NetNews huggingface dataset:
From: macrakis@osf.org (Stavros Macrakis)
Subject: Re: Why is compiled basic slower than C? (Basic is the future)
Reply-To: macrakis@osf.org (Stavros Macrakis)
Organization: OSF Research Institute
Date: Wed, 12 Aug 1992 22:54:07 GMT
Keywords: C, Basic, performance

Glenn_Johansson@f313.n203.z2.fidonet.cd.chalmers.se writes:

[How much slower is compiled Basic than C, any why?]

Here are some thoughts.  Warning: I have not looked at Basic in some
years.

   2. Why is the basic compilers creating a slower product than the C
   compilers?

      Possible answers
      a. Because of the beginner-reputation of basic,
	 basic programmers write more bad code than for example C programmers,
	 because "serious" programmers quickly change to C.

In the PC world, many implementations were interpreters, so this may have
given Basic a bad reputation for speed.  This also lowers expectations for
compilers. Of course, the original Dartmouth Basic was compiled.

     c. Because it is much harder to write a compiler for basic (even modern
        basic) than for C, which is designed for the purpose of being
	compiled, not for the programmers.

This is part of it, no doubt.  It also depends what you are doing.  I
would expect a good Basic compiler to be comparable to C for straight
floating-point code.  Old Basics used floating-point for ALL arithmetic,
so integer code will be much slower.  String manipulation will be slower,
since Basic's facilities are higher-level.

   ...So why is not Basic the biggest programming language today?
   Well, my theory is this: When C was invented, it was made to be
   simple to write a compiler for, because the compiler constructors
   were not that good then.

Yes, this is certainly true.  In fact, large areas of C's semantics (if
you can dignify them with that name) are defined by what is easy to
implement, not what makes sense.

C is also a lower-level language.  C doesn't really `understand' strings,
only pointers to byte positions.  So it is possible to write lower-level
code.  It is also possible to write high-level code to a certain extent,
but it requires discipline.

   [....  By the way, the guys who wrote Basic in
   the first place definitely wanted it to be easy to compile -- the
   first compiler at Dartmouth compiled so fast it was hard to measure
   its speed. -John]

Basic was certainly designed to be easy to compile, but not
necessarily to be fast to run.

	-s
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: johnl@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.compilers
Subject: Floating point bibliography
Keywords: bibliography, arithmetic
Date: 22 Aug 92 05:12:44 GMT
Article-I.D.: comp.92-08-141
Reply-To: John R. Levine <johnl@iecc.cambridge.ma.us>
Organization: Compilers Central

I have snarfed Norbert Juffa's extensive bibliography on floating point
arithmetic for the compilers archive, where it's stored under the name
"floatbib".  Eventually I'll also put it in the FTP archive.  (At the
moment my Internet access is tenuous.)

It was posted to comp.arch yesterday, so if you look there you can probably
find it without having to ask the compilers mail server.
-- 
Regards,
John Levine, comp.compilers moderator
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:1389 comp.lang.c:12404
From: markh@csd4.csd.uwm.edu (Hunk)
Newsgroups: comp.compilers,comp.lang.c
Subject: Re: Two-pass C compilers
Keywords: C
Date: 16 Aug 92 19:06:31 GMT
Reply-To: markh@csd4.csd.uwm.edu (Hunk)
Organization: Computing Services Division, University of Wisconsin - Milwaukee

behrenss@Informatik.TU-Muenchen.DE (Soenke Behrens) writes:
>Hmmm ... beat me if I something silly, but: Is there any way around
>a two-pass compiler? (Or even more passes)
>
>First pass: Reading in the source, preprocessing it, building a symbol table.
>Second pass: Generate p-Code
>Third pass: Optimize p-Code (Note: Do not mix with 2nd pass or you are
>in deep trouble)
>Fourth pass: Generate native code in linkable object file

Pass 1: Generate optimized binaries, into an object file.
        Back-patch forward references, Dump table of external and globals.

The object file format is dictated by this method.  All memory images must
be written before the tables and after the header.  The header must be
fixed in size, and must contain all the needed pointers to access the
tables.

The code generation rules are carefully written with optimization built
into them.  For example, they can be derived by knowledge engineering
techniques from an expert human compiler (presunably the person doing the
compiler-writing would qualify).

Global analysis, data flow, register allocation, control flow are all done
on the fly during parsing.  Whatever intermediate structures are needed
are stored in memory.

Pass 1.5: Linking object files and resolving the remaining unresolved objects.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers
From: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Subject: Re: Adding garbage collection to C++
Reply-To: fjh@munta.cs.mu.OZ.AU (Fergus James HENDERSON)
Organization: Computer Science, University of Melbourne, Australia
Date: Tue, 18 Aug 1992 10:15:42 GMT
Keywords: C, GC

tmb@idiap.ch writes:
>>[C lets you hide pointers in inconvenient ways, e.g. writing them to
>>files or scrambling bytes in unions.]
>
>All the locations where a pointer is converted to an integer (via casts,
>unions, or memcpy) are detectable by the compiler. For any pointer that
>has ever been (mis-)treated in such a way, the corresponding memory can
>simply be exempted from garbage collection (e.g., by recording the pointer
>in some global table searched by the garbage collector).

This may be true in theory, but it seems like it would be very difficult
in practice (especially if you allow seperate compilation) and might lead
to memory leaks.

Presumeably you have to consider every conversion from (T **) to (void *)
potentially dangerous, since the (void *) could be used to hide away the
(T *) pointer, using memcpy(), fwrite(), or some such.  But such
conversions may be relatively common.

For example, if you want to sort an array of strings, then you will
probably pass a (char **) to qsort() where it expects a (void *).
Presumably the compiler is not going to be smart enough to tell the
difference between qsort() and fwrite(), which both take a void *
parameter.  If instead you happened to be using a user-defined sort
function that has not yet been written or compiled, then there is no way
it could tell!  This means that it will have to assume that qsort might
hide a copy of the pointers somewhere, so the compiler must record the
pointers in the global table.

Now if you were actually relying on GC to reclaim that memory, you're
stuffed, because the compiler can never be sure that qsort() hasn't
secretly written the addresses to a file, so it has to keep the memory
hanging around.  This is a memory leak.

If your GC doesn't prevent memory leaks, not many people will use it :-)

-- 
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: quanstro@stolaf.edu (goon)
Newsgroups: comp.compilers,comp.lang.c
Subject: Re: Two-pass C compilers
Keywords: C, design
Date: 16 Aug 92 18:13:56 GMT
Reply-To: quanstro@stolaf.edu (goon)
Organization: St. Olaf College, Northfield, MN USA

The moderator comments:
   [Depends on what you mean by pass.  Most C compilers I know turn C into
   assembler and only read the source once.  Whether you think of the
   assembler as a second pass is a matter of semantics.  Some compilers, e.g.
   Turbo C, go directly from C to object code, again only reading the source
   once.  ...

It seems to me that the Dragon book is very careful in defining a "pass"
as "reading an input file and writing an output file." [p. 20] Now in each
pass you can have as many phases as you want. In theory it would be
possible to construct a compiler for any compilable language as a one-pass
compiler with some positive number of phases.  For C one needs to do
lexical analysis, parsing, type checking, and code generation with several
other phases (such as intermediate code generation and optimization) often
implemented.

In practice, C compilers have generally (well, at least often) had two
passes, with the output of the second fed to the assembler. However this
is mostly an artifact of the memory limitations in the early days of UNIX.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: imp@Solbourne.COM (Warner Losh)
Newsgroups: comp.compilers
Subject: Re: Why is compiled basic slower than C? (Basic is the future)
Keywords: interpreter, performance
Date: 18 Aug 92 19:17:16 GMT
Reply-To: imp@Solbourne.COM (Warner Losh)
Organization: Solbourne, User Interface Group

burley@geech.gnu.ai.mit.edu (Craig Burley) writes:
>[re whether it's worth compiling TECO]

I used a TECO variant on the DECSYSTEM-20 that we had at school.  The
manual claimed to compile the code on the fly before it executed it.  The
claimed speedup was on the order of a factor of 5 due to some optimization
tricks.  It was called something like NTECO, or something like that.

Warner
-- 
Warner Losh		imp@Solbourne.COM
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: tmb@arolla.idiap.ch (Thomas M. Breuel)
Newsgroups: comp.compilers
Subject: Re: Adding garbage collection to C++
Keywords: C++, GC
Date: 12 Aug 92 16:50:12 GMT
Reply-To: tmb@arolla.idiap.ch (Thomas M. Breuel)
Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
	Perceptive)


Dain.Samples@UC.EDU writes:

   I have reached the conclusion that only conservative garbage collection
   allows no changes to the existing language [C or C++].

Why have you reached that conclusion? As far as I can tell, ANSI-C and C++
are both fully garbage collectable within the current language standard.
More precisely, I believe that you could compile ANSI-C to portable and
idiomatic CommonLisp (the main difficulty is pointers to automatic
variables).

   I added three additional keywords: collected, heap, and embedded.  The
   latter keyword is used to declare pointers that can be used to point into
   objects that are collected, and the other two are used to declare
   collectible objects and allow the programmer to allocate normally gc'd
   objects on the heap.

I don't understand why there is this desire to keep supporting the "usual"
malloc/free style heap allocation once you have garbage collection (the
functions themselves should, of course, continue to exist, with "malloc"
allocating storage and "free" becoming a NOOP).

I have never found malloc/free style storage management to be faster than
a good GC, and as far as I can tell, you never want unreferenced data to
hang around if you have so little memory left that you need to call a
garbage collection. For really daring programmers, you could provide some
primitive "unsafe_free" that returns storage immediately and regardless of
whether there are still references.
					Thomas.
[I'd be interested how you trace through unions containing pointers. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: bill@amber.ssd.csd.harris.com (Bill Leonard)
Newsgroups: comp.compilers
Subject: Re: Adding garbage collection to C++
Keywords: C++, GC
Date: 14 Aug 92 21:13:51 GMT
Reply-To: bill@amber.ssd.csd.harris.com (Bill Leonard)
Organization: Harris CSD, Ft. Lauderdale, FL

kelvin@kickapoo.cs.iastate.edu (Kelvin Don Nilsen) writes:
> >[I'd be interested how you trace through unions containing pointers. -John]
> 
> We have implemented copying garbage collection for the C++ language
> standard, making only a few minor restrictions on normal C++ usage.  We
> are able, for example, to compile Gnu groff by fixing fewer than five
> "sloppy" programming tricks.  We handle unions that may contain either
> pointers or raw seething bits by adding an explicit tag to distinguish
> between the two.  Each assignment to one of these unions incurs the cost
> of updating the tag.  We do not check the tag on reads.  Further, we do
> not update the tag if the union is known always to contain pointers, or
> always to contain raw seething bits.

This would be a pretty nasty thing to do if one is using the union to map
data stored in an external device, such as data read from a file or in the
case of memory-mapped I/O.  You may consider this a "minor restriction",
but there are many programmers, whose applications would become invalid,
who would disagree with you.

We have come across another case wherein garbage collection becomes
difficult, if not impossible.  We have two C++ programs that communicate
through shared memory.  There are some cases where program A allocates an
object, then sends a pointer to that object (through shared memory) to
program B, who stores the pointer in a variable that does not reside in
shared memory.  Program A then forgets about the object (i.e., it retains
no pointers to it).  Program B will randomly send messages to this object
by sending the pointer back over to program A, but otherwise program A
will have no references to this object in *its* address space.

I think you basically have to give up on garbage collecting such strange
objects.  But their existence forces me to advocate that garbage
collection only happen if I specifically ask for it (thus begging for
language extensions), rather than automatically.
-- 
Bill Leonard
Harris Computer Systems Division
2101 W. Cypress Creek Road
Fort Lauderdale, FL  33309
bill@ssd.csd.harris.com
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: gunnar@Tymnet.COM (Gunnar Brading)
Newsgroups: comp.compilers
Subject: Design of abstract machines and LISP compilers
Keywords: Lisp, design
Date: 19 Aug 92 03:10:13 GMT
Reply-To: gunnar@Tymnet.COM (Gunnar Brading)
Organization: Compilers Central

I hope I might get help here with ideas about literature about the design
and implementation of abstract machines and compilers for LISP.  Naive
interpretative solutions might be interesting too.

What I need is to get hold of some more advanced texts, and have had
problems finding any useful litterature on the subject. I would appreciate
all help and insights.


Thanks,
Gunnar Brading     | BT North America Inc     | Work: + 1 (408) 922-6017
gunnar@Tymnet.COM  | 2560 North First Street  |  fax:           922-6125
g=gunnar,s=brading | PO Box 49019, B4-1       | Home: + 1 (408) 946-1996
o=btna,p=btna-ixgw,| San Jose, CA, 95161-9019 |    1930 Via Reggio Ct
a=dialcom,C=us     |                          |    San Jose, CA, 95132
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Xref: sparky comp.compilers:1422 misc.jobs.misc:6012
From: compilers-request@iecc.cambridge.ma.us (John R. Levine)
Newsgroups: comp.compilers,misc.jobs.misc
Subject: Job postings
Keywords: administrivia
Date: 20 Aug 92 18:24:04 GMT
Reply-To: John R. Levine <compilers-request@iecc.cambridge.ma.us>
Organization: Compilers Central

Over fifty people have responded to my question about whether job postings
are appropriate for comp.compilers, and I've gotten considerably more
support than opposition for a weekly digest.  So here's what I'm planning
to do for a test period of two months:

-- One digest per week, no digest if no messages
-- Cross-post to misc.jobs.offered
-- Distribute only to usa unless it contains offers from outside the USA

I won't include messages that don't offer compiler related jobs or that
don't conform to Eugene Miya's misc.jobs.offered guidelines.

The subject lines will read "Compiler jobs digest" so people who don't
want to see them can update their kill files now.  After two months if the
jobs digest doesn't seem to be working, I'll go back to the no jobs
policy.  There was universal agreement that one message a week was the
maximum that people want.

Regards,
John Levine, comp.compilers moderator
johnl@iecc.cambridge.ma.us or {spdcc|ima|world}!iecc!johnl
-- 
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
Subject: Re: Garbage collectable C
Reply-To: meissner@osf.org
Organization: Compilers Central
Date: Wed, 12 Aug 1992 16:12:45 GMT
Keywords: C, storage, GC

Most of the replies that I have seen about garbage collectable C are ways
to force variables into the stack (including emacs' GCPRO macros).  One
thought that I've had is to shadow the variables when they get modified.
Ie, if you have a variable foo that is local to the function, the
meta-compiler would create both 'foo' and 'shadow_foo' variables, where
'shadow_foo' is a structure that contain's foo's current value, and a
dynamic link to other shadowed structures in this or previous activation
frames.  Whenever 'foo' is modified, you update 'shadow_foo' as well.
That way, to search for the live values, all you have to do is search the
shadow chain.  Setjmps would be handled by having the setjmp calling
routines save the current shadow chain head pointer in a volatile
variable, and restoring it after longjmp yanks you back.

The cost of this method is to have the shadow chains on the stack, the
initial setup, and an extra store everytime the local variable gets
changed (and mods usually are rarer than accesses)
--
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: dhetheri@digi.lonestar.org (Dave Hetherington)
Newsgroups: comp.compilers
Subject: Public Domain COBOL Package
Keywords: Cobol, question, comment
Date: 20 Aug 92 13:07:00 GMT
Article-I.D.: comp.92-08-133
Reply-To: dhetheri@digi.lonestar.org (Dave Hetherington)
Organization: Compilers Central

I don't expect too many responses to this post since it involves COBOL ;-)
but any replies would be appreciated. A couple of friends of mine who work
with business applications expressed an interest in learning COBOL. I
found a public domain version "COBOL650.ZIP" on UUNET. The compiler seems
to work and looks as if it generates p-code. I believe the interpreter is
in the included library "COBOL650.LIB". The linker for this package is
missing.  Just for grins I tried the Turbo-C linker with the expected
failure results.  The author of this package claims to be dying of AIDS.

      1) Can someone send me the linker for this package or maybe the
         complete package? The author claims the source has been posted
         to the "AV-SYNC BBS" in Atlanta, Georgia. I noticed in the FAQ
         for this group that a COBOL grammar has been sought after. Maybe
         one is included in this package???

      2) Has anyone used this package or a previous version? Is it reliable
         and really ANSI compliant?

I will post a summary of responses if I receive any interesting replies.

Dave Hetherington                      
dhetheri@digi.lonestar.org 
[I've seen this most unusual package, including the note about the author's
illness, but I haven't tried it out, not being much of a Cobol user. There
is no grammar file, though. -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: fjh@cs.mu.OZ.AU (Fergus Henderson)
Newsgroups: comp.compilers
Subject: Re: Adding garbage collection to C++
Keywords: C, GC
Date: 14 Aug 92 08:45:36 GMT
Reply-To: fjh@cs.mu.OZ.AU (Fergus Henderson)
Organization: Computer Science, University of Melbourne, Australia

mw@ki.fht-mannheim.de (Marc Wachowitz) writes:

>Thomas M. Breuel <tmb@arolla.idiap.ch> wrote:
>: As far as I can tell, ANSI-C and C++ are both fully garbage collectable
>: within the current language standard.
>
>At least you would have to be very careful when the programmer copies the
>value of the last pointer to some heap object to some memory region (e.g.
>an unsigned char[]) and changes the order of the array elements, then
>destroys the pointer.  No more live reference is detectable by the
>collector, but the programmer may copy back the pointer value (again
>changing the byte order) and ... :-) I guess such manipulations would be
>possible with the current standard.

Yes, I have thought about exactly the same problem.
Is there way around this, Thomas?

  void f() {
  	int i;
	void *p=malloc(666);
	char hide_p[sizeof (void *)];

	memcpy(hide_p,&p,sizeof (void *)); // copy pointer into char array
	swap(hide_p[0],hide_p[1]);	   // rearrange array
	p = 0;

	// allocate lots of memory to force garbage collection
	for (i=0;i<10000;i++) malloc(10000);

	swap(hide_p[0],hide_p[1]);		// restore array and
	memcpy(&p, hide_p, sizeof (void *));	// copy back to pointer

	// now use p
	memset(p,0,666);
    }

>[It is my impression that an ANSI C program is allowed to copy a pointer to
>a long and later back to a pointer of the same type.  This sort of thing
>makes it hard to find all the live data. -John]

This is not really a problem for conservative garbage collectors which
scan through the C stack, since the long will still be on the stack and
will thus be considered a reference.

Also while a program is allowed to copy a pointer to a long and back
again, it is not allowed to depend on the results! Conversion from
pointers to long and vice versa is implementation defined, I think, and
anyway there is no guarantee in ANSI C that long wil be large enough to
hold a pointer.

Unfortunately I think that it *is* fine to copy a pointer to an array of
char and back again and to depend on the original pointer being restored.
-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
[My copy of the C standard is in the mail, so I'll wait until it arrives
before further pontificating on legal type casts.  frumious!pat@uunet.ca
sent in a similar GC-resistant example that writes pointers out to
temporary files. -John]
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
From: kuttanna@eemips.tamu.edu (Belliappa Kuttanna)
Newsgroups: comp.compilers
Subject: Wanted: Utility to convert a.out to Moto's S-record format
Keywords: linker, question
Date: 17 Aug 92 18:35:43 GMT
Reply-To: kuttanna@eemips.tamu.edu (Belliappa Kuttanna)
Organization: Texas A&M University

As mentioned above, I am looking for a utility which will convert 
an a.out file produced by the gnu C compiler to the Motorola S-record 
(hex) format.

Any help in this regard will be greatly appreciated.

 Belliappa Kuttanna              kuttanna@ee.tamu.edu
 Dept. of Electrical Engg.
 Texas A&M University.
-- 
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers.  Meta-mail to compilers-request.
Newsgroups: comp.compilers