Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!POSTGRES.BERKELEY.EDU!dillon From: dillon@POSTGRES.BERKELEY.EDU (Matt Dillon) Newsgroups: comp.sys.amiga.tech Subject: Re: Dividing by a power of two (Re: Aztec compiler ineffeciencies) Message-ID: <8811292001.AA02370@postgres.Berkeley.EDU> Date: 29 Nov 88 20:01:12 GMT Sender: usenet@ucbvax.BERKELEY.EDU Lines: 69 :> You might say "It is the compiler's job to optimize!", to which I would :>respond: "Which do you think the compiler can optimize better, a shift, or :>a divide?". Got it? No matter how good compilers get, certain constructs :>are more apt to optimization than others due to fewer assumptions having to :>be made about them, so the 'good' programmer *always* optimizes his code. : :My feeling is that the compiler should optimize whatever it can, allowing :me to select degrees of optimization, etc- like most modern compilers do. :After trying to understand what some of my oldest C code was doing (full of :tricks, and even with comments) I'm now convinced that :readability/understandability is vastly more important than "good" :programmer tricks which attempt to out-think the compiler. : :-scott Yes, readability/understandability is vastly more important than "good" programmer tricks, though they hardly attempt to out-think the compiler (one just make it easier for the compiler to generate better code). However, you are infering that there is a major relationship between how good the code looks and how many tricks one sticks in it. There is, in fact, a relationship ... about 1%, probably less. The absolute greatest effect on readability/understandability is, of course, one's coding form which is easily 99% of the whole deal. (form = indentation, structural form, modularity, modular independance, naming, and comments). The little tricks one sticks in his code probably accounts for less than one tenth of one percent of the source and can be ignored. So I'd say that you are exaggerating a bit in your message. When I want to multiply by 12 I use * UNLESS I am in a very critical portion of my code, in which case I wouldn't multiply OR shift, but would design the section so a multiplication is not required. In the very rare cases where I can't redesign the section, I will indeed use two shifts and an add. Now how often do you think that situation is going to come up? Even in large programs the critical areas are usually quite tiny and few in number. I suggest that the trouble you have understanding your very very old C code (I have the same problem to a degree w/ my very very old code) is due to the fact that you were not as experienced with form as you are now and has nothing to do with tricks. Well, maybe something ... a while back I was helping a kid with some assembly language he was doing. He wanted to convert an ascii digit to a binary value and this is what he did (in pseudo C): switch(c) { case '0': return(0); case '1': return(1); case '2': return(2); case '3': return(3); case '4': return(4); case '5': return(5); case '6': return(6); case '7': return(7); case '8': return(8); } return(9); It took me 20 minutes to explain to him that he could replace 30 lines of assembly with 2. -Matt