Programming Forums

Programming Forums (http://www.programmingforums.org/forumindex.php)
-   Assembly (http://www.programmingforums.org/forum20.html)
-   -   How do OSs work on more than one CPU? (http://www.programmingforums.org/showthread.php?t=10422)

SittingDuck Jun 19th, 2006 9:27 AM

How do OSs work on more than one CPU?
 
Different CPUs have different architectures, right? Like AMD and Intel are similar, but different in the sense of paging, segmentation and so on. So how are operating systems able to run on different CPUs without a seperate release for each CPU?

Yegg Jun 19th, 2006 4:22 PM

Out of curiosity, which OS does this?

b1g4L Jun 19th, 2006 5:36 PM

Windows / Unix are two main examples

Eoin Jun 19th, 2006 5:56 PM

When it comes to Linux, the majority of an OS is written in C which is very portable across different architectures I would assumes the bits gluing this portable framework to specific CPUs is quite small and written in Assembly.

DaWei Jun 19th, 2006 6:12 PM

Portability across different architectures has nothing to do with the OP's question, as different architectures would require different releases. The same executable code can be run on differing CPUs only if the CPUs have compatible machine code for all important and basic operations. If a mostly-compatible machine has a set of instructions that could be used, where another does not, then the ability to detect this situation at runtime and call appropriate code from among a set of available alternative code expressions would be in order.

One presumes you aren't asking about code that runs on VMs, as the VM constitutes a separate release.

hush Jun 19th, 2006 6:32 PM

I’m no Linus Torvalds but here goes my limited understanding of the subject:

The portability that you are referring to here is due in main to the HAL ( hardware abstraction layer) this hides the differences in hardware (including the processor) from the operating system kernel. With these mostly hidden from the kernel it is able to do it job regardless of the architecture.

I believe that the HAL is created on installation. I’m am assuming this because if you install windows and your BOIS does not support ACPI and then you upgrade your BOIS to a one that does support ACPI then you are required to do a new instillation due to the fact that the HAL will no longer function. It also seems logical.

Some operating systems require a specific CPU. an example of this is HP unix, where it will only run on its own proprietary hardware (I believe it is called HP/PA). This does however have benefits- one is with the CPU modes: an x86 running windows may only function within the kernel mode or a user mode, however an os running on proprietary hardware would have more levels. In real terms this means that if an application crashes it is less likely to cause a system wide failure due to the fact that it is running in a less permissible mode within the CPU.

hush

SittingDuck Jun 20th, 2006 3:08 AM

Ah...

Dameon Jun 20th, 2006 10:49 AM

There seem to be some mistaken ideas in Hush's post.
Quote:

Originally Posted by Hush
I believe that the HAL is created on installation. I’m am assuming this because if you install windows and your BOIS does not support ACPI and then you upgrade your BOIS to a one that does support ACPI then you are required to do a new instillation due to the fact that the HAL will no longer function.

Your statement assumes that a HAL is an entity that can be created and destroyed. In reality, the HAL is but a portion of the kernel that is shipped on a particular architecture release. There's no reason to give it a fancy name...it's good practice in any case to separate whatever stuff is architecture/os/etc dependant from what is not. It makes perfect sense to do, really. If Microsoft has to port the NT kernel to platform X, they write a HAL that works with it, get a compiler that supports X, and they're done. In a severely simplified sense. The Linux kernel has been ported to a much larger range of architectures, possibly due to the availability of the source. You don't see the mention of "HAL" anywhere, but the principle is the same.

Quote:

Originally Posted by OP
Different CPUs have different architectures, right? Like AMD and Intel are similar, but different in the sense of paging, segmentation and so on.

The OP also seemse to have some misconceptions.
AMD and Intel are companies, not architectures. x86 is an architecture, first around way back when with the 8086, 386 and friends. It just so happens that since then, x86 has become wildly popular...the original IBM PC, for one, followed by the army of clones by various companies. When Microsoft went on to release Windows, it would only make sense to write it for the same architecture as DOS and sell to the same market. The rest is history. x86 processors have dominated the desktop market even until now, with two main manufacturers: Intel, the original creator of the architecture, and AMD, a fairly succesful cloner. But both AMD and Intel's x86 chips adhere to the x86 spec...same registers, behavior, etc. You don't have to have separate software releases for the same architecture, which is why you don't see AMD and Intel versions of software at the store. At least, that's how I interpreted your question. Correct me if I misunderstood.

Dragon_Master Jun 20th, 2006 12:43 PM

I think the others said it nicely, but those cpu's are all part of the x86 family, I believe. They all have similar instructions. So, windows and linux,for example can run on a variety of systems. Each of them, of course has a bunch of options that the others don't. It's pretty simple actually. BTW, I'd like to mention HAL only exists in NT based systems. It wasn't around in the 16 bit windows, windows 95, windows 98, ect...

Dameon Jun 20th, 2006 12:58 PM

Yes. That is likely part of the reason the earlier kernels weren't ported off of x86...the change would have likely required a significant rewrite. NT was, in itself, a rewrtie. Off the top of my head, the NT kernel can run on Alpha and x86.


All times are GMT -5. The time now is 3:09 PM.

Powered by vBulletin® Version 3.7.0, Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Copyright ©2007 DaniWeb® LLC