Allegro assembly code (was: Re: [AD] proposing a new official .lib name for VC static CRT version)

[Andrei Ellman <ae-a-alleg@xxxxxxxxxx>]

Elias Pschernig wrote:
> Maybe it's time to remove the asm version in both branches?
> [...]
> - reduced performance on things like intel 386 and 486 (are they still
> in use though, and does Allegro still work on them?)

I can confirm that a game I compiled with DJGPP and Allegro 4.2.0 still 
works on a '486 laptop.

About 2.5 years ago, I tried unsuccessfully to get one of the Allegro 
4.0.3 examples (exdbuf) to work on a '386SX laptop (that's without the 
FPU). The program crashed with an 'illegal instruction' error, meaning 
that even though exdbuf does not use the FPU, I suspect that the GCC 
runtime does try and do something with the FPU. However, I was not sure 
which flags I needed to use to get GCC to produce a version that does 
not require the FPU. After plenty of tweaking of the makefile, I did 
manage to get the DEBUG version of exdbuf to work, but not the release 
version. Just out of interest, does anyone know which flags are needed 
to build executables with GCC that will work on a 386SX? Alas, I do not 
have access to a 386DX, so can't tell you if it works on one of those or 
not.

Anyway, now that compilers have improved, is there still an advantage to 
using ASM even on 386s and 486s, or are the compilers good enough at 
creating C code just as fast or even faster than what we already have - 
even on the 386s and 486s? Also, are the compilers smart enough to be 
able to guess when they should make use of things like MMX, SSE etc 
instructions and try to vectorise similar operations so they can be 
speeded up on such proccessors?

I think that one of the advantages of getting rid of the Assembly code 
is that we don't have to write some assembly code optimised for each 
variant of the x86 - we should just leave it up to GCC's optimisation-flags.

AE.