From: Eli Zaretskii Newsgroups: comp.os.msdos.djgpp Subject: Re: Why did ID choose DJGPP for Quake? Date: Wed, 5 Jan 2000 10:48:32 +0200 Organization: NetVision Israel Lines: 47 Message-ID: References: <199912312332 DOT RAA15911 AT lakdiva DOT slt DOT lk> <84tj7t$si3$1 AT soap DOT pipex DOT net> NNTP-Posting-Host: is.elta.co.il Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Trace: news.netvision.net.il 947062317 4675 199.203.121.2 (5 Jan 2000 08:51:57 GMT) X-Complaints-To: abuse AT netvision DOT net DOT il NNTP-Posting-Date: 5 Jan 2000 08:51:57 GMT X-Sender: eliz AT is In-Reply-To: <84tj7t$si3$1@soap.pipex.net> To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk On Tue, 4 Jan 2000, Stephen Howe wrote: > Your right. But I would be looking separately at > > (i) integer optimisation > (ii) fp optimisation > (iii) space and time saving optimisations > (iv) loop optimisations > (v) stack lifetime optimisations > (vi) tail optimisations > etc. AFAIK, this is already done on the page where Salvador pointed you. > Speaking honestly, there are a number of areas where the compiler & > libraries could be improved. For instance, the 32-bit maths libraries are > built assuming that your executables (32-bit DOS, Win32, OS/2 etc) could be > running on a 386+287 combination which implies fwait opcodes. Well how many > people are running on that combination? Not many, I bet. For everyone > running 486 or better, these can be removed. What library, specifically, are you talking about? The DJGPP library has only 11 FWAIT instructions in 8 of its math functions; the next version of the library (to be released very soon) reduces this to 3 FWAIT instructions in 3 functions. I don't see any problem here. The compiler might emit FWAIT while compiling FP code, but I'd expect latest versions of GCC to omit them when the command-line switches tell it to use Pentium as the target. So it seems that this is a non-issue. > Actually IMHO a test of how fast the mode switching routines are > would really indicate how good a protected mode environment > really is specially for a real mode OS like DOS(the quality of the > compiler also plays a part true enough). > >> > > At this point are you talking about 32-bit DOS? If so, would you not mostly > be measuring the DOS extenders performance Not quite true. Calling real-mode services has different overheads, depending what environments and waht methods are used to call real-mode code from a protected-mode program. Part of this overhead is in the library (copying data to conventional memory, preparing the real-mode call structures, etc.).