views:

331

answers:

10

i googled about it and some where i read ....

Yes, you can. That is happening in the case of embedded systems

As per i think, NO, its not possible. Any platform must have an operating system. Or else, your program must itself be an OS. Either soft or hard-wired. Without an operating system your component wouldn't work.

Am i right or can anybody explain me the answer.( I dont have any idea abt embedded systems...)

+10  A: 

Of course you can. All a (typical) CPU needs is power and access to a memory, then it will execute its hard-coded boot sequence.

Typically this will involve reading some pre-defined address, interpreting the contents there as instructions, and starting to run them.

These instructions could of course come from a C program, although at this level it's more common to write the very early stages (called bootstrapping) in assembly.

unwind
+2  A: 

Usually, any C program will have a variety of system calls which depend on the operating system. For example, printf makes a system call to write to the screen buffer. Opening files and things like that are also system calls.

So basically, you can run the C code which just gets compiled and assembled in to machine code on a processor, but if the code makes any system calls, it would just freeze up the processor when it tries to jump to a memory location that it thinks is the operating system. This of course would depend on your being able to get the program running in the first place, which is not easy without the operating system as well.

Dave
Programs written to run directly on the hardware obviously don't use system calls, and is developed on systems that run on general-purpose computers that normally simulate the real thing and which compile for use on the actual hardwar.
David Thornley
+1  A: 

Embedded systems are legitimate OS's in their own right, they're just not general purpose OS's. Any userland program (i.e. a program that is not itself an operating system) needs an operating system to run on top of.

Chris
That wasn't even true of some general-purpose computers. There were programs for my old TRS-80 that did their own display and disk handling, completely bypassing TRS-DOS. The keyboard and display were memory-mapped, so the Z80 processor could handle that directly. There was a direct hardware route to the 1771 (?) floppy disk controller.
David Thornley
@David Thornley: Even later, programs like DesqView under DOS.
Tim Post
I stand corrected. Thanks, guys!
Chris
A: 

every piece of hardware has to have a piece of software that operates it, be it embedded firmware (smaller and relatively fixed, like vxworks) or an operating system software that can run complex arbitrary code on top of it (like windows, linux, or mac).

think of it as a stack. at the bottom, you have the hardware. on top of that, a piece of software that can control that hardware. on top of that, you can have all sorts of stuff. in the case of a voip phone, you'll have vxworks controlling the hardware, and a layer on top of that that handles all the phone applications.

so going back to your question, yes, you CAN run any c program on anything, BUT it depends what kind of c program it is. if it's a low level c program that can talk to hardware, then you dont need anything other than your program and the hardware. if it's a higher level c program (like a chat program), then you need a whole bunch of stuff between your program and the hardware.

make sense?

Oren Mazor
+4  A: 

You can run a program in a system without an Operating System ... and that program need not be an Operating System itself.

Think about all the computers (or processors if you prefer) inside a car: engine management, air conditioning, ABS, ..., ...
All of those system have a program (possibly written in C) running. None of the processors have an OS.

The Standard specifically differentiates between hosted implementations and freestanding implementations:

    5.1.2.1 Freestanding environment
1   In a freestanding environment (in which C program execution may take place
    without any benefit of an operating system), the name and type of the
    function called at program startup are implementation-defined. Any library
    facilities available to a freestanding program, other than the minimal set
    required by clause 4, are implementation-defined.
2   The effect of program termination in a freestanding environment is
    implementation-defined.

    5.1.2.2 Hosted environment
1   A hosted environment need not be provided, but shall conform to the
    following specifications if present.
    ...

pmg
A: 

Obviously, you cannot execute any arbitrary C program without some sort of OS or OS-equivalent. Similarly, I can write a C program under Linux that won't run under Microsoft Windows.

However, you can write C programs on almost anything. It's a popular language to write software for embedded systems in, and they very often don't have an OS.

Many embedded systems have just a CPU hooked up to a ROM, with pins coming out of the chip that are directly attached to inputs and outputs. There is no user I/O, no file system, no process scheduling, nothing you'd typically want an OS for. In those cases, a C programmer might write a program that is burned into a ROM, which will handle everything itself.

(Some embedded systems are more complicated, and can use an OS. Linux is frequently used, since it's free for the use, can be made very compact, and can be changed at any level. Not all do, though.)

David Thornley
It seems to me that boot loaders kind of disagree with your logic? No, you can't link some ELF and expect it to boot, but you can make something that _will_ boot and do primitive things without too much trouble. I.e. ... memtest :)
Tim Post
Depends on the program, and whether it's making system calls, receiving system calls, or making them up.
David Thornley
+3  A: 

I think you would have fun writing 'toy' kernels that are designed to run under simulators like QEMU (or virtualization platforms, Xen + MiniOS is one of my favorites). With not (much) difficulty, you could get a basic console up and running and start printing things to it. Its really fun, educational and satisfying all at once.

If you are working on x86 .. and get your spiffy kernel working under QEMU .. there's a very good chance that it will also work on real hardware. You might enjoy it.

Anyway, the answer to your question is most decidedly yes. Its especially easier if you happen to be using a boot loader .. for instance, google memtest86 and grab the code.

Tim Post
+1  A: 

As an example: Building Bare-Metal ARM Systems with GNU

Many embedded systems do not have enough resources for a full OS, some may use a scheduler kernel or RTOS, others are coded 'bare metal'. The main() C entry point is entered after reset. Only a small amount of assembler code is required to initialise a microprocessor, to execute C code. All C requires to run generally is a stack - usually simply a case of initialising the stack pointer to a specific address. Some processor specific initialisation of interrupt/exception vectors, system clocks, memory controllers etc. may be necessary also.

On a desktop PC, typically you have a BIOS that handles basic hardware initialisation such as SDRAM controller setup and timing, and then bootstrapping from a disk boot-sector, which then in turn bootstraps an OS. Any of that code could be written in C (and some of it probably is), and it could do something other than boot an OS - it could do anything - it is just code.

OSs are useful for non-dedicated computing devices where the end user many select one of many programs to execute and possibly several simultaneously. Most embedded systems do just one thing, the software is often loaded from ROM or executes directly from ROM, and is never changed and executes indefinitely (usually stopped only by power-down).

You still of course might implement device drivers and the like, but often these are an integral part of the application rather than a separate entity. Even when you do use an RTOS in an embedded system, it is still generally integral to your application rather than an OS in the sense you might understand. In these cases the RTOS is simply a library like any other, and is often initialised and started from main() rather then the other way around as you might expect.

Clifford
I've run c on systems (8051 based) with as little as 128 bytes of RAM (that's 128 bytes, not kilobytes or megabytes) and that included the stack space. Obviously no room for an OS there.
Dipstick
@chrisharris: I would not say that. Because of its eight duplicated register banks, task context switches are very easy to implemented. In the early 90's I used 8051 (when they were still Intel parts) with iDCX-51, a real time executive for MCS-51 devices. Then there was no C compiler, instead it used PLM/51 or Assembler. Arguably a real-time executive is not an OS, but definitions vary. There are a number of RTOS kernels for 8051, although most modern 8051 architecture parts are better endowed with resources.
Clifford
A: 

You definitely don't need an OS to run your C code on any system. What you will need is two pieces of initialization code - one to initialize the hardware needed (processor, clock, memory) and another to set up your stack and C runtime (i.e. intialization of data and BSS sections). This, of course, means that you cannot take advantage of the multithreading, messaging and synchronization services that an OS would provide. I'll try and break it down into some steps to give you an idea:

  1. Write a "reset_routine" that run when the board starts. This will initialize the clock and any external memory needed. (This routine will have to execute from a memory that is either internal or one that can be initialized and programmed externally).
  2. The reset_routine, after the hardware initializations, transfers control to a "sw_runtime_init" routine that will set up the stack and the globals definied by you application. (Do a jump from reset_routine to sw_runtime_init instead of a call to avoid stack usage).
  3. Compile and link this to you application, whilst ensuring that the "reset_routine" is linked to the location where the reset vector points to.
  4. Load this onto your target and pray.
mandrake
A: 

when you get a windows exe file yes it is os dependent but .obj (object) file is only processor dependent which contains bare machine code yes you got object file .ok but now what how to boot a pc by this object file

suraj