[net.unix] Anybody have any experience with

wls@astrovax.UUCP (William L. Sebok) (12/03/84)

Tartan is advertising a C compiler for Vax BSD Unix.  Some of their claims are
	Optimized object code that makes your programs run up to three
	  times faster.
	Object code that's up to 55% smaller.
	Optional array bounds checking
	More complete error diagnostics.

Price is $2000 for one cpu.  There is a 15% educational discount.  Their
sales dept. phone number is (412) 621-2212.

Has anybody had any experience with this? Sounds interesting if their claims
are true.  I have felt (as stated in previous postings) that Unix on the Vax
has badly needed a super-optimizing C compiler.  Whether this is it I don't
know.

Reply to me and I will summarize to the net.
-- 
Bill Sebok			Princeton University, Astrophysics
{allegra,akgua,burl,cbosgd,decvax,ihnp4,noao,princeton,vax135}!astrovax!wls

mo@seismo.UUCP (Mike O'Dell) (12/04/84)

Super-optimizing C compilers may be wonderful, but don't expect
to compile your Kernel with such a beast.  Also, be careful of
code which calls time functions.  It is very easy to break the
kernel by moving code around!!!!  The proposed ANSI C standard
includes a new declaration keyword "volitile" to tell the compiler
"don't optimize accesses to this variable", but until this is
implemented, among other things, super-optimizing C compilers should be
used with considerable care.

Compilers which do a good job of code generation are another matter,
but keep in mind that one person's good code generation may be another
person's block optimizations.

These comments are based on conversations with an author of a merely
well-optimizing C compiler who had to work hard to make his
kernel work again.

	-Mike O'Dell

jeff@gatech.UUCP (Jeff Lee) (12/04/84)

Just for general information, the Tartan Labs people have a book out
(C: A Reference Manual by Samuel Harbison and Guy Steele) that goes
fairly in depth about the implementation details of implementing a C
compiler. It also has a true LALR(1) grammar in appendix C for C.
The book might be good for someone who doesn't currently have access to the
proposed standard. It was just published this last June ('84) so it
might be hard to get, but one of the local B. Daltons (Lenox in Atlanta)
seemed to have more than their share of copies.

-- 
Jeff Lee
CSNet:	Jeff @ GATech		ARPA:	Jeff.GATech @ CSNet-Relay
uucp:	...!{akgua,allegra,rlgvax,sb1,unmvax,ulysses,ut-sally}!gatech!jeff

padpowell@wateng.UUCP (PAD Powell) (12/05/84)

I echo the sentiments of using super-optimizing C compilers.
I had a very bad experience with one version which optimized all
of my timing loops and hardware interface level driver stuff out of
existence...

Patrick Powell

draves@harvard.ARPA (Richard Draves) (12/07/84)

> Just for general information, the Tartan Labs people have a book out
> (C: A Reference Manual by Samuel Harbison and Guy Steele) that goes
> fairly in depth about the implementation details of implementing a C
> compiler. It also has a true LALR(1) grammar in appendix C for C.

I haven't looked at their grammar, but I doubt if what I would call
a true LR(k) grammar for C is possible.  The problem is typedefs.
The expression "(a) * b" may be either a cast or a multiplication,
depending on whether "a" is a variable or a typedef.  Parsing this
requires a symbol table lookup.  The grammars I have seen all have
their lexxer make this check, contingent on a flag that is set by
the parser.  This is because declarations like "int a" in a function,
after "a" has been typedef'ed, are legal, so sometimes "a" must be
recognized as a vanilla identifier, and sometimes as a type.

Rich