why only C?

[Bernd Petrovitsch]

Hi!

On Mon, 2011-04-04 at 06:00 +0530, Chaitannya Mahatme wrote:
> On Monday 04 April 2011 01:19 AM, Bernd Petrovitsch wrote: 
[...] 
> > On Mon, 2011-04-04 at 00:47 +0530, mohit verma wrote: [....] 
> >   
> > > As far as i can decipher , we impose Object oriented paradigm in
> > > kernel space using C  : like using gates to allow only one way entry
> > > and binding functions to structures in a OOP fashion  and trying to
> > > make them private to that structure only  , encapsulation of one
> > > struct into another structure (and lots of features ) and itself  lots
> > > of kernel subsystem supports like driver interface and blah blah
> > > behaving like **objects** .......
> > >     
> > OOP is a design issue independent of the used programming language. So
> > you actually *can* do OOP with C (or assembler or ....) and I have seen
> > C++ programs which do not employ the ideas behind OOP.
> >   
> > > why dont we use some fully OOPs supportive language like JAVA or
> > > partial supportive language like  C++ to construct Linux Kernel????
> > >     
> > What does it buy and what does it cost?
> > 
> > For - or more against - Java: You really do not want an OS to use an
> > interpreted "language". That kills performance. And the more interesting
> > challenge is to implement hardware IRQ handlers in Java.
> >   
> JVM has been optimised to such a level that it beats C++ in
> performance. Only thing faster than that is C and assembly language. A

In which benchmarks?

I forgot to differentiate: Above I assumed the clichee Java-app witch is
run via a (usually not so small) JVM[0]. The alternative is to compile
the Java bytecode (or Java source directly) into native machine code -
and that as such can be probably as fast as C (provided one avoids the
kmalloc()/kfree() trashing (or whatever it is called there) for each
object and control the inherent features like garbage collection).
In both cases, I doubt that one want to live in a kernel with
- garbage collection and - apart from the simple arithmetic types - only
  "objects". It is as if every struct in the kernel is allocated via
  kmalloc().
- You have various parts which are inherently CPU-dependent - starting
  with IRQ handlers and memory management where you really have to live
  with the hardware.
So you will end up with a lower part written in C (or whatever) and the
higher layers in something completely different.

For a "use Java for an OS" approach, it is probably way better/easier to
take an existing microkernel and build the various drivers/servers/...
in Java.

> few chips process Java byte code at hardware level as well.  
> Read this http://en.wikipedia.org/wiki/Jazelle   ... So this can't be
> a valid argument.

Well, you want the Linux kernel (or any other real kernel) to run on
virtually any hardware so a "few chips" don't really help as a point for
Java bytecode. Perhaps/probably it's good to use it on these "few chips"
but that doesn't help the server and desktop world with Intel and AMD
CPUS and the embedded worlds with ARM, MIPS, PowerPC, etc.

> The key thing over here is purpose. OOP based languages are
> essentially meant to abstract the developers from the hassles of  low
> level operations (Assuming a programmer well versed with OOP) , so the

In my experience you have in an application many more than 2 levels -
some more explicit like libraries, some less explicit within the
application.
And you really want to design it so that the higher levels abstract more
than the next lower level. But with every abstraction level, you loose
some influence/control and the key question is if you can live with it.

For a pure userspace application, it is (usually, in most cases) not an
issue and and an issue is to get correct working software in (quite)
short time (so e.g. some garbage collector seems useful). Well, in
realtime applications, you probably do not want some general purpose
garbage collector to chime in for 2 seconds at the wrong time.

RAM is in desktop and server applications not really an issue as it's
cheap. In the embedded world, you may have only 8 or 16MB RAM in the
system (and no, I consider smart phones with 128MB RAM and a touch
screen in no way "embedded", there are just small PCs). I worked once
for a company building an embedded system with 4MB FlashRAM for the
firmware image and 16MB RAM (and 50MHz PowerPC-based 32bit CPU).

And that's the class of problems one also has in a kernel.

> focus is on application development. Java plays an important role in
> isolating low level hardware issues. That's why you have Java as a

Java claims to be portable everywhere. So they refuse to deliver
features which are not available everywhere (e.g. AF_UNIX sockets). That
boils down to the least common denominator of available features. But
there are lots of situations where "total portability" is not important.

> proffered choice for mobile apps and not C. 

IMHO it was just hyped at that time and the programmers there nowadays
are trained/used/know how to work around the problems with it. Let's see
on the first project in that direction if they really know what
protocols, encodings, data formats, etc. .... their apps really use on
the wire (or more on TCP/IP) if the server side is on a small/real
embedded system where some Java implementation is plain simply not
possible. Or at least if they can find the documentation for that;-)

> If you are developing kernel, you are programming bare metal. You have
> to do low level operations like loading the program into the memory,
> defining it's data segment, code segment, etc. Hence C is the obvious
> choice since it's the closest to the hardware (meaning simple to deal
> low level operations) and well structured than assembly language. 

FullACK.
There is the saying the "C is just a portable assembler";-)

Bernd

[0]: Yes, there is "embedded Java". I never looked into it.
-- 
Bernd Petrovitsch                  Email : bernd at petrovitsch.priv.at
                     LUGA : http://www.luga.at