Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!rutgers!ames!ucbcad!ucbvax!decvax!tektronix!tekcrl!tekfdi!videovax!stever From: stever@videovax.Tek.COM (Steven E. Rice, P.E.) Newsgroups: comp.sys.amiga Subject: Re: Manx C Message-ID: <4524@videovax.Tek.COM> Date: Wed, 31-Dec-69 18:59:59 EDT Article-I.D.: videovax.4524 Posted: Wed Dec 31 18:59:59 1969 Date-Received: Sun, 9-Aug-87 08:25:27 EDT References: <4540@jade.BERKELEY.EDU> <1836@vax135.UUCP> <4595@jade.BERKELEY.EDU> <3199@zen.berkeley.edu> <17827@amdcad.AMD.COM> <3211@zen.berkeley.edu> Reply-To: stever@videovax.Tek.COM (Steven E. Rice, P.E.) Organization: Tektronix Television Systems, Beaverton, Oregon Lines: 88 Keywords: type coercion, optimization Summary: Type coercion of constants has been around for a *long* time. In article <3211@zen.berkeley.edu>, waterman@cory.Berkeley.EDU.UUCP (T.S. Alan Waterman) writes: > In article <17827@amdcad.AMD.COM> tim@amdcad.UUCP (Tim Olson) writes: [ quite a bit deleted ] > There are many kinds of '0' (short, long, pointer, floating-point..) > and saying "equal to 0" leaves things open to Manx's type conversion. > Manx has a bug in that it likes to leave constants as untouched as > possible. > [argument mine] >> >> From the X3J11 ANSI C Draft, section 3.2.2.3 (Pointers): >> >> "... An integral constant expression with the value 0, or such an > ^^^^^^^^ but how big is an integer?? (we've been through > this before!!) Way back when, shortly after the dawn of time (but not much), I was an eager college student programming on an IBM 1620. [The 1620 was one of the few really *digital* computers ever built (in our case, it had 60,000 *digits* of core, each of which could hold a single decimal *digit* -- 0 to 9; none of this *binary* nonsense. . .).] Our 1620 had a FORTRAN compiler (big step forward -- previous machines had assembly language only). In IBM 1620 FORTRAN one saw numerous constructs of the form (remember the IJKLMN rule -- anything starting with those letters is an integer; anything else is real): A = 2.0 B = FLOAT(I)/3.0 C = 2.0*B This was because the 1620 FORTRAN compiler was very narrow-minded. If a number doesn't have a decimal point (or an exponent), then it *must* be an integer, right? Mercifully, compilers have improved along with computer speeds. One concept that has been added is called "type coercion" -- expressions are scanned and values are converted to the "highest" type present in the expression. Since the type of any expression is known at compile time, constants can be "coerced" to the appropriate type, without creating compiler hysteria or user frustration. As the type of the expression in question ("ptr == 0") is clearly known in advance -- "ptr" has been declared to be a pointer -- there is no good reason not to coerce the zero to the correct type! > What I don't get is this-- (!ptr) seems more straightforward, > you never have to worry about types, and it makes smaller code > than (ptr == 0) anyway. Why use the second expression? (with > pointers, at least.) There is no reason (other than incomplete optimization) that (ptr == 0) should be any larger than (!ptr) -- at least on the 68000 family! If we ignore the limited arithmetic allowable on pointers, the general strategy for an equality test would be (using long words, because of the pointer arithmetic): movea.l ,Ax cmpa.l #,Ax bne not_equal [ code to be executed if the two are equal ] bra around not_equal [ code to be executed if the two are not equal ] around [ next statement ] But, when the optimizer (or for that matter, the compiler) sees it is generating a "movea.l ,Ax" / "cmp.l #0,Ax" sequence, it can immediately delete the "cmp" instruction, because the 68000 sets the condition codes when the register is loaded. For a (!ptr) construct, a "tst.l " might be generated, but this is neither smaller nor faster than the "movea.l" instruction. Further, with a pointer it is probable the pointer will be used if it is non-zero, so the register load is likely to be both faster and smaller overall. Steve Rice ----------------------------------------------------------------------------- new: stever@videovax.tv.Tek.com old: {decvax | hplabs | ihnp4 | uw-beaver | cae780}!tektronix!videovax!stever