Author Topic: 64 bit processors? (Read 1026 times)

beet1e · « **on:** August 28, 2004, 06:58:26 AM »

I don't know how the new 64-bit architecture is going to work. Is the extension from 32 just to provide increased addressability, or is there to be a new 64-bit instruction set? If a 64-bit instruction set, will a 64 bit OS be needed in order to utilise the 64-bit CPU capability? If so, what 64-bit OS are in the pipeline?

Edbert · « **Reply #1 on:** August 28, 2004, 08:04:42 AM »

The 64bit version of XP has been in beta relese for a long time. Full release is extected in early 2005. Of course that means all of your 32 bit applications will be run in emeulation mode, much like your 16 bit apps are being run now.

Kev367th · « **Reply #2 on:** August 28, 2004, 03:33:06 PM »

Wrong Edbert, the Athlon 64 has a full 32 bit with 64 bit extensions instruction set. There is NO emulation involved.
Certain 'other' 64 bit CPUs do use emulation. See any article on the Itanic, oops I mean Itanium

XP64 is available as a free beta download form Microsoft site.

Director · « **Reply #3 on:** August 28, 2004, 05:20:51 PM »

Even if emulation was in the picture, a 64-bit processor should run a 32-bit application nearly as fast as an upper-range 32-bit processor. It won't be as fast as the fastest 32-bit processor, but it'll be close.

And of course, a program compiled for a 64-bit processor will simply scream in comparison to the 32-bit version of itself.

Kev367th · « **Reply #4 on:** August 28, 2004, 06:39:26 PM »

You would think so, but the Itanium is famous for being extremely slow running 32 bit apps. Slower than an equivalent 32 bit CPU.

Yup, games houses are drooling with what they can do with 64 bit for games!

beet1e · « **Reply #5 on:** August 29, 2004, 01:11:29 AM »

I worked on IBM mainframes for many years as a programmer, then a DBA (IMS & DB2). The OS, which was called MVS, used 24 bit addressing up until about 1985. After that, IBM introduced 31 bit addressability. The new OS became known as MVS/XA.

Apps ran much much faster, the main reason being that with 24bit addressability, the address limit was 16megs. The area of storage "below the line" (the 16MB line) no longer created a bottleneck. The reduction in virtual storage page faults was greatly reduced, and was the main reason for performance improvements.

bloom25 · « **Reply #6 on:** August 29, 2004, 05:46:24 PM »

Beetle, the AMD64 instruction set is a superset of the standard x86 ISA. It simply extends x86 to support 64 bit addressing and widens all GPRs to 64 bits. In addition AMD64 makes some enhancements to the x86 ISA by doubling the number of directly accessible GPRs and doubling the number of 128 bit XMM registers. (XMM registers are used for SSE, 3dNow, SSE2, etc.) The default operand size is still 32 bits.

The Athlon 64 CPUs have 2 64 bit operating modes, a true 64 bit mode and a compatibility mode. Compatibility mode allows 32 bit applications to run without recompiling them. Full 64 bit long mode will require an application recompile, which will allow the applications to make use of the additional registers AMD64 has added. The 64 bit version of Windows runs in long mode, but 32 bit applications use what Microsoft is calling WOW (Windows on Windows). Essentially the 32 bit applications still run under a 32 bit version of Windows, which itself is running as an application on the 64 bit version of Windows. There really isn't much of a performance hit in doing this as the enhancements to x86 that AMD64 has added make up for the small performance penalty of WOW.

Edit: Kev, the 64 bit version of Windows DOES run legacy 16/32 bit applications in a software emulation mode (WOW - Windows on Windows). The difference with the Athlon 64 vs Itanium is that AMD64 is a superset of x86 with enhancements, meaning it simply extends x86 to 64 bits. Thus there is little to no performance hit. All WOW is really doing is bit thunking (i.e. extending 32 bit arguments to 64 bit) to allow them to be compatible with a 64 bit OS. The Athlon 64 CPU does have a compatibility mode, allowing 32 bit apps to run without recompiling them, but that does not allow the additional GPR and XMM registers to be used.

The Itanium is completely different in that it actually translates x86 instructions to IA64 instructions. That is why it performs so poorly, as IA64 and x86 are vastly different instruction sets. There is a huge performance hit in translating x86 instructions to a string of IA64 instuctions to perform the same task. Itanium used to do x86 emulation on the CPU itself, which didn't work very well. It is now primarily done in software in an approach not unlike WOW, but even still the ISA differences result in a severe performance hit. Boiled down to the simplest possible terms: The IA64 architecture uses a large number of execution units running at low clockspeed in parallel to achieve high performance, versus a small number of execution units running at high speed like x86. Thus Itanium must attempt to group x86 instructions together in such a way to allow it to keep as many execution units as busy as possible. This has proven to be very difficult. Thus when Itanium is running x86 code it is only actually making use of a small percentage of its execution units as opposed to Athlon 64 which is still fundamentally x86. Sorry if that is confusing, but I really don't have the time to explain this any more clearly than that...

Kev367th · « **Reply #7 on:** August 29, 2004, 10:02:38 PM »

Got it Bloom.
Would the last person to leave the RMS Itanic please turn off the lights lol.

Was reading about Intels jump into the 32/64 CPU market. Everything up to now says yup it works,,,but compared to AMD 64 they suck basically.

Ghosth · « **Reply #8 on:** August 30, 2004, 05:33:23 AM »

Thanks for the info guys.

Next question.

Will AMD 64's work with an older OS like 98SE?

Or would they be so crippled there's no point in trying?

Is there any other OS being designed for 64 bit processors????

Overlag · « **Reply #9 on:** August 30, 2004, 01:17:38 PM »

yes win98 is fine with a64s, although im not sure why you would want to run it on win98

Kev367th · « **Reply #10 on:** August 30, 2004, 03:21:12 PM »

There are already some versions of Linux available in 64 bit edtitions.
Get enough people, we may get a 64-bit Aces High v5.0 (in two weeks maybe).

Ghosth · « **Reply #11 on:** August 30, 2004, 06:07:41 PM »

Overlag, Call me a control freak when it comes to computers.

I hate computers telling me what I have to do, or doing things I don't know about.

With 98SE I know it inside & out, there is no reporting back to poppa, and everything works. Not to mention that 98SE does everything pretty much that XP does, with half the resources.

Edbert · « **Reply #12 on:** August 31, 2004, 01:02:45 PM »

Quote

Originally posted by Kev367th
Wrong Edbert, the Athlon 64 has a full 32 bit with 64 bit extensions instruction set. There is NO emulation involved.

Regardless of the CPU the OS itself will have to open a virtual 32 bit session to run the 32 bit software though. Just like the WOWEXEC.EXE is currently used to run a 16bit app in a 32 bit version if windows. Am I missing something here?

I wont argue that the 32 bit app will run well, most 16 bit apps run really well on our 32 bit procs too

bloom25 · « **Reply #13 on:** September 02, 2004, 12:30:55 AM »

AMD publicly demonstrated the first dual core x86 processor today. It was a quad dual core Socket 940 Opteron system, making it an 8-CPU system. This is quite a significant milestone for AMD, they are the first to do this with an x86 core. On top of that the CPUs were fabbed using their new 90nm SOI process.

Intel had better start to worry, AMD already holds the performance lead with Opteron. If they bring a dual core version to the market before Intel they may begin to make serious headway into the highly profitable server market.

It gets worse for Intel though, as the current Prescott derived Xeon cores are poorly suited to a dual core design - they simply run too hot and lack the real key factor that will allow a dual core Opteron to suceed. That is the on-die dual channel memory controller. The dual core Opteron design shares a single on-die dual channel memory controller between two cores. This keeps memory latency low and greatly decreases the cost of the motherboard chipset required to support the CPU. (In fact, it could even be compatible with existing Socket 940 motherboards.) The Prescott core lacks an on-die memory controller. I will bet that when Intel finally demonstrates dual core CPUs they will be based upon the Pentium M (Banias and Dothan) cores. These cores are simply improved versions of the Pentium 3. This core would be better suited to a dual core CPU, it is a more efficient design powerwise, but is simply not as advanced as the Opteron and currently lacks 64 bit capabilities. I also doubt it will incorporate an on-die memory controller, but not because Intel couldn't do it. Rather, Intel is the number 1 producer of chipsets for their CPUs. If they designed a CPU with an on-die memory controller it would impact their profits in that area...

save · « **Reply #14 on:** September 02, 2004, 06:14:21 AM »

"The new OS became known as MVS/XA. "

Now its MVS/ESA and Z/OS

z-os for small processors in clusters for linux applications . and hey they are aircooled now .... unlike top-end intel's
that are watercooled

~~save~~