This is the mail archive of the
cygwin
mailing list for the Cygwin project.
RE: Is the Latest Release of Cygwin supported on Windows Server 8/2012
> 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 anything 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=788 "The K5 and K6 series are
> internally a highly parallel RISC processor using an x86 decoding front-end".
The key word is **internally** - also known as "hidden implementation detail." Those processors still present a CISC-type instruction set, as it says "x86 decoding front-end". The core, proprietary architecture is not accessible to you or Cygwin. You still have to pretend you are targeting the CISC environment, even if the underlying implementation isn't. Maybe the underlying 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 they kept the CISC instruction set. 64-bit is just an additional set of extensions thrown on top of the already-bloated x86 architecture. (Which happens to be detrimental to the hardware, since they have to create special decoders to translate the crufty old instruction set known as x86).
If you want to reduce bloat, go use a newer architecture like ARM. One need only look at the first alphabetically-listed x86 instruction to see how bad it is!
Example: "AAA ASCII adjust AL after addition used with unpacked binary coded 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.
> > 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 thought 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 physical memory.
For example, create an EXE with a large (e.g. 500 MB) resource in it. It will load instantly and create no major memory pressure. Only when the resource is accessed will there be memory pressure.
> > Even if the rest of the system has transitioned to 64bit?
> Even if the rest transitioned what? Your question doesn't make sense again.
I think he means, if other parts of Cygwin move to 64-bit to address real problems (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 mixed 32/64-bit environment? Or move the entire platform to 64-bit, just to keep 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