This is the mail archive of the cygwin@sourceware.cygnus.com mailing list for the Cygwin project. See the Cygwin home page for more information.
[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index] [Subject Index] [Author Index] [Thread Index]

Re: problem with cygwin version of egcs




> Showing my ignorance here, can you explain in more detail?

To make up an example, consider the JCXZ instruction - jump if CX is
zero.  On older CPUs, it was faster than the corresponding risc-like
options.  This chart shows the number of clocks used if the jump is
taken:

			8086	80486
	JCXZ foo	 16	  8

	CMP CX,0	  4	  1
	JZ foo		 16	  3

	OR CX,CX	  3	  1
	JZ foo		 16	  3

As you can see, on the 8086 it's faster to use JCXZ but on the 80486,
it's faster to use separate compare and jump instructions.

Newer processors optimized the common instructions (mov, or, cmp, jz)
so much that it's now faster to use them than the single JCXZ
instruction.  So, if you're planning on running on an old machine,
you'd want one set of instructions, but if you're running on a newer
machine, you'd want a different set.  Both sets will work perfectly
well on either machine, but different ones are optimal depending on
the machine chosen.  The gcc switch to select 386 vs 486 vs 586 does
exactly that - it chooses among equally functional alternatives based
on which is expected to perform better on the indicated platform.

Note that this does *not* mean that gcc can't choose to use
instructions that won't run on older machines - it certainly has that
option if the gcc programmers have added it.  For example, the 486 has
added various bit test instructions that gcc may know about (I don't
know).  However, the option to enable these extra opcodes is not the
one that we're talking about here, if such an option exists at all.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com