64 bits cpus

[Evert]

And I _know_ that you can _not_ run 64 bit applications unless the kernel is _actually_ 64 bits aware. Regardless of whatever nonsense Apple or you are referencing.

It's not my definition.
Any particular reason you're debating the point so aggressively?

If the kernel works on 64 bit hardware, and _uses_ the 64 bit hardware, it is, by definition, a 64 bit kernel.

Well. As I said, that's to an extend really arguing semantics. Not saying I disagree per se (as I said before, the only thing I can think of is that key parts of the kernel run in 64 bit, while the main part of the kernel runs in 32 bit).

Fine, but what does that have to do with the original question "Can you run a 64 bit application on a 32 bit operating system?" The answer was, and still is, "no". Being able to run both is really nonsensical. Who in their right mind would take a good 64 bit machine and cripple it with a 32 bit operating system? You lose 8 registers. You lose the ability to use more than 4 gigs of ram. Etc. But if you insist, you can run either a 32 or 64 bit linux system, or a 32 or 64 bit windows system, and dual-boot either so that you run what you want, for whatever reason you want.

This is not unique to Apple.

How does that even relate to anything I said? I agree, it's silly to get a 64 bit system and not use it to its full potential - even more so since 32 bit programs can run perfectly fine under a 64 bit OS.

So again, my only point against what you say is the statement that Apple's OS boots into what Apple call a 32 bit kernel, yet it runs 64 bit applications. And again, it would seem to me that this means that on some level, the system is 64 bit, even if the main part of the kernel is 32 bit (if it's not, why call it 32 bit?).
I don't think that's different from what you're saying, so why do you think we disagree?

It is simply a false statement. Any person with any operating system development experience will echo what I stated exactly. The definition of a 64 bit operating system is simple. If you put the CPU in 64 bit mode, you _must_ be a 64 bit O/S or else it will instantly crash when that mode switch is done. Why Apple is making those kinds of statements is beyond me. And wrong to boot.

Ok, well, that could be. But as I said, I think this is, in part, a semantic discussion. And again, yes, I do know how computers work.
To clarify, I don't think Apple state one way or the other what they're doing, and I think they market their OS as able to use 64 bit. But, the OS, by default, loads something that's called or described elsewhere as a "32 bit kernel" (for instance, http://news.zdnet.com/2100-9595_22-336194.html, one of the first google hits). Maybe people are incorrectly using the term "kernel", I don't know.
Either way, that's the source for the statement that you can run 64 bit applications on OS X (which I know for a fact), while the system reportedly boots a "32 bit kernel" (which isn't something I made up, and in fact contrary to what I would deduce from being able to run 64 bit applications in the first place).

[schlucke]

tiger is 32 bits right?

then
http://developer.apple.com/macosx/64bit.html

Not according to the link you gave. A 32 bit O/S can only address 4 gigabytes of memory. To go farther, you step into the 64 bit world.

Sometimes a picture says more then thousand words

Road to Mac OS X Snow Leopard: 64-bit to the Kernel
http://www.appleinsider.com/articles/08 ... ernel.html

[bob]

tiger is 32 bits right?

then
http://developer.apple.com/macosx/64bit.html

Not according to the link you gave. A 32 bit O/S can only address 4 gigabytes of memory. To go farther, you step into the 64 bit world.

Sometimes a picture says more then thousand words

Road to Mac OS X Snow Leopard: 64-bit to the Kernel
http://www.appleinsider.com/articles/08 ... ernel.html

Thanks. You'd think that would end the discussion. Particularly the blue box "64 bit unix" that is in all three diagrams.

[schlucke]

The will speed up the discussion, but it explains that Snow Leopard "can" have a 64 bit kernel

More interesting is the right part with the 64bit Kernel on a 32bit CPU

I think the 64bit Unix refers to the 64 bit system calls. How long do we have 64bit filesystem calls in 32bit Unixes. 10 years?

[bob]

And I _know_ that you can _not_ run 64 bit applications unless the kernel is _actually_ 64 bits aware. Regardless of whatever nonsense Apple or you are referencing.

It's not my definition.
Any particular reason you're debating the point so aggressively?

Because this is the way the term is defined in operating system terminology. Without a _standard_ terminology, how can anyone communicate? One says "I bought a dozen eggs". The next says "I quacked a block box". And we discover, after days, that "quacked -> bought, etc...

I've only worked on operating systems for 40 years now. It is what I have always done and still do. I have written them, modified them, and supported them.

If the kernel works on 64 bit hardware, and _uses_ the 64 bit hardware, it is, by definition, a 64 bit kernel.

Well. As I said, that's to an extend really arguing semantics. Not saying I disagree per se (as I said before, the only thing I can think of is that key parts of the kernel run in 64 bit, while the main part of the kernel runs in 32 bit).

That's the part of semantics that I don't want to argue. If an OS has 64 and 32 bit components, it is _still_ a 64 bit OS. If it has no 64 bit components, then it is not a 64 bit OS and can not run 64 bit applications nor use any of the extensions that 64 bits brings to the table (larger memory address space, extra registers, etc.)

Fine, but what does that have to do with the original question "Can you run a 64 bit application on a 32 bit operating system?" The answer was, and still is, "no". Being able to run both is really nonsensical. Who in their right mind would take a good 64 bit machine and cripple it with a 32 bit operating system? You lose 8 registers. You lose the ability to use more than 4 gigs of ram. Etc. But if you insist, you can run either a 32 or 64 bit linux system, or a 32 or 64 bit windows system, and dual-boot either so that you run what you want, for whatever reason you want.

This is not unique to Apple.

How does that even relate to anything I said? I agree, it's silly to get a 64 bit system and not use it to its full potential - even more so since 32 bit programs can run perfectly fine under a 64 bit OS.

So again, my only point against what you say is the statement that Apple's OS boots into what Apple call a 32 bit kernel, yet it runs 64 bit applications. And again, it would seem to me that this means that on some level, the system is 64 bit, even if the main part of the kernel is 32 bit (if it's not, why call it 32 bit?).
I don't think that's different from what you're saying, so why do you think we disagree?

I would think that if you agree with me on the 64 bit question, then "our" disagreement is really with Apple and their brain-dead terminology of a 32 bit operating system that uses 64 bit hardware and can run 64 bit apps. That is not possible. And if they are saying it is, then they need some help.

It is simply a false statement. Any person with any operating system development experience will echo what I stated exactly. The definition of a 64 bit operating system is simple. If you put the CPU in 64 bit mode, you _must_ be a 64 bit O/S or else it will instantly crash when that mode switch is done. Why Apple is making those kinds of statements is beyond me. And wrong to boot.

Ok, well, that could be. But as I said, I think this is, in part, a semantic discussion. And again, yes, I do know how computers work.
To clarify, I don't think Apple state one way or the other what they're doing, and I think they market their OS as able to use 64 bit. But, the OS, by default, loads something that's called or described elsewhere as a "32 bit kernel" (for instance, http://news.zdnet.com/2100-9595_22-336194.html, one of the first google hits). Maybe people are incorrectly using the term "kernel", I don't know.

I don't believe so. If you boot a 32 bit kernel, you are strapped into a 32 bit box and can not use the 64 bit memory management, extra registers, etc. The kernel is what makes that work. And their blurbs clearly differentiate between 32 bit kernel and 64 bit kernel and in the Tiger case mentioned, they do clearly state that you can boot either. But if you boot the 32 bit kernel, you aren't going to run any 64 bit apps, while if you boot the 64 bit kernel, you can run 32 bit apps easily.

Either way, that's the source for the statement that you can run 64 bit applications on OS X (which I know for a fact), while the system reportedly boots a "32 bit kernel" (which isn't something I made up, and in fact contrary to what I would deduce from being able to run 64 bit applications in the first place).

I can not find where they state that anywhere. They do say that you have the choice of booting a 64 bit kernel, or a 32 bit kernel, from the same OS installation. But nothing suggests that if you boot the 32 bit kernel, you can run 64 bit apps. At least that I can find. I don't think they would want to take the "heat" for such a nonsensical claim...

[bob]

The will speed up the discussion, but it explains that Snow Leopard "can" have a 64 bit kernel

More interesting is the right part with the 64bit Kernel on a 32bit CPU

I think the 64bit Unix refers to the 64 bit system calls. How long do we have 64bit filesystem calls in 32bit Unixes. 10 years?

I'd agree there, but the size of the file system is really not a 64 bit issue, since on a 32 bit machine, you have 32 bit integers and nothing bigger unless you do it in software as gcc did with "long long". You could do an "any-number-of-bits" filesystem assuming you have disks large enough, while still running on even a 16 bit operating system.

I've primarily been focused on the issue of the underlying architecture that the OS has to run on, most critically the page table implementation which is vastly different between 32 bit and 64 bit hardware implementations. Not to mention the register saving and restoring issues and such.

[schlucke]

I've primarily been focused on the issue of the underlying architecture that the OS has to run on, most critically the page table implementation which is vastly different between 32 bit and 64 bit hardware implementations. Not to mention the register saving and restoring issues and such.

Sure you are

BTW: I've tried to compile Crafty 23.0 on AIX 5.3 but fail somwhere (I think in the lock stuff, but will check again). The IBM C compiler is a little picky here and there Did you compile Crafty on AIX the last years?

I think it might be interesting to see it running on a POWER6 5.0 GHZ system, compared to the Intel/AMD boxes around today. And also the copy/make versus make/unmake case might be different on such a box. It is not a Cray, but memory bandwith should be higher than on Intel boxes.

[bob]

I've primarily been focused on the issue of the underlying architecture that the OS has to run on, most critically the page table implementation which is vastly different between 32 bit and 64 bit hardware implementations. Not to mention the register saving and restoring issues and such.

Sure you are

BTW: I've tried to compile Crafty 23.0 on AIX 5.3 but fail somwhere (I think in the lock stuff, but will check again). The IBM C compiler is a little picky here and there Did you compile Crafty on AIX the last years?

I think it might be interesting to see it running on a POWER6 5.0 GHZ system, compared to the Intel/AMD boxes around today. And also the copy/make versus make/unmake case might be different on such a box. It is not a Cray, but memory bandwith should be higher than on Intel boxes.

No. And it is likely that the locks will be an issue. You would probably have to write a set of lock/unlock/etc that is (I assume) PPC compatible, since I suspect that is your target platform? Or you could make them use the pthread_mutex() stuff which is a bit less efficient.

[schlucke]

No. And it is likely that the locks will be an issue. You would probably have to write a set of lock/unlock/etc that is (I assume) PPC compatible, since I suspect that is your target platform? Or you could make them use the pthread_mutex() stuff which is a bit less efficient.

Yes, POWER6 is PPC architecture. I got the following error, indeed locking stuff:

Code: Select all

# make aix
        make target=AIX  CC=xlc CXX=cc  CFLAGS='-O -O2'  CXFLAGS=-O  opt=''  crafty-make
        xlc -O -O2  -DAIX -c crafty.c
"/usr/include/sys/lock_def.h", line 212.25: 1506-247 (S) Incompatible type specifier "int".
make: 1254-004 The error code from the last command is 1.

If you can't point me a fast way to switch to pthread_mutex stuff, it's unlikely I manage that in a few "spare" minutes. Not so much time at customer site

Is it enough to add some #defines to lock.h for the specific platform?

[bob]

No. And it is likely that the locks will be an issue. You would probably have to write a set of lock/unlock/etc that is (I assume) PPC compatible, since I suspect that is your target platform? Or you could make them use the pthread_mutex() stuff which is a bit less efficient.

Yes, POWER6 is PPC architecture. I got the following error, indeed locking stuff:

Code: Select all

# make aix
        make target=AIX  CC=xlc CXX=cc  CFLAGS='-O -O2'  CXFLAGS=-O  opt=''  crafty-make
        xlc -O -O2  -DAIX -c crafty.c
"/usr/include/sys/lock_def.h", line 212.25: 1506-247 (S) Incompatible type specifier "int".
make: 1254-004 The error code from the last command is 1.

If you can't point me a fast way to switch to pthread_mutex stuff, it's unlikely I manage that in a few "spare" minutes. Not so much time at customer site

Is it enough to add some #defines to lock.h for the specific platform?

You could do that. I think there is Lock(), Unlock() and LockInit() and LockFree() that would need to be defined.