64 Bit Leopard

[Leauki]

Did anybody ever announce anything about what will happen with Parallels when Leopard is released with 64 Bit support?

Will Parallels run in long mode and run 64 bit guests? Or will it emulate real mode and 16 bit protected mode to run 32 bit operating systems (which require real mode to boot)?

Were there any announcements or guesses?

 

[darkone]

i suspect you wont hear anything until after Leopard has hit the shelves, but i wouldnt expect to see support for 64bit guest os's in parallels.

 

[Eru Ithildur]

i suspect you wont hear anything until after Leopard has hit the shelves, but i wouldnt expect to see support for 64bit guest os's in parallels.

At least not for a while...

 

[Leauki]

At least not for a while...

Yes, but will it work at all?

If Leopard runs on the CPU in long mode, real mode code won't work any more and Parallels would have to emulate it.


I understand the x64 CPUs (including Core 2) run in one of three modes:

1. Real Mode

16 bit code, 20 bit memory addresses, the mode the CPU starts up in, MS-DOS

2. Protected Mode

16 and 32 bit code, 24 or 32 bit memory addresses, 16 and 32 bit OS/2, 32 bit Windows

3. Long Mode

32 and 64 bit code, 16 bit protected mode but not real mode code (not supported by any OS anyway), 64 bit Windows, Leopard with 64 bit support (?), switch into long mode from protected mode


Parallels guests from MS-DOS to 32 bit Windows (or Linux or OS/2 or Solaris) require real mode support (to run or to boot). I believe Virtual PC emulated real mode on 64 bit Windows.

 

[gnujon]

Are you sure that 32bit versions of Windows and Linux require Real Mode? Do you mean just for booting or something? Not that I would know, but I was under the impression that modern versions of Windows were Protected Mode all the way. Windows 95 and 98 did boot DOS first and then switch to Protected Mode. And Virtual Real Mode was used to keep running the initial DOS environment so as to make use of any DOS drivers that were loaded. But I thought all that went away once we got to Windows 2000/XP running the NT kernel.

Also, seeing as one can already compile and run 64bit POSIX applications on Mac OS X machines with x64 CPUs, doesn't that mean that the CPUs must already be running in long mode with the current versions of Mac OS X used on these machines?

 

[Leauki]

Are you sure that 32bit versions of Windows and Linux require Real Mode? Do you mean just for booting or something?

Yes, as I said, to run or to boot, depending on the OS.

Not that I would know, but I was under the impression that modern versions of Windows were Protected Mode all the way. Windows 95 and 98 did boot DOS first and then switch to Protected Mode. And Virtual Real Mode was used to keep running the initial DOS environment so as to make use of any DOS drivers that were loaded. But I thought all that went away once we got to Windows 2000/XP running the NT kernel.

All 32 bit Windows versions use a Real Mode boot loader. And Long Mode also doesn't support V86 which Windows NT and OS/2 use to run 16 bit programs.

(Not sure what "virtual Real Mode" is. As far as I know Windows 95 was a type of DPMI client and switched back to Real Mode for running DOS programs.)

If Parallels solve the boot loader problem, I would be curious to learn what would happen if the user attempted to start a 16 bit program with Windows switching into a CPU mode (V86) that the Long Mode CPU Parallels uses doesn't offer.

Also, seeing as one can already compile and run 64bit POSIX applications on Mac OS X machines with x64 CPUs, doesn't that mean that the CPUs must already be running in Long Mode with the current versions of Mac OS X used on these machines?

Can one? Apple's 64 bit info speaks of PowerPC G5 boxen:

http://www.apple.com/macosx/features/64bit/

My G5 certainly can run 64 bit (Darwin) programs. But my Intel? I don't think so. The CPU seems to be in Protected Mode, which is why MS-DOS and OS/2's DOS box can run on it. (Although I am sure the Firmware switches the Core 2 into Protected Mode before the boot loader is even called.)

Long Mode would not allow 16 bit code to run, although I have found conflicting documentation on 16 bit Protected Mode code. Not that I know a lot about that. But it seems like Long Mode supports no Real Mode code (because it offers no V86 mode) but does support 16 bit Protected Mode code while the operating systems that run in Long Mode do not support 16 bit Protected Mode code. In effect Long Mode runs only 64 and 32 bit code and no 16 bit code at all.

I do believe you are right, however, that IF Mac OS X can run 64 bit code it must be running in Long Mode. But I don't think it can. And if it could, I wonder why Windows needs the complicated WoW64 environment to run 32 bit code while Mac OS X does it so naturally.

Apple claim that Leopard will be a 64 bit OS on Intel. My assumption is that Leopard will be 64 bit only on Intel, while the PowerPC version will use the 32 bit kernel (and why not). Thus there will be three kernels:

1. 32 bit PowerPC kernel (which can run 64 bit programs on a G5): G4 and G5 machines.

2. 32 bit Intel kernel (which cannot run 64 bit programs): early 32 bit-only Intel machines.

3. 64 bit Intel kernel (which can run 64 bit and 32 bit programs): all other Intel machines.

I am sure clever hackers will find a way to activate the 32 bit kernel on all Intel machines (for fun).

 

[gnujon]

Yes, as I said, to run or to boot, depending on the OS.

All 32 bit Windows versions use a Real Mode boot loader. And Long Mode also doesn't support V86 which Windows NT and OS/2 use to run 16 bit programs.

(Not sure what "virtual Real Mode" is. As far as I know Windows 95 was a type of DPMI client and switched back to Real Mode for running DOS programs.)

'Virtual Real Mode' is just another name for 'V86', 'VM86', or 'Virtual 8086' mode. Just a lot of different names for the same thing.

As I thought I understood it, Windows 3.11, Windows 9x, and OS/2 all used VM86 to run 16 bit programs (the 'DOS boxes'). But I didn't think that Windows NT/2000/XP made use of this, or that they still used Real Mode boot loaders either. I'm not saying I know what I'm talking about, I'm just surprised, I thought Real Mode was a thing of the past.

Can one? Apple's 64 bit info speaks of PowerPC G5 boxen:

http://www.apple.com/macosx/features/64bit/

My G5 certainly can run 64 bit (Darwin) programs. But my Intel? I don't think so. The CPU seems to be in Protected Mode, which is why MS-DOS and OS/2's DOS box can run on it. (Although I am sure the Firmware switches the Core 2 into Protected Mode before the boot loader is even called.)

I was told that it is currently possible to run 64 bit command line binaries on Mac OS X Intel machines that have EM64T CPUs. So I assumed that the CPUs must always be in long mode on these machines. I will have a closer look at my Mac Pro and get back to you. ;-)

Long Mode would not allow 16 bit code to run, although I have found conflicting documentation on 16 bit Protected Mode code. Not that I know a lot about that. But it seems like Long Mode supports no Real Mode code (because it offers no V86 mode) but does support 16 bit Protected Mode code while the operating systems that run in Long Mode do not support 16 bit Protected Mode code. In effect Long Mode runs only 64 and 32 bit code and no 16 bit code at all.

Is it possible that the Intel VT allows Real Mode in VMs somehow? Even if the CPU is in long mode?

I do believe you are right, however, that IF Mac OS X can run 64 bit code it must be running in Long Mode. But I don't think it can. And if it could, I wonder why Windows needs the complicated WoW64 environment to run 32 bit code while Mac OS X does it so naturally.

Actually that's a very good question. Does anyone know the answer to this? Or am I totally wrong about Mac OS X already being able to run x64 binaries?

Apple claim that Leopard will be a 64 bit OS on Intel. My assumption is that Leopard will be 64 bit only on Intel, while the PowerPC version will use the 32 bit kernel (and why not). Thus there will be three kernels:

1. 32 bit PowerPC kernel (which can run 64 bit programs on a G5): G4 and G5 machines.

2. 32 bit Intel kernel (which cannot run 64 bit programs): early 32 bit-only Intel machines.

3. 64 bit Intel kernel (which can run 64 bit and 32 bit programs): all other Intel machines.

I am sure clever hackers will find a way to activate the 32 bit kernel on all Intel machines (for fun).

I guess I've been assuming that there already are these three different kernels for the current version of the OS.

 

[gnujon]

My 64 bit binary seems to run

Hi,

I'm back in front of my Mac Pro, so I thought I'd try a little experiment. Here is my source code (testapp.c):

#include <stdio.h>
int main()
{
printf("Steve Balmer belongs in a zoo.\n");
return 0;
}

Here is me trying to compile it into a 64 bit binary:

Jons-MacPro:~/Source jonmc$ gcc -arch x86_64 ./testapp.c
Jons-MacPro:~/Source jonmc$ mv a.out testapp

Here is me checking to see what kind of binary I have built:

Jons-MacPro:~/Source jonmc$ file testapp
testapp: Mach-O 64-bit executable x86_64

And here is the binary running:

Jons-MacPro:~/Source jonmc$ ./testapp
Steve Balmer belongs in a zoo.
Jons-MacPro:~/Source jonmc$

That seems to show that my Intel Mac can run 64 bit binaries. Right?

 

[wesley]

Tiger has support for 64-bit command-line binaries for Intel CPUs as well? That's nice to know. At least we have a parity with G5 as far as 64-bit support in OS X goes.

 

[Leauki]

That seems to show that my Intel Mac can run 64 bit binaries. Right?

Yes.

Weirdness.

man gcc gives me:

-arch arch
           Compile for the specified target architecture arch.  The allowable
           values are i386, ppc and ppc64.  Multiple options work, and direct
           the compiler to produce ``universal'' binaries including object
           code for each architecture specified with -arch.  This option only
           works if assembler and libraries are available for each architec-
           ture specified.  (APPLE ONLY)

I guess I should have tried it but the above suggested to me that gcc would not produce x64 binaries, probably, I thought, because they would not run anyway.

I repeated our experiment on my iMac and the program ran and checked out as a 64 bit binary.

I also compiled it for PowerPC:

hokem:~ ajbrehm$ testapp
Steve Balmer belongs in a zoo.
hokem:~ ajbrehm$ file testapp
testapp: Mach-O 64-bit executable ppc64

Just for completeness' sake I also compiled it for 32 bit PowerPC and Intel. As expected both PowerPC binaries ran on the G5, while both Intel binaries ran on the Intel. The 32 bit PowerPC binary also ran on the Intel (Rosetta), while the 64 bit PowerPC binary did not. That's exactly as should.

This means that we are running in long mode, although our kernel is 32 bit:

xerxes:/ ajbrehm$ file mach_kernel 
mach_kernel: Mach-O universal binary with 2 architectures
mach_kernel (for architecture ppc):     Mach-O executable ppc
mach_kernel (for architecture i386):    Mach-O executable i386

hokem:/ ajbrehm$ file mach_kernel 
mach_kernel: Mach-O executable ppc

In that case it is probably safe to assume that Parallels already emulated real mode and all 16 bit code where necessary.

UNLESS Parallels runs in protected mode somehow while Mac OS runs in long mode, but I have obviously no idea how this works. And what about Parallels on Windows and Linux? Both hosts run in protected mode I am sure.

Seems like Parallels Desktop is a bit more advanced than I thought.

Or what am I missing here?

(This would mean that 16 bit programs running under Parallels would be faster on Parallels Workstation running on Windows, wouldn't it? Can anybody confirm the assumption?)

 

[Leauki]

Note that there are only two kernels:

One PowerPC binary (32 bit) and one universal binary (PowerPC 32 bit and Intel 32 bit). The PowerPC kernel naturally supports 64 bit mode on a G5, and the Intel kernel appears to run adapt to x86 or x64 as required.

The universal binary kernel is about twice the size of the PowerPC kernel, which suggests that the Intel kernel itself is about the same size as the PowerPC kernel (why not?).

Now I am wondering:

Are we in Long Mode running a 32 bit kernel that is identical to the kernel running in Protected Mode on x86 (non-x64) Macs?

Or are we in Protected Mode and 64 bit programs are somehow run anyway (how?)?

The Apple Web site is pretty quiet about how this works. Perhaps there are comments in the Darwin source that explain it (so that I can understand)?

 

[Leauki]

http://lists.apple.com/archives/darwin-kernel/2007/Feb/msg00175.html

 

[Leauki]

Not that I know anything about kernel programming or C, but I am still curious:

xerxes:~/Desktop/xnu-792.18.15 ajbrehm$ grep -R "long mode" *
bsd/nfs/nfs_vnops.c:    u_long mode, wmode;
iokit/IOKit/IOHibernatePrivate.h:    unsigned long mode;                // 
osfmk/i386/asm64.h: * Here in long mode but still running below 4G.
osfmk/i386/idt64.s:     ENTER_64BIT_MODE()              /* Enter long mode */
osfmk/mach/i386/thread_status.h: * thread state format for task running in 64bit long mode
osfmk/mach/i386/thread_status.h: * in long mode, the same hardware frame is always pushed regardless
xerxes:~/Desktop/xnu-792.18.15 ajbrehm$

I downloaded the source for the kernel. It's a 32 bit kernel all right, but is it running in Long Mode or Protected Mode. Or does it switch to Long Mode for the odd 64 bit program or hoes does it work?

Windows 3.1 to ME switched to protected mode for 32 bit programs. Perhaps Mac OS X does a similar trick for 64 bit programs?

 

[Leauki]

Last one, I think...

This header file (asm64.h) seems to suggest that we are running in Long Mode. It mentions switching to and from 32 bit compatibility mode, which in AMD64 is a feature of Long Mode.

/* Helper macros for 64-bit mode switching */

/*
 * Long jump to 64-bit space from 32-bit compatibility mode.
 */
#define	ENTER_64BIT_MODE()			\
	.code32					;\
	.byte   0xea	/* far jump longmode */	;\
	.long   1f				;\
	.word   KERNEL64_CS			;\
        .code64					;\
1:

/*
 * Here in long mode but still running below 4G.
 * "Near" jump into uber-space.
 */
#define	ENTER_UBERSPACE()			\
        mov     2f,%rax				;\
        jmp     *%rax				;\
2:      .long   3f				;\
        .long   KERNEL_UBER_BASE_HI32		;\
3:     

/*
 * Long jump to 32-bit compatibility mode from 64-bit space.
 */
#define ENTER_COMPAT_MODE()			\
	ljmp	*4f				;\
4:	.long	5f				;\
	.word	KERNEL_CS			;\
	.code32					;\
5:

My guess is now that XNU (the Mac OS X kernel) runs in Protected Mode on 32 bit CPUs and in Compatibility Mode (within Long Mode) on 64 bit CPUs. For 64 bit binaries the kernel then switches from Compatibility Mode to Long Mode. I would also assume that Mac OS X never switches to Real Mode or V86 mode (like OS/2 with prot_only=yes set in config.sys). Hence Parallels probably emulates all Real Mode and 16 bit features anyway.

The missing 64 bit support for other frameworks (i.e. Carbon and Cocoa) is probably due to them not being implemented and has nothing to do with the OS itself, which supports 64 bit binaries all right. Claiming that only command-line programs can be 64 bit seems misleading as I think that a) a 64 bit binary can use X11 graphics and b) a Cocoa command-line binary can probably not be 64 bit as the Cocoa framework does not support it.

Hence Tiger supports Darwin 32 and 64 bit, Carbon 32 bit, and Cocoa 32 bit; and Leopard will support Darwin 32 and 64 bit, Carbon 32 and 64 bit, and Cocoa 32 and 64 bit. And that's the whole difference. Both systems run in Long Mode on 64 bit CPUs and Protected Mode (prot_only) on 32 bit CPUs. Both systems can run 32 bit PowerPC binaries via Rosetta, but not 64 bit PowerPC binaries.

Any comments?

 

[Leauki]

Another experiment...

I created seven versions of the Steve Balmer program. I modified the program to do a scanf at the end, so that it would stay in memory.

The seven versions:

ppc
ppc64
universal binary with ppc and ppc64

i386
x86_64
universal binary with i386 and x86_64

universal binary with ppc, ppc64, i386, and x86_64

The point was to find out which version the Mac would run.

It turns out the Intel iMac, if confronted with a universal binary containing both 32 and 64 bit Intel code will run the 64 bit code. This suggests again that we are running in Long Mode and Mac OS X finds the 64 bit version of the code "more native".

Other "discoveries":

- Starting the third binary on my G5 runs the 64 bit code. I expected that.

- Starting the third binary on the Intel runs the 32 bit PowerPC code. I knew that.

- The PowerPC binary running in Rosetta uses considerably more memory than the Intel binary (3.5 MB vs. 800 KB).

- The 64 bit versions are slightly larger than the 32 bit versions (800 KB vs. 700 KB approx.).

- Rosetta cannot run 64 bit PowerPC code. I knew that.

- Intel and PowerPC binary code is about the same size (~100 KB difference for this binary).

- The 32 bit PowerPC binary created by Xcode ran in Rosetta but not in my G5 iMac (bus error). I had to create a 32 bit PowerPC binary manually (gcc -arch ppc main.c) to get a working binary. I have no idea why that happened.


Still interested? I think not.

 

[akac]

Tiger has support for 64-bit command-line binaries for Intel CPUs as well? That's nice to know. At least we have a parity with G5 as far as 64-bit support in OS X goes.

Yes, it can. That's why I can run x64 binaries of MySQL I compile for OS X on my Quad Xeon XServe.

 

[gnujon]

My guess is now that XNU (the Mac OS X kernel) runs in Protected Mode on 32 bit CPUs and in Compatibility Mode (within Long Mode) on 64 bit CPUs. For 64 bit binaries the kernel then switches from Compatibility Mode to Long Mode. I would also assume that Mac OS X never switches to Real Mode or V86 mode (like OS/2 with prot_only=yes set in config.sys).

Yes, I think you're right. From what I understand (my understanding is very limited of course), Long Mode has two sub modes, Compatibility Mode and '64-bit Mode'. Compatibility Mode for 32-bit and 16-bit Protected Mode code, and '64-bit Mode' for the native 64-bit code. As you say, Compatibility Mode is 'within' Long Mode.

Hence Parallels probably emulates all Real Mode and 16 bit features anyway.

It would be interesting to hear from Parallels on this. If you are correct, would it mean that enabling VT-x for a DOS VM on an EM64T Mac will essentially do nothing?

Claiming that only command-line programs can be 64 bit seems misleading as I think that a) a 64 bit binary can use X11 graphics and b) a Cocoa command-line binary can probably not be 64 bit as the Cocoa framework does not support it.

Yes, that's why I initially used the term 'POSIX applications'. Although for 64-bit X11 apps, you would need 64-bit X11 libraries for them to link to, right?

 

[Leauki]

Yes, I think you're right. From what I understand (my understanding is very limited of course), Long Mode has two sub modes, Compatibility Mode and '64-bit Mode'. Compatibility Mode for 32-bit and 16-bit Protected Mode code, and '64-bit Mode' for the native 64-bit code. As you say, Compatibility Mode is 'within' Long Mode.

Exactly, I think.

It would be interesting to hear from Parallels on this. If you are correct, would it mean that enabling VT-x for a DOS VM on an EM64T Mac will essentially do nothing?

Since DOS can switch to Protected Mode (and will, think dos4gw and Windows 95) VT-x does do something, but it wouldn't have an effect on Real Mode code, supposedly.

Yes, that's why I initially used the term 'POSIX applications'. Although for 64-bit X11 apps, you would need 64-bit X11 libraries for them to link to, right?

That's right. But during my research I found 64-bit X11 libraries for Darwin, although for PowerPC.