X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-1.7 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,T_RP_MATCHES_RCVD
X-Spam-Check-By:	sourceware.org
Message-ID:	<4FC2663A.4000309@tlinx.org>
Date:	Sun, 27 May 2012 10:36:58 -0700
From:	Linda Walsh <cygwin AT tlinx DOT org>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.24) Gecko/20100228 Lightning/0.9 Thunderbird/2.0.0.24 Mnenhy/0.7.6.666
MIME-Version:	1.0
To:	"cygwin AT cygwin DOT com" <cygwin AT cygwin DOT com>
Subject:	Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
References:	<70952A932255A2489522275A628B97C31348C437 AT xmb-sjc-233 DOT amer DOT cisco DOT com> <4FC169D9 DOT 6090107 AT tlinx DOT org> <4FC16A97 DOT 8020309 AT dancol DOT org> <4FC1D815 DOT 40306 AT tlinx DOT org> <4FC21033 DOT 4030405 AT aol DOT com>
In-Reply-To:	<4FC21033.4030405@aol.com>
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.com>
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com

Tim Prince wrote:

> CPUs have been adding microcode continually for better optimization of 
> the gcc -m32 string moves, even though new CPUs are designed primarily 
> for 64-bit OS. 

-----
	It's not the OS, machine and the width of the data path.
If you are operating in 32 bit mode, you are using 32 bit registers,
16 bit mode used AX, BX, CX  -- 16 bit registers.  32 bit mode went
to Double-words and used a D prefix for registers, 64 bit mode went
to Quad-words with Q prefixes.   a 32 bit compiler doesn't generate
the operands for Qword moves.

	These are HW issues, independent of the OS.

 The same data move instructions are present in either 
> OS.  It took years for glibc to implement efficient string moves for 
> x86_64, ...

	Yeah, and?   It's there now.

 and those still bump up against the question whether they always 
> use code which runs on the CPUs of a decade ago.

	Yup....you can compile a program for 32 bit mode and get code
that will run on old cpu's -- it won't be as efficient -- which is
the entire point of this discussion.


> 
> CPU designers spend lots of cycles simulating runs of future CPUs on 
> instruction traces of current applications.  There's a lot more 
> quantitative analysis there then in any assertions I've seen about the 
> future of cygwin.

====
	Of course... But we are not just talking about cygwin.  We are
talking about whether or not there is a benefit in compiling and using
64-bit technology over current 32 bit technology.  That benefit IS there.
Whether or not cygwin is in a position to leverage that -- or when cygwin
will be in a position to leverage that is independent of the benefit that
is there.  Cygwin-64 will happen when it happens.  But to try to justify
it not happening because some claim there would be no benefit is the
fallacious argument.


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

- Raw text -