Is the Latest Release of Cygwin supported on Windows Server 8/2012

Linda Walsh
Sun May 27 19:19:00 GMT 2012

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. 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:
Unsubscribe info:

More information about the Cygwin mailing list