Author: Robert Hyatt
Date: 07:40:48 01/14/02
Go up one level in this thread
On January 13, 2002 at 23:54:27, Eugene Nalimov wrote:
>On January 13, 2002 at 16:27:01, Tom Kerrigan wrote:
>
>>On January 13, 2002 at 10:22:52, Robert Hyatt wrote:
>>
>>>1. You know more about the program than the compiler. No bounds-checking
>>>on "switch" type statements is necessary.
>>
>>What bounds checking or "switch type statements" are going on in a C program if
>>you don't explicitly put them in?
>
> switch (x) {
> case 0:
> ...
> case 1:
> ...
> case 2:
> ...
> }
>
>Good compiler will generate something like:
>
> if (x == 0)
> ...
> else if (x == 1)
> ...
> else if (x == 2) // That condition is not necessary
> // if x can be only 0, 1, or 2
> ...
>
>In more general case, compiler have to generate even more complex check, i.e.
>
> if (((unsigned)(x-(lower value)) > (unsigned)(upper value - lower value))
> goto default;
>
>>>2. you know whether a value can be positive, negative, or both. The
>>>compiler can't.
>>
>>Why does this matter? Just deal with 32 bits (or whatever your word size is) and
>>call it good.
>
>On 64-bit system you can avoid sign extension if you know that the value is
>non-negative. Sometime you can achieve similar effect in C casting the value to
>the unsigned, but code becomes uglier than even assembly one.
>
>>>3. you know whether a value can exceed (say) 127 or not. The compiler can't.
>>
>>Again, why does this matter?
>
>Once again, to avoid ZXT/SXT.
>
>>>4. You know how many registers the CPU has and can design code around that,
>>>while C doesn't give you such control.
>>
>>You can change the C until it produces the assembly that you want.
>
>That can be hard in the marginal cases. If your compiled program needs less
>registers than target CPU have, than it easily can be at least not worse than
>assembly program. If both your program and assembly program run out of
>registers, usually there is no much speed difference, too. But in marginal case
>you can see huge difference -- e.g. on x86 compiler was not able to fit
>everything into 7 registers (it wanted 8, but there is no 8th register there, so
>there are spills), but programmer was able to slightly rearrange the code and
>still squeeze everything on 7 registers...
>
>>>5. you know exactly which registers procedure "x" will destroy, so you don't
>>>have to save everything before calling it. If you are careful, you don't have
>>>to save _anything_.
>>
>>The really strict calling conventions that you're thinking of here are no longer
>>present in today's compilers.
>
>Here you are only partially right... There are still cases where compiler have
>to honour standard calling conventions.
>
>And I can add
>
>6. Usually programmer knows much more about possible aliases in his program than
>even the best compiler can find out.
>
>But Tom is partially right, too -- today's compilers are much better than ones
>from 10 years ago. I am not talking about vectorizers, obviously major compiler
>vendors started to look at them only recently, but for the control-heavy integer
>code current compilers should produce reasonable code.
>
>Eugene
>
I never said they didn't produce "reasonable code". I simply said that no
compiler can optimize as well as a good human... Otherwise the compiler would
be _very large_ with the thousands of "special cases" that humans have learned
about by experience...
>>-Tom
This page took 0.01 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.