Date: Sat, 11 Aug 2001 12:18:57 -0700 From: John Merryweather Cooper <jmcoopr@webmail.bmi.net> To: tlambert2@mindspring.com Cc: Rob <europax@home.com>, "hackers @ FreeBSD . ORG" <hackers@FreeBSD.ORG> Subject: Re: the =+ operator Message-ID: <20010811121857.A41578@johncoop> In-Reply-To: <3B757D14.B344931@mindspring.com>; from tlambert2@mindspring.com on Sat, Aug 11, 2001 at 11:44:36 -0700 References: <3B73F0BC.548D40B3@home.com> <3B757D14.B344931@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2001.08.11 11:44 Terry Lambert wrote:
> Rob wrote:
> > I've searched far and wide on search engines to find out what the =+
> > operator does, to no avail. I'm porting some old code and found it. I
> > made a test program and compiled it with gcc, and all it appears to do
> > is the same as regular assignment. But I'm wondering if in some day
> > long ago, it mean't something else? Thanks, Rob.
>
> Before ANSI went and ruined everything (e.g. by adding prototypes
> instead of making the object file format store attribution data,
> and smarter linkers, because the committee was packed with compiler
> vendors who wanted to do good on benchmarks), there was K&R C.
>
Since when does any self-respecting compiler dictate object format? It's
brain-damage for a compiler to screw with the object format--so much for
inter-language linkage. Prototypes are an overwhelmingly "Good Thing(tm)"
as behind-your-back implicit parameter conversion is death to serious
numerical work. At least now, some control can be exercised over parameter
conversions . . .
> In K&R C, the one true C, token gathering was two pass; it did not
> ingnore whitespace for token seperation on the first pass, and
> ignored it on the second, when necessary to disambiguate unknown
> tokens.
>
Two-pass lexing is also brain-damage. How to easily double compile time is
a single step. If applied to C++, we'd wait night and day for the compile
of just one port. :) Also, languages that are deliberately ambiguous are
maintenance nightmeres--maintenance perfers a language that is 100%
deterministic. Same way with porting. They're enough side effects to C
compilers on different platforms already without creating MORE
opportunities for subtle differences.
> Historically, the =+ and =- operators were used in the original
> C compilers... I believe this was for weenies who were unfortunate
> enough to own HP calculators, but it was an anacronism even 1978,
> which is when my copy of "The C Programming Language" book was
> published (unfortunately, it's not a first printing); this is
> noted on page 212, where they also talk about no "=" initializers
> ("int i 1;" instead of "int i = 1;"; newer, dumber, compilers
> have a hard time disambiguating expressions like "int i (17+BOO);"
> from functions because of the one pass tokenizer, so this is not
> allowed by ANSI, either).
>
To paraphrase Gen. George S. Patton: "The HP Calculator--the Greatest,
Most Perfect(tm) Calculating-Implement devised . . . " :) Seriously, my
understanding from K & R is that the C designers just thought it would be a
"nice feature" to allow both versions of the operators. "Nice feature" is
usually a synonymn for brain-damage in a compiler. :)
> I have used many compilers that took "=-", "=+", "=/", "=*", "=>>",
> etc., etc..
>
> ANSI broke all this code when it stated that whitespace was always
> ignored (thus permitting compiler writers to do single pass token
> gathering using the "greedy" rule, which could be done with a
> single pass LALR parser, spitting out tokens when the next character
> could not possibly be part of the previous token).
>
And that is as it should be . . . Lexing to be fast needs to be
single-pass. The same could be said for parsing. The agony over designing
a truly "standard" C++ compiler (not a single example of which exists)
should lay this out clearly . . .
> I have also seen the "/\" (max), "\/" (min), and "^^" (McCarthy XOR,
> moral symmetry for the McCarthy "||", "&&" operators), since the
> compilers that used them could put them into single machine
> instructions).
>
> My Manx Aztec C compiler for the IBM PC supports "=+" and "=-";
> it is also smart enought to turn: "x * 10" into "x <<=2; x++; x<<=1",
> and the 68000 version was smart enough to realize the bus was 16
> bits, not 32 bits, and so made "int" 16 bits on the 68000, but 32
> bits on the 68k processors with 32 bit busses, resulting in single
> cycle transfer times for the data: most other compilers, (e.g.
> Lattice C), were stupid, and made int 32 bits to appease lousy
> programmers.
>
As a long time user of Lattice C, your comment about 32 bit int's is
inaccurate. This behaviour existed on Lattice C 6.04 only if you set a
compiler switch to force it. Otherwise, int's were 16 bit. Lattice C also
was not stupid--for it's time it was one of the best optimizing compilers
on the market--bar none. It's sad that MacroHard all but put them out of
business--and ironic considering Lattice made the first few interations of
M$ C (1-4) for MacroHard. But then BG doesn't stand for one iota of
competition, and never gave/gives a damn about technical product quality .
. .
> Something to think about, for you "style" wonks who insist on
> "if ((a+=5))" instead of "if( a += 5)", not realizing that butting
> up the parenthesis left associatively is required to make some
> compilers work right, and the doubled parenthesis are just an
> editorial comment by the compiler writers about their preferred
> style of doing the test after the operation ("a += 5; if(a)"),
> coming from being assembly weenies, and not really something
> wrong, when they bitch about assignments in comparison statements.
>
"Style" is the essense of the best programming. Good programmers have it,
the rest suffer for want of it . . .
jmc
===================
> Kids these days: change the programmer to fit the machine...
>
> -- Terry
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010811121857.A41578>