From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21754 invoked by alias); 21 May 2012 17:36:48 -0000 Received: (qmail 21595 invoked by uid 22791); 21 May 2012 17:36:45 -0000 X-SWARE-Spam-Status: No, hits=-1.4 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_NONE,RCVD_IN_HOSTKARMA_YE,RCVD_IN_SORBS_WEB,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mout.perfora.net (HELO mout.perfora.net) (74.208.4.195) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 21 May 2012 17:36:25 +0000 Received: from JamesJPC (75-146-80-177-Chattanooga.hfc.comcastbusiness.net [75.146.80.177]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MD9dM-1SI9zl2ZmW-00Gpt3; Mon, 21 May 2012 13:36:23 -0400 From: "James Johnston" To: References: <000601cd351f$da0e4900$8e2adb00$@motionview3d.com> <4FB6DD43.9080407@users.sourceforge.net> In-Reply-To: Subject: RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012 Date: Mon, 21 May 2012 17:36:00 -0000 Message-ID: <005001cd3778$3d553550$b7ff9ff0$@motionview3d.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com X-SW-Source: 2012-05/txt/msg00448.txt.bz2 > 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. Hey, why isn't "ls" a 16-bit program? Realistically, it does not need anyt= hing offered by 32-bit architectures to do its job... > > 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=3D788 "The K5 and K6 series are > internally a highly parallel RISC processor using an x86 decoding front-e= nd". The key word is **internally** - also known as "hidden implementation detai= l." Those processors still present a CISC-type instruction set, as it says= "x86 decoding front-end". The core, proprietary architecture is not acces= sible to you or Cygwin. You still have to pretend you are targeting the CI= SC environment, even if the underlying implementation isn't. Maybe the und= erlying implementation does use fixed 64-bit wide instructions, but you don= 't get to write for it. 64-bit Intel Architecture didn't magically/radically change the instruction= set to be a new one. They had to preserve backwards-compatibility, so the= y kept the CISC instruction set. 64-bit is just an additional set of exten= sions thrown on top of the already-bloated x86 architecture. (Which happen= s to be detrimental to the hardware, since they have to create special deco= ders to translate the crufty old instruction set known as x86).=20 If you want to reduce bloat, go use a newer architecture like ARM. One nee= d only look at the first alphabetically-listed x86 instruction to see how b= ad it is! Example: "AAA ASCII adjust AL after addition used with unpacked binary cod= ed decimal" Really...? > 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". And this would probably be true if you weren't working with an x86 decoder = front-end that forces use to use variable-width instructions instead.=20 > > No modern OS actually loaded the entire executable into memory, not > > since the MSDOS days, they are mapped, like pagefiles. > So what. Because your arguments about reduced performance seemed to imply that you t= hought this was the case, when it is not. A bloated EXE in and of itself does not create system memory pressure. It = is only when large portions of that EXE are used and must be loaded into ph= ysical memory. For example, create an EXE with a large (e.g. 500 MB) resource in it. It w= ill load instantly and create no major memory pressure. Only when the reso= urce is accessed will there be memory pressure.=20 > > Even if the rest of the system has transitioned to 64bit? > Even if the rest transitioned what? Your question doesn't make sense agai= n. I think he means, if other parts of Cygwin move to 64-bit to address real p= roblems (e.g. due to reduced address space, or the need to run on a 64-bit = only environment), would you still keep "ls" as 32-bit and run it in a mixe= d 32/64-bit environment? Or move the entire platform to 64-bit, just to ke= ep things consistent? (See my snarky "16-bit" comment at the top...) -- 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