[ 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