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

[JonY <jon_y at users dot sourceforge dot net>]

On 5/19/2012 11:25, Andrew DeFaria wrote:
> On 05/18/2012 07:39 PM, JonY wrote:
>>> I was under the impression that the instruction size matches the natural
>>> word size of the machine. Therefore they would be 64 bit instructions.
>> No, we are talking about x86, not MIPS/ARM type RISC.
> 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.
>> 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.
> I was not talking about your x86 - you were.

Cygwin runs only on x86 Windows, which is on a CISC CPU, with variable
length instructions.

You maintained that instruction sizes are doubled. This is not true of
CISC, especially the entire x86 line. You veered into AMD64 having a
RISC implementation underneath, which is of little consequence since it
is at the microcode level. This technique is in use since the Pentium
Pro days.

>>> I still don't understand what having a 64 bit version of ls or grep will
>>> do for ya...
>> Since 64-bit mode cannot be avoided,
> Excuse me but it seems to me that right now it is being avoided quite
> successfully. Cannot be avoided? Really?
>> 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.
> 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.

This is no reason to hold back on transitioning to 64bit though. Once
you do, there is little reason to keep the baggage if all your programs
don't need it. This was what OP was concerned about.

>> You don't keep 16-bit programs lying about when there are 32-bit
>> programs doing the same thing right?
> When 32 bit just came around, you betcha I did - and so did you.
> 
> 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.

You have to start somewhere somehow, perhaps with a tiny step, how it
goes depends on the Cygwin development committee.

Attachment: signature.asc
Description: OpenPGP digital signature