[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
> It can't hurt, can it? IMHO it's nontrivial to implement (so
> it makes sense to have it in a library) and is unlikely to
> need maintainance or change its API (so no gain to make it
> internal). But I don't mind very much.
The problem is that we have no function using doubles in the API (apart from
two little Unicode functions), so
void al_sincos(double x, double *s, double *c);
would certainly look a little astonishing to the user.
I'd rather make it an internal function (_al_sincos for example), inlined
for the Allegro sources, but exported via src/inline.c though, with the help
of some preprocessor trickery. This way the problem with math.h goes away
and you still can have access to it in your program like to any other
exported internals.
> No, I meant that my inline asm al_sincos(), which does not check
> the arguments, was as fast as djgpp's non-inline sincos(), which
> does check arguments. They both are twice as fast as sin()
> followed by cos().
Ha! Then I'm relieved ;-)
> I'd interpret this as the sincos instruction being slow, so it makes
> sense to write it, and it's even so slow that the relative gain of
> inlining it is small.
Ok. Let's try to inline it for the library sources though.
--
Eric Botcazou
ebotcazou@xxxxxxxxxx