An application running in a 32-bit Windows OS can change the mode bit, and run with 64-bit addressing.kuwan said:
At least one application that I know of does that - it runs 64-bit tasks from a 32-bit version of Windows.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Xserve July, Mac Pro (PowerMac) in August?
- Thread starter MacRumors
- Start date
- Sort by reaction score
At least one application that I know of does that - it runs 64-bit tasks from a 32-bit version of Windows.
AidenShaw said:Oh no, now the overused "pro" label is being used for chipsets as well....
Curse those "amateur" chipsets!
Thank you Aiden i was just about to jump all over this before i read your comment , it seems the Mac cool aid is becoming more potent every day , now people have to label all things related to the PowerMac/MacPro with "Pro". As for being amatuer : e-sata / 10x USB 2.0 ports / 2x Firewire / 2xPCIe 16 , 2x gigabit ethernet / 8ch HD audio/ 6x sata 3gb/s / DDR2 800 support. I don't think these are amateur features , no mac will ever see all this stuff , but my P965 mobo will. Apple will give you a cheap bare bones bargin bin Mobo as always. Will give you cheap DDR2 533(with bad latency) , a low end $90 250Gb HD with only 8MB cache. let's also not forget the infamous $80 video card Apple always includes with thier $2000+ "Pro" Desktops.
This is like the same crap people kept saying about the G5 being "server class" and Conroe being "Desktop Class" this is why i was calling people snobs , because this is pure "BS" . Steve has got too many mac users believing this crap , I will put my "amateur" DFI Lanparty UT NF4 Ultra-D Mobo against any thing apple can come up with and still end up with better "Pro" features. you guys that need 64 Gigs for ram are barking up the wrong tree , buy an Xserve.
AidenShaw said:
I don't think Apple cares about that segment of the market , Apple only cares about thier margins and if they came out with a $1499 PC it would probabally be crippled to death like the single socket G5's. They figure the iMac has this covered.
AidenShaw said:
Name the application, I doubt it does what you think it does. Running in 64-bit mode on x86-64 is much more than 64-bit addressing, there are additional registers that must be addressed by compiler and OS support and the registers are 64-bits wide instead of 32-bits. These features require OS and compiler support.
AidenShaw said:
It's only stealing if you rip DVDs you don't own. If you're ripping DVDs you bought, that's covered by fair use.
it5five said:
I assume you mean you don't see *why* apple would do a mini tower? There's no question about *how* they can do it since it certainly would be possible. If they don't, it's because they choose not to, not because they can't.
Apple could easily release a mini tower with iMac specs plus a couple slots for less than what an iMac costs. Of course, that would make the mini look expensive...
jiggie2g said:
I think apple wants to push people to more expensive models, but I also think they could easily make a decent tower for $1499 and still have the same or better margins than they do on any other model. I think they could even go cheaper than that.
jiggie2g said:
Although I agree this "Pro" stuff and shocked responses that Apple would dare consider Conroe for the PowerMac G5 replacement are silly and ignorant, the PowerMac G5s do have some "server class" features you won't find in retail Conroe motherboards.
The dual socket PowerMac G5s all have eight memory slots. The PCIe PowerMac G5s can take either ECC or non-ECC memory. You won't find dual sockets, eight memory slots or an ECC/non-ECC option on any retail Conroe motherboards. You can't have two sockets, period. I'm fairly certain the Intel MCH chips for Conroe aren't capable of having more than four memory slots work reliably. Although the chipsets can support ECC memory, I've never seen a motherboard manufacturer support the option.
For me, I couldn't care less if I lost those features. I think using an E6700 with four memory slots supporting up to DDR2-800 would make a great replacement PowerMac for almost everyone. I agree there would need to be a dual dual based on Woodcrest but I just can't see that being attractive for anyone but the most demanding video professionals and amateurs with too much money on their hands.
VMware Workstation/VMware Server.kuwan said:
Running on a 32-bit OS, it can run 64-bit virtual machines.
_____________________________
The point is only academic, however. Since a true 64-bit version of Windows exists, it's very easy to run 32-bit and 64-bit apps side by side. Just run Windows x64 Edition !
It's only if you you're stuck with a 32-bit operating system that the question of a having a crippled 64-bit application mode becomes interesting.
milo said:
Not if you live in the US and the DVDs use CSS. The DMCA has not been found to be unconstitutional, so bypassing the CSS is still against the law.
I've never heard the term "fair use" apply outside of the US but I'm sure Europe probably has some equivalent legal concept. I have no idea if bypassing CSS for DVDs you own is legal there or not.
it's not that bad, and it will get better
Most of the people who need 64-bit apps are buying new machines to run them, so getting supported drivers is no problem.
By the time Vista has been out for a year - you'll find the opposite problem. All the new stuff will have 64-bit drivers, and sometimes you'll have problems finding a 32-bit driver.
It's really only a problem if you build your own x64 PC or if you have a bunch of old cards that you want to put in a new x64 PC.ktlx said:
Most of the people who need 64-bit apps are buying new machines to run them, so getting supported drivers is no problem.
By the time Vista has been out for a year - you'll find the opposite problem. All the new stuff will have 64-bit drivers, and sometimes you'll have problems finding a 32-bit driver.
AidenShaw said:
Or if you have printers. Or if you have scanners. Or if you have lots of things. Have you even tried to build a home set up using Windows XP 64-bit with peripherals? I have. Once you get past chipset and video card drivers, you start running into lots of problems really fast. Not even all of the Tier 1 peripheral hardware players support Windows XP 64-bit yet for stuff you can buy in the stores today. Epson's about the only company I've seen who isn't a video card or chipset company who has broad support for the OS.
How much do you think the G4 tower in my Signature will be worth after the Mac Pro's are released? Keep in mind it comes with a 15" ADC moniter.
kuwan said:
AMD64 is not an "extension" of x86, it is more of a new CPU architecture cleverly designed to very easily support code for the x86 ISA. With AMD64, they basically cleaned up and fixed all the significant legacy problems of x86 while retaining all its advantages (and yes, x86 does have some advantages). The biggest improvements are the move to 16 general purpose 64-bit registers and a redesigned floating point implementation. PPC has little to offer over AMD64, and given the choice I actually prefer AMD64 to PPC as an architecture.
AidenShaw said:
This is nothing like you described previously. The 64-bit virtual machines that VMware creates run an entire 64-bit guest operating system. This is completely different from 32-bit Windows running 64-bit applications which cannot be done without emulation or virtualization. What this is is 64-bit Windows running 64-bit applications inside of a virtual environment.
AidenShaw said:
And as others have pointed out, 64-bit Windows suffers from a lack of 64-bit drivers. This will be the same situation that Mac users will face with a 64-bit version of Mac OS X.
Wouldn't it be nice if the operating system could remain 32-bit but still support 64-bit applications? Then there'd be no driver issues to worry about. Oh wait, we already have this with the PPC version of Tiger. It'd be nice if they could do the same thing with x86-64, but they can't. And since they can't it means that we'll have to go through yet another transition where everyone will need to wait for updated drivers for all of their peripherals. Plus they'll have to wait for new 64-bit versions of applications to come out (assuming developers want to take advantage of the speed improvements in x86-64).
tortoise said:
Extension, new architecture, who cares what vocabulary you use? IMO, given that its main purpose was to provide backwards compatibility with the IA-32 architecture then that sounds much more like an extension than something completely new.
A redesigned floating point implementation has nothing to do with the platform's architecture. Implementation is different from architecture.
What is it exactly that you prefer in AMD64 over PPC as an architecture? Is it AMD64's 16 general purpose registers to PPC's 32? Is it the inability of AMD64 to run 64-bit applications from a 32-bit operating system? Is it the inability of AMD64 to use 64-bit registers in a 32-bit application? Is it AMD64's 48-bit address space (2^48 bytes) to PPC's full 64-bit address space (2^64 bytes)? Is it AMD64's incomplete (and still incompletely evolving) SSE1/2/3 to PPC's AltiVec? I could keep going.
What is it exactly in AMD64's architecture that is so compelling? Or do you prefer an AMD64 implementation over the PPC implementation?
What this is is 32-bit Windows running a 64-bit application. The 64-bit application happens to be a virtual machine monitor, but it's a 64-bit task running on a 32-bit OS.kuwan said:
The CPU has to switch between 32-bit mode and 64-bit mode everytime it runs the VMM.
Note that Windows 36-bit addressing support (the 64 GiB RAM limit) internally uses larger memory addresses, so the VMM could use as much memory as it needs. This is helped by the fact that a VMM uses low-level OS APIs to allocate memory at the page level - the VMM doesn't "malloc" a few Gibis when it needs RAM for the VM.
Short term problem during the transition from 32-bit to 64-bit. With Vista, Microsoft aims to make the 64-bit version the logical one to run if you have 64-bit capable hardware.kuwan said:
Just as today you should put off a MacIntel purchase until your necessary apps are fat binary, you should (today) stick with 32-bit unless you have 64-bit drivers for your necessary hardware.
No, that's a limited kludge. A stepping stone to true 64-bit support - especially in the lame OSX implementation where most of the libraries and frameworks can't be used from a 64-bit app.kuwan said:
IMO, Apple should have waited for Core 2 and made OSX for Intel 64-bit only. Selling Yonah was a mistake that will hurt for years.
Core 2-only would have eliminated the driver issue. Since there would be no 32-bit OSx64 systems, if there's a driver - it's 64-bit.
One fewer transition for software developers - the Intel transition would also the true 64-bit transition.
The "mode bit" that controls 64-bit operation is a per-process attribute - whenever the scheduler gives a CPU to a thread the thread's mode bit setting is used.kuwan said:
Tiger's lame 64-bit implementation could easily be run on x64 processors - the VMware application proves that.
These problems will be real, but the cause isn't that an x64 processor can't switch modes on a per thread basis.kuwan said:
The problem was that someone in Cupertino was too impatient to wait a few more months for the x64 transition - and instead jumped on Yonah. In the long term, this will be seen as the biggest mistake of the Intel transition.
Interesting that you emphasize this, since some of your arguments ignore the distinction between implementation and architecture.kuwan said:
Not true, as I've shown with the VMware example. The CPU can easily swap between modes on the fly.kuwan said:
Microsoft chose to port their existing 64-bit Windows operating system to the x64 architecture and provide true 64-bit support. There was no need to go to additional effort and create a kludge that supported a small set of limited 64-bit apps from a 32-bit base.
If the tables were turned (that is, if Apple had true 64-bit and Windows supported 64-bit apps only at a DOS prompt) there'd be no end of comments about how stupid Microsoft is...
Not true, 32-bit apps can use 64-bit and 128-bit registers.kuwan said:
Of course, you meant "64-bit general purpose integer registers" - the 64-bit FP and 128-bit SSE registers are available to both 32-bit and 64-bit programs. (And note that SSE3 supports some long integer operations even in 32-bit mode.)
I won't mention the inability of AltiVec to do double-precision floating point....
Perhaps you should check your facts here - the PPC970 has 42-bit physical addressing, not 64-bit. (Implementation vs. architecture mistake.)kuwan said:
No Apple PPC970 has supported more than 34-bits (16 GiB), just like the "amateur" 975 chipset.
There is *no* point in having more physical address lines in an implementation than it will reasonably need during its lifetime. 42-bits is 4096 GiB of RAM, 48-bit is 262,144 GiB - more than enough headroom for the lifetime of these implementations.
Similarly, there's little point in supporting virtual addressing wider than is likely to be necessary - as long as the architecture requires full 64-bit address checking. This lets later implementations increase the VA width without any changes in applications.
AidenShaw said:
Not to get wildly off topic, but could someone please explain to me how it's possible for a 32-bit operating system to use addresses with such weird sizes (34, 36, 42, 48 bits)?? It was always my understanding that this was an impossibility, hence the need for 64-bit processors. If not, what's the need for 64 bit?
bytes within a page can often be ignored by the OS
The memory hardware in an x86 system divides memory into pages of 4096 bytes. This is the smallest unit of memory that can be allocated, assigned protections, etc. at the hardware and low-level system memory management.
Since 4096 bytes is 12-bits, that means that a 20-bit number can count all the pages in a 32-bit physical memory.
Much of the memory management and I/O code in the operating system refers to pages by their page number - therefore a 32-bit register can easily hold the page numbers needed to support more than 4 GiB of physical RAM.
That's how a 32-bit operating system like 32-bit Windows can support 64 GiB of total system RAM (which is 36-bit physical address).
An application, however, uses a 32-bit virtual address (since it needs to find the bytes inside one of the 4 KiB pages). A 32-bit application is capped at seeing 4 GiB of RAM at once.
If the operating system needs to see the bytes within the page - it either runs in the context of the process, or it puts the page number into a kind of pointer to make it temporarily accessible as a virtual address.
(This is simplified at bit, but basically correct.)
Applications need 64-bit virtual addressing more than the OS needs it.brianus said:
The memory hardware in an x86 system divides memory into pages of 4096 bytes. This is the smallest unit of memory that can be allocated, assigned protections, etc. at the hardware and low-level system memory management.
Since 4096 bytes is 12-bits, that means that a 20-bit number can count all the pages in a 32-bit physical memory.
Much of the memory management and I/O code in the operating system refers to pages by their page number - therefore a 32-bit register can easily hold the page numbers needed to support more than 4 GiB of physical RAM.
That's how a 32-bit operating system like 32-bit Windows can support 64 GiB of total system RAM (which is 36-bit physical address).
An application, however, uses a 32-bit virtual address (since it needs to find the bytes inside one of the 4 KiB pages). A 32-bit application is capped at seeing 4 GiB of RAM at once.
If the operating system needs to see the bytes within the page - it either runs in the context of the process, or it puts the page number into a kind of pointer to make it temporarily accessible as a virtual address.
(This is simplified at bit, but basically correct.)
ktlx said:
It hasn't been found unconstitutional yet. It hasn't gone to the supreme court so far, has it? If it ever does (which is probably unlikely, I can't imagine trying to press charges against a guy ripping DVD he owns), I think the supreme court would throw it out in a heartbeat.
If bypassing the CSS really is illegal, than how are commercial DVD ripping apps being sold in the USA?
Alright, I'll respond to your two posts and then that's it for me since I've grown tired of providing facts only to be countered with your vague, incorrect and unverifiable assertions. Unless you provide something substantive in response I'll be gone.
The 64-bit application here is the 64-bit guest operating system. I'll reiterate again, running the processor in 64-bit mode requires a 64-bit OS - the VMM or hypervisor puts the processor into 64-bit mode and then an operating system must manage the processor while in this mode. If you wanted to run other "applications" in this way then each application would have to do everything an operating system does - manage context switching, memory management, scheduling, etc. Each "application" would basically be a small operating system incurring extra overhead. This would be a huge kludge, so much so that it is impractical as each 64-bit "application" would be a mini operating system and dramatically increase overhead on the machine.
At any rate the 32-bit operating system is not running 64-bit applications, the 32-bit OS is running an application that virtualizes a 64-bit environment that then runs a 64-bit OS and subsequently 64-bit applications (whew, what a mouthful).
Reference Operating modes for more details.
For additional proof and reading, please take a look at AMD's AMD64 Architecture Programmers Manual Volume2: System Programming (PDF). Describing Long Mode (64-bit mode) in 2.1.1, page 29:
For information on how to put the processor into Long Mode read 14.6.1 Activating Long Mode, page 427:
Leaving Long Mode (found in 14.7, page 429) is a similarly long and complex process.
Note that this is nothing like the "mode bit" that you claim can be set on a per-process basis. The CPU can run in either 32-bit Legacy mode or 64-bit Long mode, it cannot run and/or use both modes at the same time. In order for VMware to work as it does it needs to be constantly switching the processor in and out of 64-bit mode - switch to 64-bit mode and let the 64-bit virtualized OS run, then switch back to 32-bit mode and let 32-bit Windows do what it needs to do (and back and forth). Also note that this is much more complex and resource intensive than a simple context switch from one thread/process to another.
Short term and yet today, over a year after 64-bit Windows was released, there is limited support for 64-bit drivers and Vista is still more than 6 months away (at best). All the while Tiger has been out for over a year featuring 64-bit support and not requiring any new drivers or any other painful transition for users.
You do now seem to concur with my original reason for bringing up 64-bit support - that in addition to the current PPC to Intel transition there will be yet another 32-bit to 64-bit transition for users to go through.
It's not a limited kludge, it's a great feature that takes advantage of one of the great design advantages of the PPC platform. I agree though that Apple has limited its usefulness by not providing 64-bit versions for most of the libraries on Mac OS X. Had they provided a complete set of 64-bit libraries then this would be "true 64-bit support" in every sense. There's no reason that the OS kernel needs to be 64-bit, it certainly doesn't need to access that much RAM itself, unless of course the processor needs a 64-bit OS in order to run 64-bit applications.
I agree with this 100%. It now means yet another transition for both developers and users. That would have meant waiting for Leopard in addition to Core 2. And since Leopard probably won't be coming until next year I guess Apple decided they couldn't let their laptop line stagnate for that long. We all get to pay the price for years to come.
There is no such "mode bit". As described above the processor can either run in 32-bit Legacy mode or it can run in 64-bit Long mode. If you want to mix modes as VMware does then you need to constantly switch the processor between Legacy mode and Long mode. Note that this is a serializing operation that requires the processor to completely flush whatever it is doing before it can make the mode switch - a time-consuming and performance-degrading operation. This is not a per-process attribute, the CPU can run in either one mode or the other.
Not without providing either 1) a separate 64-bit kernel to run 64-bit applications - in essence you'd have two operating systems running (32-bit Tiger and a separate 64-bit kernel for 64-bit apps) or 2) requiring each 64-bit application to be its own mini OS. Neither option is practical and requires too much overhead.
The bottom line is that with x86-64 you need a 64-bit operating system in order to run 64-bit applications. And this means yet another transition for developers and users.
AidenShaw said:
The 64-bit application here is the 64-bit guest operating system. I'll reiterate again, running the processor in 64-bit mode requires a 64-bit OS - the VMM or hypervisor puts the processor into 64-bit mode and then an operating system must manage the processor while in this mode. If you wanted to run other "applications" in this way then each application would have to do everything an operating system does - manage context switching, memory management, scheduling, etc. Each "application" would basically be a small operating system incurring extra overhead. This would be a huge kludge, so much so that it is impractical as each 64-bit "application" would be a mini operating system and dramatically increase overhead on the machine.
At any rate the 32-bit operating system is not running 64-bit applications, the 32-bit OS is running an application that virtualizes a 64-bit environment that then runs a 64-bit OS and subsequently 64-bit applications (whew, what a mouthful).
Reference Operating modes for more details.
For additional proof and reading, please take a look at AMD's AMD64 Architecture Programmers Manual Volume2: System Programming (PDF). Describing Long Mode (64-bit mode) in 2.1.1, page 29:
To use 64-bit mode, a 64-bit operating system and tool chain are required.
For information on how to put the processor into Long Mode read 14.6.1 Activating Long Mode, page 427:
Switching the processor to long mode requires several steps. In general, the sequence involves disabling paging (CR0.PG=0), enabling physical-address extensions (CR4.PAE=1), loading CR3, enabling long mode (EFER.LME=1), and finally enabling paging (CR0.PG=1).
Specifically, software must follow this sequence to activate long
mode:
Specifically, software must follow this sequence to activate long
mode:
1. If starting from page-enabled protected mode, disable paging by clearing CR0.PG to 0. This requires that the MOV CR0 instruction used to disable paging be located in an identity-mapped page (virtual address equals physical address).
2. In any order:
2. In any order:
- Enable physical-address extensions by setting CR4.PAE to 1. Long mode requires the use of physical-address extensions (PAE) in order to support physical-address sizes greater than 32 bits. Physical-address extensions must be enabled before enabling paging.
- Load CR3 with the physical base-address of the level-4 page-map-table (PML4). See Long-Mode Page Translation on page 160 for details on creating the 4- level page translation tables required by long mode.
- Enable long mode by setting EFER.LME to 1.
3. Enable paging by setting CR0.PG to 1. This causes the processor to set the EFER.LMA bit to 1. The instruction following the MOV CR0 that enables paging must be a branch, and both the MOV CR0 and the following branch instruction must be located in an identity-mapped page.- Load CR3 with the physical base-address of the level-4 page-map-table (PML4). See Long-Mode Page Translation on page 160 for details on creating the 4- level page translation tables required by long mode.
- Enable long mode by setting EFER.LME to 1.
Leaving Long Mode (found in 14.7, page 429) is a similarly long and complex process.
Note that this is nothing like the "mode bit" that you claim can be set on a per-process basis. The CPU can run in either 32-bit Legacy mode or 64-bit Long mode, it cannot run and/or use both modes at the same time. In order for VMware to work as it does it needs to be constantly switching the processor in and out of 64-bit mode - switch to 64-bit mode and let the 64-bit virtualized OS run, then switch back to 32-bit mode and let 32-bit Windows do what it needs to do (and back and forth). Also note that this is much more complex and resource intensive than a simple context switch from one thread/process to another.
AidenShaw said:
Short term and yet today, over a year after 64-bit Windows was released, there is limited support for 64-bit drivers and Vista is still more than 6 months away (at best). All the while Tiger has been out for over a year featuring 64-bit support and not requiring any new drivers or any other painful transition for users.
You do now seem to concur with my original reason for bringing up 64-bit support - that in addition to the current PPC to Intel transition there will be yet another 32-bit to 64-bit transition for users to go through.
AidenShaw said:
It's not a limited kludge, it's a great feature that takes advantage of one of the great design advantages of the PPC platform. I agree though that Apple has limited its usefulness by not providing 64-bit versions for most of the libraries on Mac OS X. Had they provided a complete set of 64-bit libraries then this would be "true 64-bit support" in every sense. There's no reason that the OS kernel needs to be 64-bit, it certainly doesn't need to access that much RAM itself, unless of course the processor needs a 64-bit OS in order to run 64-bit applications.
AidenShaw said:
I agree with this 100%. It now means yet another transition for both developers and users. That would have meant waiting for Leopard in addition to Core 2. And since Leopard probably won't be coming until next year I guess Apple decided they couldn't let their laptop line stagnate for that long. We all get to pay the price for years to come.
AidenShaw said:
There is no such "mode bit". As described above the processor can either run in 32-bit Legacy mode or it can run in 64-bit Long mode. If you want to mix modes as VMware does then you need to constantly switch the processor between Legacy mode and Long mode. Note that this is a serializing operation that requires the processor to completely flush whatever it is doing before it can make the mode switch - a time-consuming and performance-degrading operation. This is not a per-process attribute, the CPU can run in either one mode or the other.
AidenShaw said:
Not without providing either 1) a separate 64-bit kernel to run 64-bit applications - in essence you'd have two operating systems running (32-bit Tiger and a separate 64-bit kernel for 64-bit apps) or 2) requiring each 64-bit application to be its own mini OS. Neither option is practical and requires too much overhead.
The bottom line is that with x86-64 you need a 64-bit operating system in order to run 64-bit applications. And this means yet another transition for developers and users.
AidenShaw said:
See my post above for why your VMware example is faulty and does not work for any practical purposes (other than providing a virtual environment for a 64-bit operating system). Switching between modes is a serializing operation and wouldn't be at all practical for normal use. And it still doesn't change the fact that while in 64-bit mode the processor must be managed by a 64-bit OS.
AidenShaw said:
Good that you edited your original post to correct yourself.
What I was talking about is the ability of a 32-bit PPC application to use 64-bit general purpose registers. This can be done by using the -mpowerpc64 flag in GCC (or the "Use 64-bit Integer Math" setting in Xcode). This allows math-intensive 32-bit applications that do not require a 64-bit address space to benefit from using native 64-bit integers. You cannot do this on x86-64. In order to use 64-bit general purpose registers you must be a 64-bit application running in 64-bit mode.AidenShaw said:
You just did, but that's hardly a great advantage of SSE2. Since the G5 has two double-precision floating point units capable of performing 2 double-precision floating point operations (FLOPs) per cycle then what's the point of having double-precision SIMD support? Given the choice of 2 FLOPs per cycle in scalar or 2 FLOPs per cycle in SIMD I think the scalar route is much more useful as it doesn't require you to mess with the difficulties of SIMD programming.
Plus, given the fact that the double-precision SSE implementations can only complete 1 SSE operation ever other cycle (1 operation every 2 cycles) then that gives you an effective throughput of only 1 double-precision FLOP per cycle. In this case the G5 clearly wins. Altivec, in addition to supporting many more integer operations than SSE1/2/3/4, has a throughput of one instruction per cycle - double that of current SSE implementations (Search for "vector throughput of one instruction per two cycles on vector execution units." on the linked page).
Oops, now I'm getting into implementation details. So while from an architecture standpoint I suppose it is nice that SSE has had double-precision support it has been handicapped by poor implementations. Luckily Core 2 features a much improved vector engine finally capable of delivering one instruction per cycle throughput. I'd still prefer having 2 double-precision floating point units over double-precision SIMD support.
AidenShaw said:
I was talking about virtual address space, not physical. Though I will admit to being mistaken about the AMD64's virtual address space, it is 64-bits as defined by the architecture so never mind on this one. Current implementations, however, have a 48-bit virtual address space and a 40-bit (1 terabyte) physical address space.
The PPC970 on the other hand actually supports a 65-bit (yes, 65-bit) virtual address space and a 42-bit physical address space (4 terabytes). See the PPC 970FX User Manual (PDF) section 5.1, page 134 for details.
But those are implementation details.
My point still stands, the PPC64 architecture is a much cleaner and better designed architecture than AMD64/x86-64/EM64T (whatever you want to call it). Just think of the poor Intel engineers that wanted to throw legacy x86 away and design the IA-64 (Itanium) architecture (not that I think IA-64 is a particularly good architecture, I don't much like it). It'd be nice if we could throw away all the legacy garbage and baggage that is x86, but its massive installed base and required backwards compatibility has (probably above anything else) ensured the success of AMD64 and that x86 will be with us for many, many years to come.
kuwan said:
Or, one could read your docs and take them to mean that the EFER.LME is the mode bit.
I never said that the "mode bit" was automatic - the process mode bit is a marker for the scheduler to "do the right thing". It takes a few instructions for the scheduler to "honor" the process mode bit.
And it's something that Windows x64 does constantly as you run a mix of 32-bit applications, 64-bit application, and the 64-bit OS. No one has noticed any performance problems due to the "complex and resource intensive" switch.kuwan said:
My main point, however, is that it *is* possible for a 32-bit operating system to run 64-bit tasks. VMware is the proof of this - even though the context/mode switching is done by the 32-bit VMware application, not the 32-bit O/S scheduler. The corollary to that point is that Microsoft already had a 64-bit version of Windows, no there was no need for a hybrid 32/64 bit effort - although it would have been possible, it was unnecessary.
But I didn't correct myself, I corrected your vague statement - it was wrong as posted.kuwan said:Good that you edited your original post to correct yourself.