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
