By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
449,412 Members | 993 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 449,412 IT Pros & Developers. It's quick & easy.

[25% OT] C library integral part of OS/kernel???

P: n/a
Is the C library of most OSes (i.e, unix type OSes) implemented at the
very low kernel or just outside kernel level?

Looking through the source tree of Linux/BSDs it seems like the C
library is intertwined with the OS (string.h and other headers are
there). So does this mean that when I program in C and use standard
library functions, it's similar to calling the OS specific APIs (same
type of performance)?

Seeing all these Standard Library functions being implemented at the
kernel/OS level makes me want to use C more, because it obviously means
other languages are implemented at a level "more distant" from the
system (possibly calling the C library functions????).

Is my thinking correct or am I way off? Am I getting too excited by
seeing standard library functions being implemented in OS kernel code?

Clarification will be appreciated.

Nov 14 '05 #1
Share this Question
Share on Google+
50 Replies


P: n/a
"Romeo Colacitti" <ww*****@gmail.com> wrote in message
news:11*********************@g14g2000cwa.googlegro ups.com...
Is the C library of most OSes (i.e, unix type OSes) implemented at the
very low kernel or just outside kernel level?

Looking through the source tree of Linux/BSDs it seems like the C
library is intertwined with the OS (string.h and other headers are
there). So does this mean that when I program in C and use standard
library functions, it's similar to calling the OS specific APIs (same
type of performance)?

Seeing all these Standard Library functions being implemented at the
kernel/OS level makes me want to use C more, because it obviously means
other languages are implemented at a level "more distant" from the
system (possibly calling the C library functions????).

Is my thinking correct or am I way off? Am I getting too excited by
seeing standard library functions being implemented in OS kernel code?

Clarification will be appreciated.

The thing is, the standard C library MUST be based on something. This
something is the OS kernel (actually, this is true not only of C, it's like
that with any other language and its standard library). So, it doesn't
matter how tight and explicit the relationship between the two is, it is
there by definition.
On the other hand, lots of the standard C functions are generic and useful
enough to be used inside the OS kernel itself. Yes, those string functions,
conversion functions, I/O functions, whatever. So, the kernel MAY and often
DOES use them too.
The key difference is that the kernel provides some base functionality,
usually very low-level. The standard C library and the applications are
built on top of that, these are higher-level. BUT (!) there's nothing that
prevents you from using the higher-level functions in the kernel. I mean,
the kernel does use its own low level functionality and may use the high
level functionality, which is based on its low level funcs... You see, if
you have sprintf() and want to use it in the kernel, you can do that -- you
don't need to have a special version of sprintf() just for the kernel
itself. The 2nd would contribute to the bloat. You could use open()/fopen()
in the kernel, you should be able to because the kernel (plus the drivers)
will provide you with file access anyway, even though it's on low level. If
high level is more convenient for use yet doesn't compromise the kernel, do
use it in the kernel.

Alex
Nov 14 '05 #2

P: n/a
Romeo Colacitti wrote:
Is the C library of most OSes (i.e, unix type OSes) implemented at the
very low kernel or just outside kernel level?
"Yes."

From the C Standard's point of view (you've posted to
comp.lang.c), the library is part of "the implementation"
and the internal arrangements of the implementation are
whatever the implementor chooses. The Standard describes
what the implementation (including the library) must do,
but not how it must be done.

In most implementations, some parts of the library are
entirely "user-land code" but others require some amount of
help from the O/S. It's likely that qsort() runs entirely
in user land, but it's likely that fopen() is a mixture of
user and kernel code.

P.J. Plauger's "The Standard C Library" is a good
exposition of a typical (C90) library implementation. (Yes:
I seem to have plugged this book quite a lot recently, but no:
I don't get a commission ...)
Looking through the source tree of Linux/BSDs it seems like the C
library is intertwined with the OS (string.h and other headers are
there). So does this mean that when I program in C and use standard
library functions, it's similar to calling the OS specific APIs (same
type of performance)?
Different systems will have different performance. That's
about all the typing I care to do on this very complex subject;
others may have more stamina.
Seeing all these Standard Library functions being implemented at the
kernel/OS level makes me want to use C more, because it obviously means
other languages are implemented at a level "more distant" from the
system (possibly calling the C library functions????).
Non sequitur: the fact that something is "in the kernel"
doesn't in and of itself give a speed advantage. On most
systems, crossing and recrossing the user/kernel boundary
exacts a time penalty (part of the job of <stdio.h> is to
reduce the number of crossings). Even if the in-kernel code
for this or that function is faster than a user-land version,
a program that needs to hop in and out of the kernel to use
that faster code may actually run more slowly. Don't drive
ten kilometers to avoid one traffic signal.

Also, if the performance of individual micro-operations is
all-important to you, you should not use ANY high-level language,
be it C, Lisp, Java, Ada, or COBOL. For any given programming
task, the O/S is too general and hence too slow; discard it and
implement your own specialized version. And don't use assembly
language: use hand-crafted numeric machine code. You'll have
the fastest imaginable implementation -- for a machine that will
have become obsolete before you finish your code ... Performance
is far from the be-all and end-all of good programming.
Is my thinking correct or am I way off? Am I getting too excited by
seeing standard library functions being implemented in OS kernel code?


I think you are. YMMV.

--
Eric Sosman
es*****@acm-dot-org.invalid
Nov 14 '05 #3

P: n/a
Eric Sosman <es*****@acm-dot-org.invalid> writes:
[...]
Non sequitur: the fact that something is "in the kernel"
doesn't in and of itself give a speed advantage. On most
systems, crossing and recrossing the user/kernel boundary
exacts a time penalty (part of the job of <stdio.h> is to
reduce the number of crossings). Even if the in-kernel code
for this or that function is faster than a user-land version,
a program that needs to hop in and out of the kernel to use
that faster code may actually run more slowly. Don't drive
ten kilometers to avoid one traffic signal.


Some C library functions can be implemented straightforwardly in C.
strlen() is a good example. If the OS kernel is written in C, it's
going to need some sort of C library (though it may not be a fully
conforming hosted implementation).

My guess is that there's only one implementation of the strlen()
function, and that it's callable either from the kernel or from user
code without crossing the user/kernel boundary. It's just a function
call. The same is going to be true for a lot of other C library
functions.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #4

P: n/a
Keith Thompson wrote:
Eric Sosman <es*****@acm-dot-org.invalid> writes:
[...]
Non sequitur: the fact that something is "in the kernel"
doesn't in and of itself give a speed advantage. On most
systems, crossing and recrossing the user/kernel boundary
exacts a time penalty (part of the job of <stdio.h> is to
reduce the number of crossings). Even if the in-kernel code
for this or that function is faster than a user-land version,
a program that needs to hop in and out of the kernel to use
that faster code may actually run more slowly. Don't drive
ten kilometers to avoid one traffic signal.


snip

My guess is that there's only one implementation of the strlen()
function, and that it's callable either from the kernel or from user
code without crossing the user/kernel boundary. It's just a function
call. The same is going to be true for a lot of other C library
functions.


I've even seen some "redefinitions" of library functions in kernel code
for unix-type operating systems. Something like:

#include <stdio.h>
int getchar()
{
return getchar();
}

So this suggests that these kernel writers are trying to get these C
functions to "propogate" in future versions of the kernel - I think.
So I guess compiling the code for the kernel, creates the standard
library in the kernel itself. It seems like the standard library is as
much important to these OSes as POSIX functions, etc. I guess this is
another reason why C is considered efficient - it's library is closer
to kernel (or part of it).

Nov 14 '05 #5

P: n/a
> kernel/OS level makes me want to use C more, because it obviously means
other languages are implemented at a level "more distant" from the
system (possibly calling the C library functions????).


Yes. Usually, it is so.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma***@storagecraft.com
http://www.storagecraft.com
Nov 14 '05 #6

P: n/a
Romeo Colacitti wrote:

I've even seen some "redefinitions" of library functions in kernel code
for unix-type operating systems. Something like:

#include <stdio.h>
int getchar()
{
return getchar();
}


I hope "something like" means "rather different."
There are two invocations of undefined behavior in the
above, and if they don't bite you the remaining problem
surely will ...

Recursion (n): see "recursion."

--
Eric Sosman
es*****@acm-dot-org.invalid
Nov 14 '05 #7

P: n/a
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
My guess is that there's only one implementation of the strlen()
function, and that it's callable either from the kernel or from user
code without crossing the user/kernel boundary. It's just a function
call. The same is going to be true for a lot of other C library
functions.


Your guess is typically wrong: a kernel is a freestanding program
and it doesn't rely on any external library, not even the standard
C library. It defines all the standard C library functions it uses,
which is OK for an application translated in freestanding mode.

The source code of the kernel's strlen() may be the same as the
source code of the C library's strlen(), but they're still completely
separate entities, that can be maintained independently (kernel people
and library people are not necessarily the same). Nontrivial
functions, like malloc and friends may have completely different
implementations.

Dan
--
Dan Pop <Da*****@ifh.de>
Nov 14 '05 #8

P: n/a
Romeo Colacitti wrote:
Is the C library of most OSes (i.e, unix type OSes) implemented at the very low kernel or just outside kernel level?

Looking through the source tree of Linux/BSDs it seems like the C
library is intertwined with the OS (string.h and other headers are
there). So does this mean that when I program in C and use standard
library functions, it's similar to calling the OS specific APIs (same
type of performance)?

The C library is usally integrated into the OS, but not the kernel part
of it. The code you saw in the kernel code is for use by the kernel
developers. But part of what you're saying is right (see below).

Seeing all these Standard Library functions being implemented at the
kernel/OS level makes me want to use C more, because it obviously means other languages are implemented at a level "more distant" from the
system (possibly calling the C library functions????).

Is my thinking correct or am I way off? Am I getting too excited by
seeing standard library functions being implemented in OS kernel code?
Clarification will be appreciated.


The library is implemented as part of the userland of the OS (which is
GNU not linux) - libc. That's why all the standard C library functions
are in the man pages, where as the C++, python, perl are not. The
standard C library is considered part of the "OS's SYSTEM CALLS." So
it is in the 'OS' , but not the kernel (the userland part of the OS).
This can only be said for the C library, no the C++, perl, python etc
(which incidentally could be calling/using the C library system calls)
- outside the userland.

Nov 14 '05 #9

P: n/a
Luke Wu wrote:
Romeo Colacitti wrote:

The library is implemented as part of the userland of the OS (which is GNU not linux) - libc. That's why all the standard C library functions are in the man pages, where as the C++, python, perl are not. The
standard C library is considered part of the "OS's SYSTEM CALLS." So
it is in the 'OS' , but not the kernel (the userland part of the OS).
This can only be said for the C library, no the C++, perl, python etc
(which incidentally could be calling/using the C library system calls) - outside the userland.


This diagram better compares the API provided by other languages, with
the API provided by C (for unix/linux). As you can see, LIBC is
"closer" to the kernel, but not "in" the kernel.

JAVA API
|
\/
JVM
/ \
POSIX LIBC(c api)
| |
\/ \/
SYSTEM CALLS
|
_____ \/_____
| KERNEL |
|___________|

Nov 14 '05 #10

P: n/a
Romeo Colacitti wrote:
Is the C library of most OSes (i.e, unix type OSes) implemented at the very low kernel or just outside kernel level?

That would depend on what your definition of _most_ is. If by most you
mean Operating Systems that are _USED_ the most, then yes you are
right, but these days I see a lot of {new} Operating systems that are
trying to move away from the monolithic design paradigm. In these
{[micro][nano][pico]}kernel architecture there is very little need of
adding a large part of the C library {seperately} in the Operating
System Kernel. They could very well implement a substantial portion the
C library at the _user_ level. Under which case the Operating System's
C library and yours {c/w}ould be same.
Looking through the source tree of Linux/BSDs it seems like the C
library is intertwined with the OS (string.h and other headers are
there).
That the string functions were implemented in <linux/string.h> is
nothing _but_ a mere coincidence the developers could have named it
<linux/hakuna_matata.h>. But familarity is a big aspect of any project.
So does this mean that when I program in C and use standard
library functions, it's similar to calling the OS specific APIs (same
type of performance)?

Most of the C libary calls that you make, printf, scanf, malloc, free,
fopen, fclose etc. require _at-least_ 2 levels

a) Your [gcc or MS] C libary.
b) Operating System underneath.

Though in case of Operating Systems like Linux, if you are using
functions like kprintf, kmalloc and strlen etc you are directly linking
your code with library. Which in a sense could be considered to be
static linking of your calls.

Seeing all these Standard Library functions being implemented at the
kernel/OS level makes me want to use C more, because it obviously means other languages are implemented at a level "more distant" from the
system (possibly calling the C library functions????).

In way you are quite right, there are people who consider .NET and Java
to be _mere_ wrappers. I don't[%].

Is my thinking correct or am I way off? Am I getting too excited by
seeing standard library functions being implemented in OS kernel

code?

The very important point that favors C being used in Operating Systems
is that no other compiler-for-language-other-than-c has been able to
been able to beat code-generated-by-c-compilers. It is very much
possible to write an Operating System within a programming language
like Java, with a pinch of salt actually, and then generating the
native code for a platform like i386, again with a pinch of salt. There
is at least one Operating System Project that attempts to do so.

[%] An interesting point is that .NET's CLR was implemented in C++,
actually first in LISP the translated to C++. I am quite sure that JRE
is also implemented in a similar fashion. Why this is so, is left as an
exercise for the interested reader.

--
Imanpreet Singh Arora
If I am given 6 hours to chop a tree, I will spend the
first 4 sharpening my axe.
-- A.L.
It's been 10, Can I stop now?
-- Nisha

Nov 14 '05 #11

P: n/a


Dan Pop wrote:
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:

My guess is that there's only one implementation of the strlen()
function, and that it's callable either from the kernel or from user
code without crossing the user/kernel boundary. It's just a function
call. The same is going to be true for a lot of other C library
functions.

Your guess is typically wrong: a kernel is a freestanding program
and it doesn't rely on any external library, not even the standard
C library. It defines all the standard C library functions it uses,
which is OK for an application translated in freestanding mode.

So, when an executable gets built, then there are two copies of C
library functions (one copy of functions used by kernel and other by
user/app level) !! An app might end up using user level c functions but
dont you think this approach increases the executable size :-(
in the end ?

- Ravi

The source code of the kernel's strlen() may be the same as the
source code of the C library's strlen(), but they're still completely
separate entities, that can be maintained independently (kernel people
and library people are not necessarily the same). Nontrivial
functions, like malloc and friends may have completely different
implementations.

Dan


Nov 14 '05 #12

P: n/a
On Tue, 08 Mar 2005 11:49:08 +0530, in comp.lang.c , Ravi Uday
<ra******@gmail.com> wrote:
Dan Pop wrote:
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
My guess is that there's only one implementation of the strlen()
function, and that it's callable either from the kernel or from user


Your guess is typically wrong: a kernel is a freestanding program
and it doesn't rely on any external library,

So, when an executable gets built, then there are two copies of C
library functions


Maybe, maybe not. Dan's guess is probably as wrong as Keiths, and both are
just as possibly right. Indeed if you read what Keith said, its not even
incompatible with Dan's comment.

For example the kernel may provide a service to allow userland apps to call
its version of the C library functions. Or the two may both use an
physically external library and there may be one shared copy in memory, or
two separate copies one in userspace and one in kernelspace, or there may
be two or more physical copies of the library on disk - consider that you
probably have executables built with microsoft, gnu and borland C, each
providing their own library, possibly more than one, if different versions
of the compiler were used.
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 14 '05 #13

P: n/a
> So, when an executable gets built, then there are two copies of C
library functions (one copy of functions used by kernel and other by
user/app level) !!
Yes. Otherwise, you would need to cross the kernel-user boundary for each
strlen(). This is a bad idea.
An app might end up using user level c functions but
dont you think this approach increases the executable size :-(


Usually such increase is not noticeable anyway.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma***@storagecraft.com
http://www.storagecraft.com
Nov 14 '05 #14

P: n/a

Ravi Uday wrote:
Dan Pop wrote:
In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes:
My guess is that there's only one implementation of the strlen()
function, and that it's callable either from the kernel or from usercode without crossing the user/kernel boundary. It's just a functioncall. The same is going to be true for a lot of other C library
functions.

Your guess is typically wrong: a kernel is a freestanding program
and it doesn't rely on any external library, not even the standard
C library. It defines all the standard C library functions it uses, which is OK for an application translated in freestanding mode.

So, when an executable gets built, then there are two copies of C
library functions (one copy of functions used by kernel and other by
user/app level) !! An app might end up using user level c functions

but dont you think this approach increases the executable size :-(
in the end ?

- Ravi


What executable? When you create your daily-day executables all it does
is interact with about 250 calls on Linux and around 1500(?) calls in
case of Windows environment. There isn't essentially a sort of thing
like there is a printf in user enviroment or user library and a printf
in Kernel. Both exist seperately for a very good reason.
As regards to increasing the size it is quite possible for your code to
directly call "strlen"[%] of kernel but there is a very good reason
this approach is not followed. Also, most executables now use shared C
libraries and since most programs in Linux, or at least the ones I use,
are command line printf is shared among all of these programs.
That said you make a very good point for micro-kernel based Operating
Systems.
[%] At least in Linux this could done by editing entry.S and couple of
other hacks.

--
Imanpreet Singh Arora

Nov 14 '05 #15

P: n/a
Very simply put.

The OS needs no C. and as such, niether is integrated with the other.

C compilers link low level code to interact with the OS.

In the "early days" most of this was done using the BIOS standard interface.
Wich exists without an OS. So you could develop an OS with C that does not
interact with any OS resources. Or you could say that the BIOS is an
integral componant of Every OS.

Keep them seperate in your mind. C is C, and OS is OS.
no integration.

Now, Before someone corrects me.
some OS's do have C compilers as an integral componant of that particular
OS. These are the exceptions, and some of the better OS's.

But C, will never, (dare I say never), integrate any particular OS.

"Minti" <im*******@gmail.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...

Ravi Uday wrote:
Dan Pop wrote:
> In <ln************@nuthaus.mib.org> Keith Thompson <ks***@mib.org> writes: >
>
>>My guess is that there's only one implementation of the strlen()
>>function, and that it's callable either from the kernel or from user >>code without crossing the user/kernel boundary. It's just a function >>call. The same is going to be true for a lot of other C library
>>functions.
>
>
> Your guess is typically wrong: a kernel is a freestanding program
> and it doesn't rely on any external library, not even the standard
> C library. It defines all the standard C library functions it uses, > which is OK for an application translated in freestanding mode.
>

So, when an executable gets built, then there are two copies of C
library functions (one copy of functions used by kernel and other by
user/app level) !! An app might end up using user level c functions

but
dont you think this approach increases the executable size :-(
in the end ?

- Ravi


What executable? When you create your daily-day executables all it does
is interact with about 250 calls on Linux and around 1500(?) calls in
case of Windows environment. There isn't essentially a sort of thing
like there is a printf in user enviroment or user library and a printf
in Kernel. Both exist seperately for a very good reason.
As regards to increasing the size it is quite possible for your code to
directly call "strlen"[%] of kernel but there is a very good reason
this approach is not followed. Also, most executables now use shared C
libraries and since most programs in Linux, or at least the ones I use,
are command line printf is shared among all of these programs.
That said you make a very good point for micro-kernel based Operating
Systems.
[%] At least in Linux this could done by editing entry.S and couple of
other hacks.

--
Imanpreet Singh Arora

Nov 14 '05 #16

P: n/a
In <1110263065.532104@sj-nntpcache-3> Ravi Uday <ra******@gmail.com> writes:


Dan Pop wrote:

Your guess is typically wrong: a kernel is a freestanding program
and it doesn't rely on any external library, not even the standard
C library. It defines all the standard C library functions it uses,
which is OK for an application translated in freestanding mode.
So, when an executable gets built, then there are two copies of C
library functions (one copy of functions used by kernel and other by
user/app level) !!


Nope. When an executable gets built, it contains at most one copy of
any given standard library function. With dynamic linking, it contains
no copy at all.
An app might end up using user level c functions but
dont you think this approach increases the executable size :-(
in the end ?


As long as applications don't contain the kernel code, I can't see how
the existence of two implementations of standard library functions
(one for kernel usage, one for hosted applications usage) is going to
affect the size of any application executable code.

OTOH, it is not uncommon for compilers to inline certain standard
library function calls. This does increase the executable size, but
it also accelerates the program execution.

Dan
--
Dan Pop <Da*****@ifh.de>
Nov 14 '05 #17

P: n/a


Dan Pop wrote:
In <1110263065.532104@sj-nntpcache-3> Ravi Uday <ra******@gmail.com> writes:
Dan Pop wrote:
Your guess is typically wrong: a kernel is a freestanding program
and it doesn't rely on any external library, not even the standard
C library. It defines all the standard C library functions it uses,
which is OK for an application translated in freestanding mode.


So, when an executable gets built, then there are two copies of C
library functions (one copy of functions used by kernel and other by
user/app level) !!

Nope. When an executable gets built, it contains at most one copy of
any given standard library function. With dynamic linking, it contains
no copy at all.


Well, that's not always true. A fairly common counter-
example is the inline expansion of some "simple" Standard
library functions like sqrt() or memcpy(). An implementation
that performs such inlining may generate an executable with
as many "copies" of sqrt() as there are calls to it -- and
perhaps yet another, to be called via a function pointer!

(Are these inline expansions "functions?" Probably not,
from the point of view of the hardware: they won't have the
argument marshalling, call-and-return, and so forth that are
associated with ordinary subroutines. But from the point of
view of the C Standard they most certainly are "functions;"
the inline expansions are merely an implementation detail,
and all the Standard's language about "the fmod() function"
still governs the behavior of the code.)

--
Er*********@sun.com

Nov 14 '05 #18

P: n/a
Dan Pop wrote:
.... snip ...
OTOH, it is not uncommon for compilers to inline certain standard
library function calls. This does increase the executable size,
but it also accelerates the program execution.


Welcome back. I trust nothing especially evil has happened to you
in the interim.

--
Chuck F (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!
Nov 14 '05 #19

P: n/a
In <d0**********@news1brm.Central.Sun.COM> Eric Sosman <er*********@sun.com> writes:


Dan Pop wrote:
In <1110263065.532104@sj-nntpcache-3> Ravi Uday <ra******@gmail.com> writes:
Dan Pop wrote:

Your guess is typically wrong: a kernel is a freestanding program
and it doesn't rely on any external library, not even the standard
C library. It defines all the standard C library functions it uses,
which is OK for an application translated in freestanding mode.
So, when an executable gets built, then there are two copies of C
library functions (one copy of functions used by kernel and other by
user/app level) !!

Nope. When an executable gets built, it contains at most one copy of
any given standard library function. With dynamic linking, it contains
no copy at all.


Well, that's not always true. A fairly common counter-
example is the inline expansion of some "simple" Standard
library functions like sqrt() or memcpy(). An implementation
that performs such inlining may generate an executable with
as many "copies" of sqrt() as there are calls to it -- and
perhaps yet another, to be called via a function pointer!


A possibility I have *explicitly* mentioned myself in the text you
have not included.

Dan
--
Dan Pop <Da*****@ifh.de>
Nov 14 '05 #20

P: n/a
Dan Pop wrote:
[I wrote; attribution lost]
Well, that's not always true. A fairly common counter-
example is the inline expansion of some "simple" Standard
library functions like sqrt() or memcpy(). An implementation
that performs such inlining may generate an executable with
as many "copies" of sqrt() as there are calls to it -- and
perhaps yet another, to be called via a function pointer!


A possibility I have *explicitly* mentioned myself in the text you
have not included.


Ah, the perils of speed reading! My apologies.

--
Eric Sosman
es*****@acm-dot-org.invalid
Nov 14 '05 #21

P: n/a
There two aspects to original question: dependencies and using C
runtime functions for OS kernel implementation.

I would say if you can layer OS components and RTL appropriately, you
are fine. That is for example one may have (lets say) spinlocks
dependant only on atomic functions from RTL, and later it's okay to use
spinlocks in (lets say) vsnprintf() set of functions which are part of
another RTL component. As long as dependencies are clear (in this
example it is not good to use vsnprinf() functions to debug spinlocks
component itself). It is totally possible to have an OS using just
minimal set of RTL components, or it is also possible to build more
complex system (but having well-defined architecture).

I would split the second question from the dependancy one: related to
C-language as a language which is used to implement OS'es Romeo
metioned. In my opinion second question has obvious answer: those OS'es
are implemented in C and therefore it is natural to use C runtime
functions (like sprintf) for the particular OS implementation. I would
imagine that Oberon OS (right?) uses Pascal standard output library for
output and this is totally fine.

Nov 14 '05 #22

P: n/a
> interact with any OS resources. Or you could say that the BIOS is an
integral componant of Every OS.


BIOS a) requires the obsolete CPU mode which does not support VM and is limited
in memory addressing b) is not multitask-enabled.

That's why nearly no OSes uses BIOS for now (except for boot). From what I
know, NT uses only video BIOS, and only some drivers, and only for monitor
power management (the videocard driver calls VideoPortInt10 when it sees the
suspend/resume request for a monitor device).

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma***@storagecraft.com
http://www.storagecraft.com
Nov 14 '05 #23

P: n/a
> Well, that's not always true. A fairly common counter-
example is the inline expansion of some "simple" Standard
library functions like sqrt() or memcpy().


MS's compiler has "intrinsic functions" which are inlined assembly
auto-generated by the compiler. memcpy() is one of them. You can switch this
off by #pragma or command-line flag.

I hope GCC also has this.

--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
ma***@storagecraft.com
http://www.storagecraft.com
Nov 14 '05 #24

P: n/a
Are you replying to me?

--
Imanpreet Singh Arora

Nov 14 '05 #25

P: n/a

Dan Pop wrote:
In <1110263065.532104@sj-nntpcache-3> Ravi Uday <ra******@gmail.com> writes:

Dan Pop wrote:

Your guess is typically wrong: a kernel is a freestanding program
and it doesn't rely on any external library, not even the standard
C library. It defines all the standard C library functions it uses, which is OK for an application translated in freestanding mode.
So, when an executable gets built, then there are two copies of C library functions (one copy of functions used by kernel and other by user/app level) !!


Nope. When an executable gets built, it contains at most one copy of
any given standard library function. With dynamic linking, it

contains no copy at all.
An app might end up using user level c functions but
dont you think this approach increases the executable size :-(
in the end ?
As long as applications don't contain the kernel code, I can't see

how the existence of two implementations of standard library functions
(one for kernel usage, one for hosted applications usage) is going to
affect the size of any application executable code.

OTOH, it is not uncommon for compilers to inline certain standard
library function calls. This does increase the executable size, but
it also accelerates the program execution.


Would the lord allow me to nitpick on the last sentence?
--
Imanpreet Singh Arora

Nov 14 '05 #26

P: n/a
On 12 Mar 2005 00:46:55 -0800, in comp.lang.c , "Minti" <im*******@gmail.com>
wrote:
Are you replying to me?


Is this a quote from Taxi Driver?
(perhaps you ought to remember that
a) usenet is not a chat room, anyone can post and
b) keeping some context in is useful)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 14 '05 #27

P: n/a


No this is not a quote from taxi driver, and whatever else you might be
thinking. BTW do you know any Operating Systems which have "C"
compilers as integral components of *any* Operating System.

--
Imanpreet Singh Arora
Damn top-posters.
-- A quote from taxi driver

Mark McIntyre wrote:
On 12 Mar 2005 00:46:55 -0800, in comp.lang.c , "Minti" <im*******@gmail.com> wrote:
Are you replying to me?
Is this a quote from Taxi Driver?

(perhaps you ought to remember that
a) usenet is not a chat room, anyone can post and
b) keeping some context in is useful)
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>


Nov 14 '05 #28

P: n/a
On 12 Mar 2005 19:31:01 -0800, in comp.lang.c , "Minti" <im*******@gmail.com>
wrote:


No this is not a quote from taxi driver,
It was very close tho: "you lookin' at me?"
and whatever else you might be thinking.
I was thinking that your post was utterly without context, adn your habit of
top-posting and putting a standard sig separator means its very hard to /reply/
to your posts with context. Please stop top-posting.
BTW do you know any Operating Systems which have "C"
compilers as integral components of *any* Operating System.


Yes.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Nov 14 '05 #29

P: n/a

Mark McIntyre wrote:
On 12 Mar 2005 19:31:01 -0800, in comp.lang.c , "Minti" <im*******@gmail.com> wrote:


No this is not a quote from taxi driver,
It was very close tho: "you lookin' at me?"
and whatever else you might be thinking.


I was thinking that your post was utterly without context, adn your

habit of top-posting and putting a standard sig separator means its very hard to /reply/ to your posts with context. Please stop top-posting.
Do you have anything else(better) to say? I have *never* and I repeat
*never* top-posted *except* and I repeat *except* to people who reply
either to me or to others. Seems like Joona Palaste has a better sense
of humour here.

BTW do you know any Operating Systems which have "C"
compilers as integral components of *any* Operating System.


Yes.

Saying *just* yes is as good as saying no. FWIW, the question was just
meant as a remark to you that even though this aint no IRC, one must
choose the person-to-reply with a bit of thought.

--
Imanpreet Singh Arora

PS We could go on all day and for that matter all night about this.From my end it Over and Out.


Nov 14 '05 #30

P: n/a
Minti wrote:
Mark McIntyre wrote:
"Minti" <im*******@gmail.com> wrote:

[top-posting]

Please stop top-posting.


Do you have anything else(better) to say? I have *never* and I repeat
*never* top-posted *except* and I repeat *except* to people who reply
either to me or to others.


Every message on Usenet is a reply to you or others !
(except for the start of a thread, which can't be a top-post).

How about you change your dogma to "I never top-post except
when it's appropriate". Your top-posting in this thread
was inappropriate.

Nov 14 '05 #31

P: n/a
On 13 Mar 2005 05:22:58 -0800, in comp.lang.c , "Minti" <im*******@gmail.com>
wrote:

Mark McIntyre wrote:
On 12 Mar 2005 19:31:01 -0800, in comp.lang.c , "Minti"<im*******@gmail.com>
wrote:
>No this is not a quote from taxi driver,


It was very close tho: "you lookin' at me?"
>and whatever else you might be thinking.


I was thinking that your post was utterly without context, adn your habit of
top-posting and putting a standard sig separator means its very hard to /reply/
to your posts with context. Please stop top-posting.


I have *never* and I repeat *never* top-posted


good. I stand corrected.
*except* and I repeat *except* to people who reply
either to me or to others.
So you only top post when replying? Eh?
Seems like Joona Palaste has a better sense
of humour here.
funnily enough, I thought my original comment to your inexplicable one-liner was
quite witty. YMMV, HAND etc
>BTW do you know any Operating Systems which have "C"
>compilers as integral components of *any* Operating System.
Yes.


Saying *just* yes is as good as saying no.


Do tell.
FWIW, the question was just
meant as a remark to you that even though this aint no IRC, one must
choose the person-to-reply with a bit of thought.


as was my reply.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.ungerhu.com/jxh/clc.welcome.txt>
Nov 14 '05 #32

P: n/a
On 12 Mar 2005 00:46:55 -0800, "Minti" <im*******@gmail.com> wrote:
Are you replying to me?


Could be. Who are you talking to, and about what?

--
Al Balmer
Balmer Consulting
re************************@att.net
Nov 14 '05 #33

P: n/a

Old Wolf wrote:
Minti wrote:
Mark McIntyre wrote:
"Minti" <im*******@gmail.com> wrote:
>
> [top-posting]
>
Please stop top-posting.
Do you have anything else(better) to say? I have *never* and I repeat *never* top-posted *except* and I repeat *except* to people who reply either to me or to others.


Every message on Usenet is a reply to you or others !
(except for the start of a thread, which can't be a top-post).


Oooooooops. Is there a bathroom nearby?

How about you change your dogma to "I never top-post except
when it's appropriate". Your top-posting in this thread
was inappropriate.

Why are we even talking about this? Go through the entire thread again,
read each post at least 153 times. "DhollingsWorth2", first topposted
me, not to mention that the reply looked ( a bit ) irrelevent[%%].
Compare, what I had said and what "DhollingsWorth2" said. If you find
them relevant, good "You are smartass and I am an asshole". If that is
what you and Mark wanted to hear.
--
Imanpreet Singh Arora

[%%] To me at least.

Nov 14 '05 #34

P: n/a
"Minti" <im*******@gmail.com> writes:
Old Wolf wrote:
How about you change your dogma to "I never top-post except
when it's appropriate". Your top-posting in this thread
was inappropriate.

Why are we even talking about this? Go through the entire thread again,
read each post at least 153 times. "DhollingsWorth2", first topposted
me, not to mention that the reply looked ( a bit ) irrelevent[%%].
Compare, what I had said and what "DhollingsWorth2" said. If you find
them relevant, good "You are smartass and I am an asshole". If that is
what you and Mark wanted to hear.


What on Earth are you talking about? This isn't about DhollingsWorth2
(who has been criticized here at length for various things). It's
about you top-posting and then making excuses for it.

I'm glad to see that you're not top-posting now. If you want to drop
this, then drop it.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #35

P: n/a

Keith Thompson wrote:
"Minti" <im*******@gmail.com> writes:
Old Wolf wrote:
How about you change your dogma to "I never top-post except
when it's appropriate". Your top-posting in this thread
was inappropriate.

Why are we even talking about this? Go through the entire thread again, read each post at least 153 times. "DhollingsWorth2", first topposted me, not to mention that the reply looked ( a bit ) irrelevent[%%].
Compare, what I had said and what "DhollingsWorth2" said. If you find them relevant, good "You are smartass and I am an asshole". If that is what you and Mark wanted to hear.


What on Earth are you talking about? This isn't about

DhollingsWorth2 (who has been criticized here at length for various things). It's
about you top-posting and then making excuses for it.

I'm glad to see that you're not top-posting now. If you want to drop
this, then drop it.


Keith, I earnestly apologise, but I think _nobody_ has understood
"What-the-Hell" I am trying to SAY.

In simple words.

"If somebody top-posts ME, I will without thought, without
consideration, without shame, top-post him back."
If anybody considers it to be an excuse, so be it. I consider it to be
a way of life.

--
Imanpreet Singh Arora

Nov 14 '05 #36

P: n/a
Minti wrote:
.... snip ...
In simple words.

"If somebody top-posts ME, I will without thought, without
consideration, without shame, top-post him back."

If anybody considers it to be an excuse, so be it. I consider it
to be a way of life.


This is not e-mail. If you wish to reply to an individual you can
do so with e-mail, top-post as you wish, and not annoy anybody
else.

Usenet is a public place, and articles are for all. Top-posting is
rude and foolish. If you do it automatically you are simply being
rude to the great majority. Get in the habit of correcting
top-posting, and you may start to contribute something. If you are
not willing to do this, don't bother with a reply in the newsgroup.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson
Nov 14 '05 #37

P: n/a
"Minti" <im*******@gmail.com> writes:
Keith Thompson wrote:

[...]
What on Earth are you talking about? This isn't about
DhollingsWorth2 (who has been criticized here at length for various
things). It's about you top-posting and then making excuses for
it.

I'm glad to see that you're not top-posting now. If you want to drop
this, then drop it.


Keith, I earnestly apologise, but I think _nobody_ has understood
"What-the-Hell" I am trying to SAY.

In simple words.

"If somebody top-posts ME, I will without thought, without
consideration, without shame, top-post him back."
If anybody considers it to be an excuse, so be it. I consider it to be
a way of life.


Ok, now I understand what you're trying to say. It's wrong, but I
understand it.

Nobody can "top-post you", and you cannot "top-post him back".

This is a newsgroup, not e-mail. Everything you write here will be
read by many people, not just by the person who wrote the article to
which you happen to be posting a followup. Top-posting is not
acceptable here under any circumstances.

By top-posting, you are being rude to all of us; whether the previous
poster top-posted is not at all relevant. Both of you will be flamed,
and we couldn't care less who started it.

When we post a followup to a top-posted article, we usually correct
the top-posting by rearranging the quoted text (and ask the poster not
to top-post). If you don't want to take the time to do that, just
don't post a followup (or snip the nested quotations if doing so
leaves enough context). If you want to have a private conversation,
with your text formatted any way you like, use e-mail. If you want to
post to this newsgroup, please follow the conventions we use here.

Once again, top-posting in comp.lang.c is *never* acceptable,
regardless of what anyone else has done, regardless of whom or what
you're replying to.

(I don't mean to imply that top-posting is some horrible crime. A
single instance is often the result of excusable, and curable,
ignorance; persistent top-posting is rude, but the punishment won't
exceed flaming and possible kill-filing.)

Now do you understand?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #38

P: n/a

Keith Thompson wrote:
"Minti" <im*******@gmail.com> writes:
Keith Thompson wrote: [...]
What on Earth are you talking about? This isn't about
DhollingsWorth2 (who has been criticized here at length for various things). It's about you top-posting and then making excuses for
it.

I'm glad to see that you're not top-posting now. If you want to drop this, then drop it.


Keith, I earnestly apologise, but I think _nobody_ has understood
"What-the-Hell" I am trying to SAY.

In simple words.

"If somebody top-posts ME, I will without thought, without
consideration, without shame, top-post him back."
If anybody considers it to be an excuse, so be it. I consider it to be a way of life.


Ok, now I understand what you're trying to say. It's wrong, but I
understand it.

Nobody can "top-post you", and you cannot "top-post him back".

This is a newsgroup, not e-mail. Everything you write here will be
read by many people, not just by the person who wrote the article to
which you happen to be posting a followup. Top-posting is not
acceptable here under any circumstances.


Thanks.
By top-posting, you are being rude to all of us; whether the previous
poster top-posted is not at all relevant. Both of you will be flamed, and we couldn't care less who started it.

When we post a followup to a top-posted article, we usually correct
the top-posting by rearranging the quoted text (and ask the poster not to top-post). If you don't want to take the time to do that, just
don't post a followup (or snip the nested quotations if doing so
leaves enough context). If you want to have a private conversation,
with your text formatted any way you like, use e-mail. If you want to post to this newsgroup, please follow the conventions we use here.

Once again, top-posting in comp.lang.c is *never* acceptable,
regardless of what anyone else has done, regardless of whom or what
you're replying to.

(I don't mean to imply that top-posting is some horrible crime. A
single instance is often the result of excusable, and curable,
ignorance; persistent top-posting is rude, but the punishment won't
exceed flaming and possible kill-filing.)

Now do you understand?


I think I do. BTW, I never meant to be rude with you or anybody else. I
earnestly apologize if I did end up.

Nov 14 '05 #39

P: n/a
"Minti" <im*******@gmail.com> wrote:
Keith Thompson wrote:
I'm glad to see that you're not top-posting now. If you want to drop
this, then drop it.
Keith, I earnestly apologise, but I think _nobody_ has understood
"What-the-Hell" I am trying to SAY.


Oh, I think we've all understood quite clearly:
I will without thought,


Says it all, really.

Richard
Nov 14 '05 #40

P: n/a
"Minti" <im*******@gmail.com> writes:
Keith Thompson wrote:

[...]
Now do you understand?


I think I do. BTW, I never meant to be rude with you or anybody else. I
earnestly apologize if I did end up.


Apology accepted.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #41

P: n/a
Minti wrote:
Dan Pop wrote:

OTOH, it is not uncommon for compilers to inline certain standard
library function calls. This does increase the executable size, but
it also accelerates the program execution.
Would the lord allow me to nitpick on the last sentence?


Speaking on His/Her behalf, I give you permission
to do so.
Dan Pop: Please make sure you include something
like "sometimes" or "may or may not" when you talk
about things like inlining function calls.
Jonathan
Nov 14 '05 #42

P: n/a

Jonathan Mcdougall wrote:
Minti wrote:
Dan Pop wrote:

OTOH, it is not uncommon for compilers to inline certain standard
library function calls. This does increase the executable size, butit also accelerates the program execution.

Would the lord allow me to nitpick on the last sentence?


Speaking on His/Her behalf, I give you permission
to do so.


The lord seemeth to be busy or maybe just a bit arrogant :-).

<snip>

--
Imanpreet Singh Arora

Nov 14 '05 #43

P: n/a

Richard Bos wrote:
"Minti" <im*******@gmail.com> wrote:
Keith Thompson wrote:
I'm glad to see that you're not top-posting now. If you want to drop this, then drop it.
Keith, I earnestly apologise, but I think _nobody_ has understood
"What-the-Hell" I am trying to SAY.


Oh, I think we've all understood quite clearly:


Indeed. I appreciate that.
I will without thought,


Says it all, really.


Yup it does. Though just replace "top-post for top-post for top-post"
with "bullet-for-bullet."
Anwyay I have apologized twice for this so I don't see your point.
Moreso the flame DID NOT start with Mark commenting me on top-posting.
He just mentioned that one should not not assume that the reply is
directly aimed at one's own post. It WAS I who mentioned the toppost.
And if you look ( did you? ) at that post I KNOWINGLY added a signature
with "Damn Top Posters". Why do you think I wrote that?

So who is posting without thought now?

Because I respect a lot of guys here, I have already said that I won't
be top-posting even if someone top-posts me. Why is that such a simple
reply is made a issue here? Why can't you just resist the tempation to
post?

HTH
--
Imanpreet Singh Arora

Nov 14 '05 #44

P: n/a
Minti wrote:
.... snip a lot of childish nonsense ...
Because I respect a lot of guys here, I have already said that I
won't be top-posting even if someone top-posts me. Why is that
such a simple reply is made a issue here? Why can't you just
resist the tempation to post?


Why are you insisting on having the last word? Go and sin no more.

--
"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare
Nov 14 '05 #45

P: n/a
"Minti" <im*******@gmail.com> writes:
[...]
Because I respect a lot of guys here, I have already said that I won't
be top-posting even if someone top-posts me. Why is that such a simple
reply is made a issue here? Why can't you just resist the tempation to
post?


Usenet is an asychronous medium. If multiple people post a followup,
it may be because they haven't seen each other's posts.

You've apologized. I advise you to drop it and move on, unless
there's actually something new to say (which seems unlikely).

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #46

P: n/a

CBFalconer wrote:
Minti wrote:

... snip a lot of childish nonsense ...


Yeah well sort of but just when I start to avoid these posts someone
just pops up ;-).

Because I respect a lot of guys here, I have already said that I
won't be top-posting even if someone top-posts me. Why is that
such a simple reply is made a issue here? Why can't you just
resist the tempation to post?


Why are you insisting on having the last word?


How can I NOT? I have got to reply to these polite questions? ;-).
Don't tell me you have also joined the forces of evil. (-:
--
Imanpreet Singh Arora

Nov 14 '05 #47

P: n/a
"Minti" <im*******@gmail.com> writes:
CBFalconer wrote:

[...]
Why are you insisting on having the last word?


How can I NOT?


By not posting. Really.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
Nov 14 '05 #48

P: n/a
Minti wrote:

The very important point that favors C being used in Operating Systems is that no other compiler-for-language-other-than-c has been able to
been able to beat code-generated-by-c-compilers.
"Beat" it how? Convenience, size, speed, ubiquity, or what? There are
certainly cases where another compiler will generate a smaller and/or
faster executable than any of the C compilers available on that
platform, or for that architecture. Highly parallel machines are a
likely case, but there are others. Some architectures are rather
C-hostile, having for instance no user stack or no indirect addressing.
I believe I've heard that the system programming language on CDC
mainframes was (at least at one time) FORTRAN, to the extent that no
assembler was provided. (Or perhaps it was ALGOL. Not C, in any
case.)
It is very much
possible to write an Operating System within a programming language
like Java, with a pinch of salt actually, and then generating the
native code for a platform like i386, again with a pinch of salt. There is at least one Operating System Project that attempts to do so.


What's this "salt" you refer to? And when you say "a programming
language like Java", what Java-like characteristic are you referring
to? A bytecoded, interpreted language? An OO language? A declarative
language? A strongly-checked language? And what's special about
i386's?

OS's have been written in many languages, but you usually require at
least some assembly language unless there's already at least some sort
of bootstrap on the platform, and usually some low-level device
drivers.
Not specifically to Minti:

Of course, nobody's even referenced an explicit definition of
"Operating System" in this entire thread, as far as I can see. (There
were references to the kernal plus other parts.) Some of the
disagreement appears to be due to different, unstated definitions.

Nov 14 '05 #49

P: n/a

gtippery wrote:
Minti wrote:

The very important point that favors C being used in Operating Systems
is that no other compiler-for-language-other-than-c has been able to been able to beat code-generated-by-c-compilers.


"Beat" it how? Convenience, size, speed, ubiquity, or what? There

are certainly cases where another compiler will generate a smaller and/or
faster executable than any of the C compilers available on that
platform, or for that architecture. Highly parallel machines are a
likely case, but there are others.
Yup, but how many Operating System developers seem to be convinced with
this argument?

Some architectures are rather
C-hostile, having for instance no user stack or no indirect addressing.

How many of these are in _common_ and _popular_ usage? (*)
I believe I've heard that the system programming language on CDC
mainframes was (at least at one time) FORTRAN, to the extent that no
assembler was provided. (Or perhaps it was ALGOL. Not C, in any
case.)
Read (*).
It is very much
possible to write an Operating System within a programming language
like Java, with a pinch of salt actually, and then generating the
native code for a platform like i386, again with a pinch of salt.

There
is at least one Operating System Project that attempts to do so.


What's this "salt" you refer to?


Have you read about projects like Jalapeno? Though Jalapeno[%] is a
Virtual Machine implemented (totally) in Java, the developers had to
use several hacks like storing references of several different objects
in a single array.

[%] http://jikesrvm.sourceforge.net/
And when you say "a programming
language like Java", what Java-like characteristic are you referring
to? A bytecoded, interpreted language? An OO language? A declarative language? A strongly-checked language? And what's special about
i386's?

Is Java a declarative language? And what's so special about i386's? ask
yourself.

OS's have been written in many languages, but you usually require at
least some assembly language unless there's already at least some sort of bootstrap on the platform, and usually some low-level device
drivers.


In as sense YES! But only if it were just _writing_ an Operating
System. _Usability_ _Efficiency_ _Speed_ are just some of the arguments
that need to be satisfied.

Followups set to alt.os.development

--
Imanpreet Singh Arora

Nov 14 '05 #50

50 Replies

This discussion thread is closed

Replies have been disabled for this discussion.