views:

191

answers:

5

Why we are saying that the OS is purely hardware dependent (other than hardware peripherals like RAM/USB etc)? The word hardware independence means, the OS should run on any platform with out any underlying hardware abstraction layer like ARM/x86/xtensa/starcore etc etc.

Can you please give me the exact hardware dependencies in a simple/common OS? Meaning exactly in which are all points in the OS is accessing the hardware or depending on the platform?

Also is it possible to write a simple OS or a RTOS (using C language) with out any hardware or platform dependency(ie without any VM concept) so that it'll run on any platforms?

I would be expecting the answers from the OS kernel side and not from the peripheral side like RAM /keyboard/mouse

I will give you an example of exact hardware dependency in an OS "at context switching (context of the tasks/threads should be stored with help of underlying platform/CPU only)"
__Kanu

+1  A: 

Pretty much everything about an OS is hardware dependent in some way, from memory management to timers (scheduling) to networking to video to keyboard to BIOS. All of this will require hardware-dependent C code and/or assembly.

That doesn't mean you can't extract out a lot of common C code which is shared between architectures. Linux is a classic example of this. It has been ported to a vast array of hardware platforms, requiring custom code for each platform. However, there's still a large body of shared C code (e.g. filesystem drivers).

And of course, even the parts that are ANSI C only run on your hardware if your compiler can target it.

Matthew Flaschen
I'd just like to point out that both OSX and Windows are also classic examples of this.
Randolpho
@Randolpho, neither of them are ported nearly as widely as Linux.
Matthew Flaschen
@Matthew: True, but both were designed from the ground up to support doing so, and both have been ported successfully. It's inherent to their design. Versus e.g. MS-DOS, Windows 9x, or classic Mac OS.
quixoto
@quixoto: Mac OSX is a BSD Unix on a Mach micro-kernel with a lot of stuff from NeXT on top. It's run on two or three architectures, but then classic Mac OS ran on two (680?0 and PowerPC). MS Windows was at least designed to run on more than one architecture, but isn't nearly as widely ported as Linux.
David Thornley
@quixoto: Yes, both started out as being pretty portable, but nowadays both only run on x86.
DarkDust
+1  A: 

If an OS had no hardware dependancies, how could it received input from the output world, and output back to them the results?

James Curran
i don't know whether this is a fake information or not http://tech2.in.com/india/previews/software/blixos-an-independent-operating-system/146162/0
Renjith G
That link is laughable. It's allegedly "hardware independent", and it requires "only" 120 MB of main memory. Strangely, it didn't even install on my phone or my PDP-11.
Matthew Flaschen
oops. http://www.blixcorp.com/
Renjith G
@Mathew, I have a PDP-11 in the other room. It still boots and runs TSX-11 or RT-11. Its 8" floppy drive still work too. Gotta love hardware built that solidly... it's older than many of the users here ;-)
RBerteig
@RBerteig, sadly, I don't really have a PDP-11, and yours probably is older than me. I do know it's a venerable machine, and it also shows the folly of the 14-year-old BlixOS kids.
Matthew Flaschen
@Mathew, we had it turned on just the other day to help a friend recover some files from a box of archived floppies. Some of the files had legitimate dates in 1978, which led to the discovery that .ZIP files don't support dates that old.... That BlixOS site does look like a pipedream (or nightmare).
RBerteig
+3  A: 

In general, the following things are hardware dependent:

  • System startup/reset
  • Interrupt handling
  • Virtual memory management & protection
  • Device I/O
  • System-level protections for code access and security
  • Some mutual exclusion primitives.

At some level, way way down, an OS kernel needs to sit on top of something. Most kernels are written such that they touch the hardware with as small a surface area as possible, but there must be some touch point there.

You can write most of a kernel in C (this is usually the case). But you'll need to run on top of something. If you fudge with the definition of an OS a little bit, you could have a "microkernel" that is hardware-dependent, and build many of the above as abstractions as a toy OS on top of it, but you'd suffer in performance/accuracy/sophistication.

quixoto
What about a small RTOS? suppose system start up are done on BIOS and not on OS?
Renjith G
You're depending on the specific BIOS interface, as well as on the architecture of the CPU itself. You can all that "hardware independent" if you want, but it still requires a compile for the CPU and the presence of the expected BIOS interface.
quixoto
yes. Suppose we are having the source code(in C language) of small RTOS, then we can cross compile it for any platform as our wish right? then we can say the source code of this OS is hardware/platform independent?
Renjith G
You could, but I wouldn't. The source code of your hypothetical RTOS would still assume a certain BIOS interface. That BIOS is a "platform", and your OS depends on that. I'll be honest, it's not totally clear what the thrust of your question is. Are you trying to validate that news story you posted a link to? Or understand what they mean when they say that? "Marketing" aside, nothing I would call an "operating system" is "platform independent". Operating systems are the very things that mediate between "application"-level software/tasks and a machine.
quixoto
No. I am not validating that. After searching for the hardware dependency of OS in google , i got that link. Also Why the RTOS needs a BIOS interface? If we are loading our cross compiled RTOS with sample application after boot up through a JTAG interface , then it will start run from os_main() right?
Renjith G
There is a lot of machine dependent stuff that needs to be done before your "os_main". E.g. on Intel, switch to protected mode, set up all the tables for memory management and task separation, interface with peripherals like a hard-disk to even start loading your "os_main", setting up the necessary environment for it and then, maybe we are ready to call "os_main". On other systems there might even be more work to be done like setting up interrupt tables. There is a lot of stuff going on, even in MS-DOS, which is the most primitive OS I've known, before you even see one character on the screen.
DarkDust
but what about a small RTOS? like AUTOSAR OS?
Renjith G
@Renjith, you seem to want very badly to stretch this term "hardware independent" and apply it to something. So go ahead. AUTOSAR requires a microcontroller abstraction layer, though, which represents the "hardware" for all practical purposes. As DarkDust notes, somebody has to do this work. If you want to call that something besides the OS, go ahead, but very few other people would classify it that way. :)
quixoto
ok..please consider me in that very few other people group :-)
Renjith G
+2  A: 

Any operating system is at least depending on one piece of hardware: the CPU. There are different CPUs, each working differently and having a different "native language". Since an OS is "just a program" which needs to run on the CPU, it must be written in the CPUs native language is thus dependent on it. You cannot run a normal Windows on an ARM or PowerPC processor, for example. It only runs on Intel-compatible CPUs.

It is possible to write an OS that can be compiled for different CPUs and run on them, most UNIXes like Linux, FreeBSD, etc. are good examples. But the need to be compiled ("translated") for each CPU they want to run on.

Apart from the CPU, an OS also needs ways to process something, so it needs input and output like a hard-disk or ROM, a screen and a keyboard (but not necessarily; e.g. an elevator has no need for a real keyboard and often doesn't even need a screen). And there are various different ways to access each of these devices and the OS depends on these methods (for example, bus systems like the PCI bus, or dedicated chips like a 16550 for serial ports).

DarkDust
yes. Suppose we are having the source code(in C language) of small RTOS, then we can cross compile it for any platform as our wish right? then we can say the source code of this OS is hardware/platform independent?
Renjith G
Almost. There's always bootloading which is different on almost every machine, as well as memory and task management. Those two are pretty heavy tasks. And you almost always need some assembly language to do certain machine dependent tasks. So, the smaller the OS the bigger the percent of machine dependent code, I guess. As the OS grows bigger the machine dependent parts don't get smaller but take up less percent of the total kernel.
DarkDust
Yes, but, it is not possible to write an interrupt handler in standard C, or even in a portable non-standard C. Yet your OS needs to support interrupts for time management and efficient device I/O. It may need to use software interrupts to implement the ABI between application code and kernel. Even a portable OS still requires at some platform dependent code, and almost always requires some code in assembly language as well.
RBerteig
Can you clarify your below point? " but, it is not possible to write an interrupt handler in standard C, or even in a portable non-standard C" ?
Renjith G
+1  A: 

Every point where input and output occur is hardware dependent.

Every point where interrupts come into play is hardware dependent.

Every point where memory itself is managed is hardware dependent.

In other words, if you care about it, it's probably hardware dependent.

Man I like embedded systems.

Paul Nathan
suppose if there is a RTOS having a small scheduler part only ..then?
Renjith G
Well, there will be an ecosystem around the scheduler that relates to the timer, how the stack is manipulated, etc. Those are all hardware dependent.
Paul Nathan
@Renjith G, The logic of a scheduler can be completely hardware independent, but an efficient (and correct) context switch cannot. I once built a cooperative lightweight threading kernel to run inside a Unix application out of essentially nothing more that `setjmp()` and `longjmp()`. It worked, but since it only managed what those functions covered, it had some serious limitations. Doing a context switch correctly requires that the task switcher *know* exactly what *hardware* state is important to preserve for each task.
RBerteig