public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: JonY <jon_y@users.sourceforge.net>
To: cygwin@cygwin.com
Subject: Re: Is the Latest Release of Cygwin supported on Windows Server 8/2012
Date: Sat, 19 May 2012 05:05:00 -0000	[thread overview]
Message-ID: <4FB72A0C.4030206@users.sourceforge.net> (raw)
In-Reply-To: <jp73rf$lnf$1@dough.gmane.org>

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

  reply	other threads:[~2012-05-19  5:05 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-05-18 14:46 Cary Conover
2012-05-18 14:58 ` Andrew DeFaria
2012-05-18 17:59   ` James Johnston
2012-05-18 22:46     ` Andrew DeFaria
2012-05-18 23:38       ` JonY
2012-05-19  1:15         ` Andrew DeFaria
2012-05-19  2:40           ` JonY
2012-05-19  3:26             ` Andrew DeFaria
2012-05-19  5:05               ` JonY [this message]
2012-05-21 17:36           ` James Johnston
2012-05-21 20:01             ` Andrew DeFaria
2012-05-21 17:18       ` James Johnston
2012-05-21 17:35         ` Andrew DeFaria
2012-05-21 20:49           ` Warren Young
2012-05-21 21:30             ` Andrew DeFaria
2012-05-21 22:15 Matt Seitz (matseitz)
2012-05-21 22:44 ` Andrew DeFaria
2012-05-21 22:50   ` Andrew DeFaria
2012-05-21 23:04     ` Matt Seitz (matseitz)
2012-05-22  0:27       ` Andrew DeFaria
2012-05-22 16:58         ` Matt Seitz (matseitz)
2012-05-26 23:43 ` Linda Walsh
2012-05-27  0:51   ` Daniel Colascione
2012-05-27 11:30     ` Linda Walsh
2012-05-27 17:37       ` Tim Prince
2012-05-27 19:19         ` Linda Walsh
2012-05-27  7:30   ` Tim Prince
2012-05-28 21:21     ` Christopher Faylor

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4FB72A0C.4030206@users.sourceforge.net \
    --to=jon_y@users.sourceforge.net \
    --cc=cygwin@cygwin.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).