From owner-freebsd-hackers Sat Aug 11 13:52: 9 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from yoda.bmi.net (yoda.bmi.net [204.57.191.163]) by hub.freebsd.org (Postfix) with ESMTP id 56D5037B408 for ; Sat, 11 Aug 2001 13:52:02 -0700 (PDT) (envelope-from jmcoopr@webmail.bmi.net) Received: from johncoop.MSHOME (drumheller-router.bmi.net [206.63.201.3] (may be forged)) by yoda.bmi.net (Pro-8.9.3/Pro-8.9.3) with ESMTP id OAA27059; Sat, 11 Aug 2001 14:17:01 -0700 Received: from johncoop.MSHOME (localhost [127.0.0.1]) by johncoop.MSHOME (8.11.5/8.11.5) with ESMTP id f7BJJ8W54102; Sat, 11 Aug 2001 12:19:08 -0700 (PDT) (envelope-from jmcoopr@webmail.bmi.net) Date: Sat, 11 Aug 2001 12:18:57 -0700 From: John Merryweather Cooper To: tlambert2@mindspring.com Cc: Rob , "hackers @ FreeBSD . ORG" Subject: Re: the =+ operator Message-ID: <20010811121857.A41578@johncoop> References: <3B73F0BC.548D40B3@home.com> <3B757D14.B344931@mindspring.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <3B757D14.B344931@mindspring.com>; from tlambert2@mindspring.com on Sat, Aug 11, 2001 at 11:44:36 -0700 X-Mailer: Balsa 1.1.7 Lines: 117 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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