Date: Wed, 21 Feb 2001 22:25:48 +0200 (EET)
From: Tuukka Toivonen <tuukkat AT s-inf-pc24 DOT oulu DOT fi>
To: "pgcc AT delorie DOT com" <pgcc AT delorie DOT com>
Subject: Re: Re: Probably pgcc-2.95.2.1 does not optimized propertly?
In-Reply-To: <E14VeIw-0000Qs-00@smtp4.port.ru>
Message-ID: <Pine.LNX.4.21.0102212215340.6342-100000@s-inf-pc24.oulu.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Reply-To: pgcc AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: pgcc AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com
Precedence: bulk

On Wed, 21 Feb 2001, Nick Kurshev wrote:

> There is only one main cause: POSIX C language is not ready for MMX as it
> always was ready for FPU. Because it lacks many useful features and extensions

Not too ready for FPU either (or x86 was not ready for C). Just see what
	int xx(double y) {
	        return (int)y;
	}
looks in compiled assembly. Hint: it's too long to be listed here. And the
FPU stack is a bit silly anyway.

> Therefore pgcc must be expanded up to new keywords if it pretends on top
> efficient generator of code for mmx unit.

I'm not too sure about this. It already has very powerful inline assembler
that should be possible to be used to #define your own keywords. It's
rumored to have support for MMX even if this is completely undocumented 8-)

And it would be better if the compiler could generate good MMX code
automatically for any C code.

It would also be nice if the compiler could convert direct Fourier
transform O(N^2) automatically into FFT too...