Re: [AD] ALLEGRO_USE_C vs ALLEGRO_NO_ASM

[Siarhei Siamashka <siarhei.siamashka@xxxxxxxxxx>]

Peter Hull wrote:

> As far as I can tell, ALLEGRO_USE_C is something that we set in the 
> makefile (either statically for OSX/PowerPC or  via a ./configure option 
> on Linux) whereas ALLEGRO_NO_ASM is set by the compiler at build time.  
> There are certain 'valid' combinations of compiler and processor for 
> which assembly code exists, and if it's a different combination, 
> ALLEGRO_NO_ASM is set. This happens in asm.inl.
>
> This relates to Juvinious's problem with his Intel OSX compile. 
> (http://sourceforge.net/mailarchive/forum.php?thread_id=9929081&forum_id=34598 
> <http://sourceforge.net/mailarchive/forum.php?thread_id=9929081&forum_id=34598>)
>
> The problem we found is that OSX/Intel is a 'valid' combination (i86 + 
> gcc) but we don't want asm.inl to include any assembly code. Some 
> functions (_stub_bank_switch was one of them) have both asm and C 
> implementations, but the C version is only defined if ALLEGRO_NO_ASM is 
> set. Since the asm version is in a file which isn't part of the OSX 
> build, these functions are never defined.
>
> What needs to happen is that ALLEGRO_USE_C should override the 
> compiler's decision to use asm or not. As far as we could see in our 
> discussion on #allegro, ALLEGRO_USE_C and ALLEGRO_NO_ASM as synonymous - 
> there are no cases where you'd want one set, but not the other. 
> Therefore they should be merged in my opinion.
>
> Another thing is that alconfig.h independently checks for gcc/i386 and 
> defines a little bit of inline assembly. This needs to be overridden by 
> ALLEGRO_USE_C as well.

I see two configuration options here:
1. use C ABI (as opposed to currently default asm-ABI on x86)
2. avoid using any assembly at all cost

Do they really need to be merged?

Are there any reasons for avoiding assembly completely except for using
allegro with tools like valgrind?