Author: Robert Hyatt
Date: 14:16:44 01/30/03
Go up one level in this thread
On January 30, 2003 at 14:32:37, Ed Schröder wrote:
>On January 30, 2003 at 13:03:49, Robert Hyatt wrote:
>
>>On January 30, 2003 at 07:02:39, Ed Schröder wrote:
>>
>>>On January 29, 2003 at 23:29:36, Russell Reagan wrote:
>>>
>>>>http://members.home.nl/matador/chess840.htm#INTRO
>>>>
>>>>From Ed's page...
>>>>
>>>>switch (piece_type) { case 0 : goto empty;
>>>> case 1 : goto white_pawn; // evaluate white pawn
>>>> case 2 : goto white_knight; // evaluate white knight
>>>> case 3 : goto white_bishop;
>>>> case 4 : goto white_rook;
>>>> case 5 : goto white_queen;
>>>> case 6 : goto white_king;
>>>> case 7 : goto black_pawn; // evaluate black pawn
>>>> case 8 : goto black_knight;
>>>> case 9 : goto black_bishop;
>>>> case 10 : goto black_rook;
>>>> case 11 : goto black_queen;
>>>> case 12 : goto black_king; }
>>>
>>>Any reasonable compiler will translate the above into 2 assembler statements,
>>>someling like:
>>>
>>> mov EAX, dword ptr piece_type
>>> JMP TABLE [EAX]
>>>
>>>Nothing can beat that. Just generate an ASM file to see it work.
>>
>>I would hope *not*.
>
>
>>it should generate:
>>
>> mov eax, piece_type
>> cmp eax,0
>> jb skip
>> cmp eax,12
>> jna table[eax]
>> skip:
>
>Of course, but no need to go into ASM details. The point is its speed, replacing
>a whole block of c-code into a few ASM instructions.
>
>Also in ASM I don't have to do the 0-12 range check because I already know the
>range is valid, so just 2 instructions :)
The advantage of doing it in ASM. However, trying to make it happen in C is
not so easy, although a few compilers have a #pragma you can use to turn off the
range checking...
>
>
>>Somebody had _better check the switch values.
>
>>BTW the jna table[eax] is not particularly efficient from a prediction point of
>>view.
>
>???
>
>Please explain.
>
When you fetch the branch, you don't yet know where it is going. So there is no
way to
predict anything except "it will fall through" even though the branch is
unconditional, so
you stuff the pipeline up a bit until it can evaluate table[eax] into an
address, and then
check that against the BTB for a match.
I haven't tried to study intel's stuff on how this effects the PIV pipeline, but
I suspect it is
at least a bit "messy"...
>Ed
>
>
>>>
>>>Explanation: the trick is that the compiler will generate an internal table (not
>>>visible for the programmer) where it calculates all the effective addresses of
>>>the labels mentioned in the switch/case statement.
>>>
>>>Then using the "piece_type" in register EAX it does an "indirect jump", only a
>>>few cycles.
>>>
>>>Of course, the sequence must be in reasonable order otherwise the compiler will
>>>not recognize the possibility.
>>>
>>>Ed
>>>
>>>
>>>>On one portion of Ed's discussion of Rebel (see above), he talks about using
>>>>"indirect addressing". I get the impression from Ed's words that this method is
>>>>supposed to fast. I understand his discussion to mean that if you create a
>>>>switch statement like he does, you create a jump table and avoid a bunch of
>>>>conditionals.
>>>>
>>>>However, in past discussions, I recall hearing that using a function pointer is
>>>>going to be at least as slow as conditional, so I asked someone, and was told
>>>>that Ed's example should be no different than using a function pointer or
>>>>virtual functions.
>>>>
>>>>Ed talks about this method as if it is a good thing to use. So what is the
>>>>advantage of it? Either someone is mistaken, or Ed and the guy I talked to are
>>>>talking about different things.
This page took 0 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.