[hatari-devel] Hatari patches for bitplane conversion

[npomarede at corp.free.fr]

On Sat, 25 Jul 2009, Eero Tamminen wrote:

> Hi,
>
> On Saturday 25 July 2009, npomarede at corp.free.fr wrote:
>>> But it's faster to have pFrameBuffer->bFullUpdate first and use a
>>> logical OR (||).  That way wmemcmp() is skipped when not needed (and
>>> it's a bit heavier than a branch from || operation :-)).
> [...]
>>>       lineChanged = pFrameBuffer->bFullUpdate ||
>>>                               ((blitFrom < y) && (blitTo > y)) ||
>>>                               wmemcmp(stplanes, stcopy, no_words);
>>
>> Not wanting to nitpick, but I think the use of | vs || is not always
>> faster with ||, because by using logical OR you will add more
>> tests/branches than by doing a bitwise combination and a single test at
>> the end.
>
> It's hard to imagine how single (or even several) branch(es) could be slower
> than a function call to wmemcmp() that compares one screen line worth of
> bytes before returning...?
>
> Or did you mean that only the first "||" in above quoted lines should
> be "|"? That could be quite confusing to others reading the code...

Yes, I was not suggesting to call wmemcmp in all case, the || is good in 
that case, it was just a more general remark on the fact that sometimes

if ( cond1 | cond2 | cond3 )

could be faster than

if ( cond1 || cond2 || cond3 )

but of course this requires that condX are "simple" to evaluate (not too 
cpu costly).

But I agree that mixing | and || would not be very maintanable. If we 
really require this kind of over optimisation, we'd better coding hatari 
direclly in asm from scratch :)