Mail Archives: djgpp/2000/01/05/10:41:22
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.).
- Raw text -