On Mon, Jul 01, 2002 at 07:43:40AM +0100, Keith Whitwell wrote:
>Jos� Fonseca wrote:
[...]
>>
>>I think this is a bug in Mesa. First because a macro should generally
>>behave as an
>>ordinary function, unless there is a very special reason not to do so.
>
>Hmm, not really, this is something people are supposed to understand about
>macros generally - it's one of the classic C programming mistakes to assume
>that macros evaluate their arguments exactly once.
I was aware of that common pitfall, but I though that it was common [and
good] practice to define the macros to avoid exactly this pitfall. Imagine
if in the linux kernel, for example, macros such as cpu_to_le32 didn't
followed that convention.
Of course that many times the solution is to rewrite the macro as a inline function.
>
>>Second because this relies on compiler optimization to remove the
>>redundancy of calculating OUT twice. Although I haven't check what is
>>the exact assembler output of gcc, the call of INTERP_F with
>>calculations in
>>its arguments is used on the default vertex template, hence used across
>>all drivers. See src/tnl_dd/t_dd_vbtmp.h:669:
>
>You should check the output. Gcc does lots of
>common-subexpression-elimination (cse). I'd be suprised if it didn't find
>this one.
>
You're right in respect with gcc. The following code in t_dd_vbtmp.h
INTERP_F( t, dst->v.u0, out->v.u0 * qout, in->v.u0 * qin );
compiles into
fld %st(1)
fld %st(1)
fxch %st(1)
fmuls 24(%ebx)
fxch %st(1)
fmuls 24(%edx)
fsub %st(1), %st
fmul %st(4), %st
faddp %st, %st(1)
movl -36(%ebp), %eax
fstps 24(%eax)
that is, three fp multiplications in total, so OUT isn't recalculated (as
that would result in four).
Jos� Fonseca
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
