kovacm
Čuven
- Učlanjen(a)
- 28.01.2005
- Poruke
- 8,607
- Poena
- 870
Delimire secam se da si u par navrata napominjao kako je Apple napravio glatku tranziciju sa 32bita na 64bita, potpuno transparentno za korisnike.
Ovo je malo objasnjenje kako je to izvedeno:
Control bits: Just as my earlier example of the "pseudo-32-bit" mode demonstrated how 32-bit microprocessors can deliver a backward compatible programming model, AMD64 could have offered the option to enable only the new 64-bit wide registers but to keep the existing 32-bit memory addressing model. This would have allowed Windows XP or Windows Vista to have easily kept most of their existing code base and application compatibility, while offering a new enhanced 64-bit mode for applications that chose to make use of 64-bit integer registers. It would have been a very easy transition.
In fact, Apple has made use of just such as trick in Mac OS X. Unlike the AMD - Intel war, in the early 1990's IBM, Apple, and Motorola got together to jointly define a specification for the new PowerPC microprocessor family. One of the beautiful things about PowerPC's design is that they thought years ahead. When I was a developer on Mac Office 98, I used a 1994 programmer's reference manual written jointly by IBM and Motorola which described the PowerPC register state and instruction set. Near the back of the manual is an entire chapter on 64-bit extensions to PowerPC. Even though 64-bit chips were years away, they had thought ahead and define what happens when you extend registers to 64-bit bits in width and allow 64 bits of address space. The end result is spec that, unlike x86, allows 32-bit PowerPC code to run almost unmodified, and sometimes completely unmodified, on 64-bit PowerPC microprocessors. One of the modes available, and the mode that I believe Mac OS X takes advantage of, is a programming model with 64-bit wide integer registers but a 32-bit address space. This allows Apple to ship one single version of Mac OS X for PowerMac G5 and to seamlessly multitask 32-bit and 64-bit Mac OS applications using the same kernel. I was actually amazed when I went to work on the Xbox 360 team a few years ago how almost identical the design and specification of the actual 64-bit Xbox 360 PowerPC was compared to the specification from over 10 years earlier.
AMD64 offered no such smooth upgrade to 64-bit mode, forcing Microsoft as well as Linux distributions to require completely separate kernels for 32-bit and 64-bit. The 32-bit Windows XP and the 64-bit Windows XP operating systems are actually quite radically different. Even Windows Vista has different feature sets on 32-bit and 64-bit, such as no longer supporting MS-DOS or 16-bit Windows applications in the 64-bit version of Windows.
LESSON LEARNED: AMD should have studied the PowerPC design to learn how to smoothly extend x86 to AMD64. Instead, it has given us an architecture that requires a radical rewrite of operating systems and applications. Backward binary compatibility, such as mix and matching 32-bit x86 code with new AMD64 code in the same process, is not possible.
link
Ovo je malo objasnjenje kako je to izvedeno:
Control bits: Just as my earlier example of the "pseudo-32-bit" mode demonstrated how 32-bit microprocessors can deliver a backward compatible programming model, AMD64 could have offered the option to enable only the new 64-bit wide registers but to keep the existing 32-bit memory addressing model. This would have allowed Windows XP or Windows Vista to have easily kept most of their existing code base and application compatibility, while offering a new enhanced 64-bit mode for applications that chose to make use of 64-bit integer registers. It would have been a very easy transition.
In fact, Apple has made use of just such as trick in Mac OS X. Unlike the AMD - Intel war, in the early 1990's IBM, Apple, and Motorola got together to jointly define a specification for the new PowerPC microprocessor family. One of the beautiful things about PowerPC's design is that they thought years ahead. When I was a developer on Mac Office 98, I used a 1994 programmer's reference manual written jointly by IBM and Motorola which described the PowerPC register state and instruction set. Near the back of the manual is an entire chapter on 64-bit extensions to PowerPC. Even though 64-bit chips were years away, they had thought ahead and define what happens when you extend registers to 64-bit bits in width and allow 64 bits of address space. The end result is spec that, unlike x86, allows 32-bit PowerPC code to run almost unmodified, and sometimes completely unmodified, on 64-bit PowerPC microprocessors. One of the modes available, and the mode that I believe Mac OS X takes advantage of, is a programming model with 64-bit wide integer registers but a 32-bit address space. This allows Apple to ship one single version of Mac OS X for PowerMac G5 and to seamlessly multitask 32-bit and 64-bit Mac OS applications using the same kernel. I was actually amazed when I went to work on the Xbox 360 team a few years ago how almost identical the design and specification of the actual 64-bit Xbox 360 PowerPC was compared to the specification from over 10 years earlier.
AMD64 offered no such smooth upgrade to 64-bit mode, forcing Microsoft as well as Linux distributions to require completely separate kernels for 32-bit and 64-bit. The 32-bit Windows XP and the 64-bit Windows XP operating systems are actually quite radically different. Even Windows Vista has different feature sets on 32-bit and 64-bit, such as no longer supporting MS-DOS or 16-bit Windows applications in the 64-bit version of Windows.
LESSON LEARNED: AMD should have studied the PowerPC design to learn how to smoothly extend x86 to AMD64. Instead, it has given us an architecture that requires a radical rewrite of operating systems and applications. Backward binary compatibility, such as mix and matching 32-bit x86 code with new AMD64 code in the same process, is not possible.
link
Poslednja izmena:
