Re: [AD] Header splitup.

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


> That is right. But it won't include anything if no asm version of the
> routines are available for the current platform, so...

That's precisely where lies IMHO the cleverness of asm.inl: it knows which
asm version to pick up (among the three ones available) and automatically
defines ALLEGRO_NO_ASM if the platform doesn't support asm, thus instructing
other headers to define the corresponding C version.

> What I don't understand is that if no asm version of, say, bmp_read_line,
> is available for BC++, then it ought to define them in alconfig.h (I
> think, it might be another header). Which should be included where
> appropriate to be defined whenever used.

Yes, another solution.

> > IMHO gfxasm.inl and mathasm.inl are useless because you can't
> > include them without including *each time* gfx.inl and fmaths.inl
> > (respectively) before.

After actually.

> That is on purpose. They are asm versions of stuff that should be defined
> in, eg, gfx.inl or fmaths.inl.

Quite right. So why not simply merge them in gfx.inl and fmaths.inl ?
Both files (gfxasm.inl and mathasm.inl) are wrappers around a wrapper
(asm.inl) and contain 3 lines of code.

> On second thought, I think it would be better to include a fallback C
> version of these routines in gfx.inl and fmaths.inl, if no asm version is
> available for a particular platform.

That's the current situation.

> Where would you put the asm version of the routines that currently are
> in gfxasm.inl ? They must be somewhere...

gfxasm.inl and mathasm.inl don't contain any routine (see above).

--
Eric Botcazou
ebotcazou@xxxxxxxxxx



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/