This is the mail archive of the cygwin mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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?
-- 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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |