From: "Marp" 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: 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" 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