Re: Allegro assembly code (was: Re: [AD] proposing a new official .lib name for VC static CRT version) |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: alleg-developers@xxxxxxxxxx
- Subject: Re: Allegro assembly code (was: Re: [AD] proposing a new official .lib name for VC static CRT version)
- From: Chris <chris.kcat@xxxxxxxxxx>
- Date: Mon, 16 Jan 2006 04:05:52 -0800
- Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:from:to:subject:date:user-agent:references:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:message-id; b=n6aPuW/+BVRQFwTJ3f8OvazpcSaFebm63quy5ZR0yqMDPzPs9inaukHtjS6wonfzdccxpGTdLSQ9OiZPpX6Vaiv4VmsNdacIpkjfpyU48j5rZ0C6RvJn6TssoyhSL6iATYSyAAXqn1iDPH8ToDxJ74M54zpKvmOiOLWzaJVYQZg=
On Monday 16 January 2006 03:17, Andrei Ellman wrote:
> Just out of interest, does anyone know which flags are needed
> to build executables with GCC that will work on a 386SX?
IIRC, there's a package that's distributed with DJGPP for doing floating point
stuff in software (and thus using it on 386SX and 486SX). As far as I
remember, it was used automagically.
> 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?
It's certainly possible. Feel free to do benchmarks. :)
> 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?
If you use the -march= option, it should turn on mmx, 3dnow, sse and stuff if
the given CPU is capable of it. There are also -mmmx/-m3dnow/etc switches to
do it manually. The -mtune= (formerly -mcpu=) option, which is implied when
using -march, is supposed to generate code that runs best on the given CPU,
though still retain compatibility for processors back to the one specified by
-march (386 by default, I think).