yess we both have a few gray hairs.
You inadvertently raise a really good point about optimizations. The old
PCC was somewhat of a pig, but one could rely on its code. Optimizers
tend to do some really screwy things. The code snippet about the
optimizing of the strlen(constant) had a couple of interesting things in it.
Other than the elimination of strlen altogether, it also called a private
version of printf. Nearly all C compilers will optimize this one:
unsigned long loop(insigned long iterations)
{
unsigned long i;
for(i=0; i < iterations;i++);
return i;
}
Nearly every compiler (Dec C, GCC, HPUX, SUN) will optimize out this
loop (even when you tell it not to). Makes life interesting for benchmark
writers.
On 5 Apr 2000, at 16:15, Jon 'maddog' Hall, Executive Director, Li wrote:
> >Actually I had my original K&R in hand when I answered the question.
>
> Gerry, what was YOUR original K&R may well have been MY second edition.
> But then again, we share about the same number of grey hairs.
>
> >Before DEC C was allowed to become the compiler on Digital Unix, it
> >had to successfully compile the entire kernel, libraries and commands.
>
> Right, we were using the portable "C" compiler before that. And because it
> was compiling a BSD kernel, it was obviously "BSD". QED
>
> DEC "C" was originally built to the ANSI standard, I believe, which caused
> all the work that you mentioned to be done, PLUS there are certain issues
> in a kernel level compiler and libraries vs a user-level compiler and libraries
> that had to be overcome to use DEC "C".
>
> Finally (for those of you not used to this type of trick), the engineers
> creating the kernel and the X-server (in particular) knew what type of output
> the pcc compiler would generate for certain constructs of "C". When the
> DEC "C" compiler compiled their code and "optimized" it, many times there
> was no performance improvement, and often there was a performance penalty.
>
> >Most of the kernel at that time was K&R. Most of libc was ANSI, and the
> >commands were a hodgepodge depending on their origin.
>
> I tend to think of it as "most of the kernel was BSD, all of libc was
> BSD, some of which happened to align with ANSI, and the commands were
> a hodgepodge, which (by a miracle) happened to link to BSD.
>
> > But, strcmp still returned and int back then.
>
> No argument. It was "always" an int.
>
> > The issues are exactly
> > what are the positive and negative values. ANSI says that strcmp()
> > returns greater than zero, less than zero or zero. Most
> > implementations return the difference between the first non-matching
> > characters of the strings. While optimizing compilers may inline the
> > code, the run time libraries frequently do a simple subtract.
> >
>
> We are in violent agreement.
>
> md
> --
> =============================================================================
> Jon "maddog" Hall
> Executive Director, Linux(R) Intern'l Director of Linux Evangelism
>
> Linux International VA Linux Systems
> 80 Amherst St. 1382 Bordeaux Ave.
> Amherst, N.H. 03031-3032 U.S.A. Sunnyvale, CA 94089
> Internet: [EMAIL PROTECTED] [EMAIL PROTECTED]
> WWW: http://www.li.org WWW: http://www.valinux.com
> Voice: +1.603.672.4557
>
> Board Member: Uniforum Association, USENIX Association
>
> (R)Linux is a registered trademark of Linus Torvalds in several countries.
>
>
> **********************************************************
> To unsubscribe from this list, send mail to
> [EMAIL PROTECTED] with the following text in the
> *body* (*not* the subject line) of the letter:
> unsubscribe gnhlug
> **********************************************************
Jerry Feldman <[EMAIL PROTECTED]>
Associate Director
Boston Linux and Unix user group
http://www.blu.org
**********************************************************
To unsubscribe from this list, send mail to
[EMAIL PROTECTED] with the following text in the
*body* (*not* the subject line) of the letter:
unsubscribe gnhlug
**********************************************************
