From mboxrd@z Thu Jan 1 00:00:00 1970 From: DJ Delorie To: earnie_boyd@yahoo.com Cc: cygwin@sourceware.cygnus.com Subject: Re: problem with cygwin version of egcs Date: Mon, 08 Mar 1999 17:07:00 -0000 Message-id: <199903090107.UAA19534@envy.delorie.com> In-reply-to: < 19990309005620.2525.rocketmail@send102.yahoomail.com > (messagefrom Earnie Boyd on Mon, 8 Mar 1999 16:56:20 -0800 (PST)) References: <19990309005620.2525.rocketmail@send102.yahoomail.com> <19990309005620.2525.rocketmail@send102.yahoomail.com> X-SW-Source: 1999-03/msg00274.html > 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 From mboxrd@z Thu Jan 1 00:00:00 1970 From: DJ Delorie To: earnie_boyd@yahoo.com Cc: cygwin@sourceware.cygnus.com Subject: Re: problem with cygwin version of egcs Date: Wed, 31 Mar 1999 19:45:00 -0000 Message-ID: <199903090107.UAA19534@envy.delorie.com> References: <19990309005620.2525.rocketmail@send102.yahoomail.com> X-SW-Source: 1999-03n/msg00274.html Message-ID: <19990331194500.TvoasnLqPe34dO3vqTgZS8P57mbzcq4QvRDZC1l_zt8@z> > 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