From:	"Marp" <marp AT 0 DOT 0 DOT 0 DOT 0>
Newsgroups:	comp.os.msdos.djgpp
Subject:	Re: Support for higher end cpus
Date:	Sat, 30 Dec 2000 23:07:38 -0500
Organization:	MindSpring Enterprises
Lines:	74
Message-ID:	<92mb9j$soc$1@slb6.atl.mindspring.net>
References:	<f_v36.53630$59 DOT 14770834 AT news3 DOT rdc1 DOT on DOT home DOT com>
NNTP-Posting-Host:	04.30.99.b9
X-Server-Date:	31 Dec 2000 04:05:07 GMT
X-Priority:	3
X-MSMail-Priority:	Normal
X-Newsreader:	Microsoft Outlook Express 5.50.4522.1200
X-MimeOLE:	Produced By Microsoft MimeOLE V5.50.4522.1200
To:	djgpp AT delorie DOT com
DJ-Gateway:	from newsgroup comp.os.msdos.djgpp
Reply-To:	djgpp AT delorie DOT com

"Tom ST Denis" <tstdenis3160 AT home DOT com> wrote in message
news:f_v36.53630$59 DOT 14770834 AT news3 DOT rdc1 DOT on DOT home DOT com...
> I know (from my earlier post) that DJGPP can understand switches such
> as -march=k6 or -march=i686 but the code it produces doesn't seem to be
any
> faster (substantially anyways) then -march=i486.  The output code *is*
> different just not improved.
>
> My basis for this judgement is my compilation of Allegro and my updated
> Plush lib.  I get about the same FPS in my Plush examples when I use
> march=k6 (on my Athlon) then I do with march=i486.
>

The compiler definitely has its limits as to how much it can optimize a
program. It can only go so far because it has to produce code that's
logically equivalent to the code that you feed it. I think you will find
that gcc produces code that's as good as any code made by a proprietary
compiler. You should try to write code that is as efficient as possible to
get the best results.

You can improve the performance of allegro programs that use graphics by
getting a vbe/af driver for your video card. See the allegro web site for
details about freebe ( http://www.talula.demon.co.uk/ ).

> Will there be any development for supporting the K7/PIII/PIV?  It would
make
> DJGPP (and it's GCC derivatives such as CYGWIN) jump way ahead of VC++
6.0.
> If GCC supported these new cpus I bet alot of people would be happy!  I
know
> I would.
>

Specific support for these newer cpus may develop eventually, but these
things take time. It can develop faster if more people with the necessary
skills make contributions (and people who don't have the skills themselves
can pay someone who does if it's that important to them). You must also keep
in mind that the compiler can only do so much to optimize your code, so
don't expect any miracles if and when such support arrives. The easiest
solution is to buy faster hardware ;-)

BTW cygwin is not a derivative of djgpp. GCC was developed by the GNU
project to go with the operating system they are making. Since the sources
to these things are freely available, many people thought it would be useful
to port these programs to other systems. DJGPP happens to be a dos port of
gcc, and cygwin happens to be a windows port of gcc. Cygwin is not a port of
DJGPP to windows.

> For the most part I think just the way the code is rescheduled is the only
> thing the compiler *could* do.  But often that makes a big difference.
> Other things such as MMX/3dNOW instructions could be provided by a
libext.a
> or something that is optional for a DJGPP installation.
>

You can write a library that makes use of such instructions when it's
functions are used by a program. If you are suggesting something that would
provide support for those instructions in some manner that's mostly
invisible, I'm not sure how something like that could be done, but it's
certainly not a bad idea. Maybe someone who knows more can comment on
this...

> I have no clue about compiler development or serious optimization tricks.
I
> just use the compiler and write what I think is efficient algorithms... so
I
> can't help develop this...wish I could..

Doing the best you can is all you can be expected to do :-)

Marp

- Raw text -