This is the mail archive of the
mailing list for the Cygwin project.
Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
On 05/18/2012 07:39 PM, JonY wrote:
Really? OK - Show me! Because the first mention of even CISC was *your*
posting two posts ago. Just because you were talking about x86 does not
mean that I was talking about x86.
No, we are talking about x86, not MIPS/ARM type RISC.
I was under the impression that the instruction size matches the natural
word size of the machine. Therefore they would be 64 bit instructions.
I was not talking about your x86 - you were.
Which do not apply to CISC CPUs, whatever implementation underneath is
tangent to the user code ISA, the opcodes did not double in size. Please
at least look at the x86 opcode, they are known to have variable lengths.
Excuse me but it seems to me that right now it is being avoided quite
successfully. Cannot be avoided? Really?
Since 64-bit mode cannot be avoided,
I still don't understand what having a 64 bit version of ls or grep will
do for ya...
If a 32 bit executable will run on a 64 bit machine, but a 64 bit
executable will not run on a 32 bit machine, there's no good
justification to have to maintain two different builds and sets of bits.
there is simply no reason to keep
legacy mode applications and all that baggage if you can easily rebuild
and move to 64-bit mode.
When 32 bit just came around, you betcha I did - and so did you.
You don't keep 16-bit programs lying about when there are 32-bit
programs doing the same thing right?
All that said, I'd like to see it all move to 64 bit and I know it will,
eventually. But I can understand the rational for not doing it at this time.
Andrew DeFaria <http://defaria.com>
I'm not into working out. My philosophy is no pain, no pain.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple