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

On 5/18/2012 4:37 PM, JonY wrote:
>> OK, OK. Tack on "for most applications" to my statement (I thought it
>> was assumed).
> I believe the same was said when transitioning from 16bit to 32bit.
If so then they were wrong.
> Those are just pointers, instructions do not necessary double in size,
I was under the impression that the instruction size matches the natural 
word size of the machine. Therefore they would be 64 bit instructions.
> we are talking about CISC CPUs after all, besides, nearly all registers in 64bit long mode doubled in size, not to mention the number of them increased, see AMD64 GPRs compared to x86 GPRs.
I believe my AMD64 is considered a RISC computer. According to 
http://www.tek-tips.com/faqs.cfm?fid=788 "The K5 and K6 series are 
internally a highly parallel RISC processor using an x86 decoding 
front-end". And according to 
https://en.wikipedia.org/wiki/Instruction_set: "In some architectures, 
notably most reduced instruction set computers (RISC), instructions are 
a fixed length, typically corresponding with that architecture's word 
size". Things might be different now. I really don't keep up with 
processors anymore.
>>> Besides, who cares that much about the image size these days?  We
>>> don't, within reason.
>> I, for one, do. These larger binary images need to fit in memory and
>> reserve swap space and virtual memory. I see virtual memory foot prints
>> in the hundreds of megs if not gigs. Chrome on my Ubuntu box regularly
>> takes 1-2 gig of virtual memory and hundreds of megs of real memory. If
>> you run many things like I do you quickly get to the point where your
>> swapping and thrashing and waiting for the OS to manage many, many more
>> fragments of memory. All my systems have 4 gig (XP at work, a couple of
>> Ubuntu boxes at home) and they all come under memory pressure at times.
>> Small is beautiful.
> No modern OS actually loaded the entire executable into memory, not
> since the MSDOS days, they are mapped, like pagefiles.
So what.
>> All of this is irrelevant to the request to make say /bin/ls 64 bit.
> And why not?
And why not what? Your question doesn't make sense.
> Even if the rest of the system has transitioned to 64bit?
Even if the rest transitioned what? Your question doesn't make sense again.
> If you didn't know, GCC does win64 applications fine. The hard part for porting Cygwin to win64 is the LP64 vs LLP64 issue. The former is used by newlib, it is not easy to transition to Win64 LLP64.
I still don't understand what having a 64 bit version of ls or grep will 
do for ya...
-- 
Andrew DeFaria <http://defaria.com>
I've taken a vow of poverty -- to annoy me, send money


--
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

  reply	other threads:[~2012-05-19  1:15 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 [this message]
2012-05-19  2:40           ` JonY
2012-05-19  3:26             ` Andrew DeFaria
2012-05-19  5:05               ` JonY
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='jp6s6r$cnr$1@dough.gmane.org' \
    --to=andrew@defaria.com \
    --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).