-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chia-I Wu wrote:
> On Mon, Oct 05, 2009 at 11:16:17AM -0600, tom fogal wrote:
>> Chia-I Wu <olva...@gmail.com> writes:
>>> +#ifdef USE_X86_ASM
>>> +extern const GLubyte gl_dispatch_functions_start[];
>>> +#endif
>> I'm a little concerned that something like this is changing. Your
>> introductory comment doesn't mention anything about modifying anything
>> to do with the dispatch itself; it seems like a table is changing from
>> an unordered -> ordered, and an algorithm from linear search -> binary
>> search. Thus changing the declaration type / decl. location of the
>> table itself doesn't seem like it would happen.
> There is no functional change here. The original code reads
>
> -#ifdef USE_X86_ASM
> -
> -#if defined( GLX_USE_TLS )
> -extern GLubyte gl_dispatch_functions_start[];
> -extern GLubyte gl_dispatch_functions_end[];
> -#else
> -extern const GLubyte gl_dispatch_functions_start[];
> -#endif
> -
> -#endif /* USE_X86_ASM */
>
> Since gl_dispatch_functions_end is never used, and
> gl_dispatch_functions_start is never modified, they are simplified.
But gl_dispatch_funcitons_start is declared (in the assembly stub file)
differently in these cases. Now the extern doesn't match the declaration.
>>> + GLuint lo, hi;
>>> +
>>> + /* binary search */
>>> + lo = 0;
>>> + hi = ARRAY_SIZE(sorted_static_function_offsets);
>>> + while (lo < hi) {
>>> + const glprocs_table_t *entry;
>>> + GLuint mid = (lo + hi) / 2;
>>> + int res;
>>> +
>>> + entry = &static_functions[sorted_static_function_offsets[mid]];
>>> + res = strcmp(_glapi_static_entry_name(entry), funcName);
>> This might be okay, but I don't want to scroll all the way up to check,
>> especially since I might have snipped it ;) Anyway, either this strcmp
>> should have a MANGLE case or _glapi_static_entry_name should always
>> return "glWhatever" even when the symbol is "mglWhatever".
> That would be the latter case.
>> Secondly, any chance of using stdlib's bsearch here?
> I just had a look at _mesa_bsearch. It seems bsearch is not universally
> available? I think the inline version is also slightly faster.
Madness. bsearch has been part of standard C since 1989. We can be
pretty sure that the implementation of bsearch, qsort, and others in the
C library have been thoroughly debugged. I think that peace of mind is
worth more that the small speed-up gained by open coding.
I strongly recommend you pick up a copy of Jon Bentley's "Programming
Pearls" and read chapter 2. It looks like part of the chapter, starting
with page 11, is available on Google books. See also:
http://googleresearch.blogspot.com/2006/06/extra-extra-read-all-about-it-nearly.html
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkrLh+YACgkQX1gOwKyEAw+zYwCeKpoonWXZ70FyUxWmKRn2bE4G
AF8An0IsArTI0bGyZ8tlXOv0pjATpZZU
=ZnPv
-----END PGP SIGNATURE-----
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Mesa3d-dev mailing list
Mesa3d-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mesa3d-dev
