32 bit
alex
Jon Morton
> yep
So, 32-bits might be fine to develop today, if you can easily convert
the code to 64-bits. I've made a start on
that - I've got a basic GUI debugger that talks to bochs, but so far
it still only operates at the assembler level.
Although its possible to write a kernel completely in C its been
done several times obviously, is it really idea
l? Also, it had OpenWatcom support for Windows, but not DOS.
Rod Pemberton
news:149b0a8c-fe7f-4c2c...@v4g2000yqa.googlegroups.com...
> Although its possible to write a kernel completely in C its been
> done several times obviously, is it really ideal?
Well, I prefer C...
First, C from my perspective. The special instructions for setting up the
CPU must be done in assembly, or usually as inlined assembly in C.
Interrupt routines need some assembly "wrappers" to work with C. But, other
than that, everything else can be done in C. C, although not as portable as
those on comp.lang.c would like you to believe, is more portable than
assembly. If your C compiler supports different code sizes, say 16-bit,
32-bit, 64-bit, you just recompile the C. The inlined assembly will need to
be adjusted for the mode, which can be wrapped in a mode appropriate #ifdef
using the compiler's define for that mode. The problems with C are that
while there are many areas of the C library that are independent of the
underlying host OSes functions and interrupts, much of the C library, if
customized for the host OS, is dependent on the host OS. So, you have to be
careful what you use, or you have write your own library. (I've posted a
few times on specific's of this. I'll post a link if you want.) Some
compilers have switches to disable library use. And, C, of course, while C
supports signals, it doesn't support cpu interrupts, so you have to use
workarounds such as assembly wrappers.
Second, assembly from my perspective. The main problem with assembly is
that it has to be entirely rewritten when going from 16-bits to 32-bits, or
32-bits to 64-bits, or from a machine using one cpu, say x86, to another,
say ARM. That's alot of code to convert. You could write all your assembly
is using macro's avoiding nearly all cpu instructions except for the bare
minimum, i.e., say 10 to 32 instructions. This minimal subset of
instructions would then need to be adjusted for each platform, but the
macro's could remain the same as long as the macro processor is available on
each platform. The secondary issues with assembly are a lack of a variable
system and type system. While I'm not especially fond of C's type system, I
prefer the more generic integer as everything of assembly, C's type system
does catch errors. But, my personal "pet peave" with assembly is that I
can't track variables by name. If I name the variable, it has to be in
memory, but I may need to move it around to a register, to the stack, etc.
at which point, you can't use whatever name the assembler allowed you to use
for the memory label. There is no way to reassign that variable name to the
register or stack location. Another issue is optimization and efficient use
of registers. Humans just aren't as good as compilers for most general
programming. When I program in assembly, I end up with heavy register
usage. Or, I end up with registers dedicated to certain tasks. This isn't
anywhere near as optimal as gcc -O2 or wcl386 -otexan etc.
Rod Pemberton
chiky
wrote:
>The problems with C are that
> while there are many areas of the C library that are independent of the
> underlying host OSes functions and interrupts, much of the C library, if
> customized for the host OS, is dependent on the host OS. So, you have to be
> careful what you use, or you have write your own library. (I've posted a
> few times on specific's of this. I'll post a link if you want.) Some
> compilers have switches to disable library use. And, C, of course, while C
> supports signals, it doesn't support cpu interrupts, so you have to use
> workarounds such as assembly wrappers.
Hey Rod,
Can you please post the links that you mentioned above. Actually, i
had the same question for sometime that i wanted to ask: why cant we
use the standard C library for kernel development? Well, the obvious
answer that came to my mind was OS dependence, but you mentioned some
independent areas of C library. I would like to know about these too.
Functions that can be used for kernel development.
Regards
Chirag
Alexei A. Frounze
memcpy() and sprintf(), for example. Look around for many more.
Basically, everything that doesn't do I/O or depend on the other OS
functionality (e.g. memory allocation) or configuration (on e.g. time,
locale) can be used.
Alex
t
news:23a10bf1-66e7-4da5...@w39g2000prb.googlegroups.com...
On Dec 11, 12:06 am, "Rod Pemberton" <do_not_h...@nohavenot.cmm>
wrote:
> >The problems with C are that
> > while there are many areas of the C library that are independent of the
> > underlying host OSes functions and interrupts, much of the C library, if
> > customized for the host OS, is dependent on the host OS. So, you have to
be
> > careful what you use, or you have write your own library. (I've posted a
> > few times on specific's of this. I'll post a link if you want.) Some
> > compilers have switches to disable library use. And, C, of course, while
C
> > supports signals, it doesn't support cpu interrupts, so you have to use
> > workarounds such as assembly wrappers.
>
>
http://groups.google.com/group/alt.lang.asm/msg/4a7c8abd09d6fe6d?hl=en
http://groups.google.com/group/alt.os.development/msg/5ce9e335f5e139b7?hl=en
The para that starts "For C, the main compiler..." in the second one. That
post doesn't emphasize the fact that some functions you might think are free
of file I/O aren't, e.g., printf().
Most C libraries are built up from a small set of OS functions. I've listed
the quantity used for various C libraries, OSes, and FORTH's in these posts.
I also listed the low level functions needed for various FORTH's and LISP's,
but I didn't list the low level functions used by C libraries. I'll list a
few below.
http://groups.google.com/group/comp.lang.forth/msg/10872cb68edcb526?hl=en
http://groups.google.com/group/comp.lang.c/msg/13a6ef81e8b85e0d?hl=en
K&R C, e.g., PDP-7 and/or PDP-11 UNIX C libraries were built these:
open, close, read, write, creat, link, fork, exec, wait, exit, lseek, pipe
PJ Plauger's "Standard C Library" book
clock, close, environ, execl, exit, fork, getpid, kill, link, lseek, open,
read, sbrk, signal, time, unlink, wait, write
Redhat's newlib
close, environ, _exit, execve, for, fstat, getpid, isatty, kill, link,
lseek, open, read, sbrk, stat, times, unlink, wait, write
Of course, this all refers to C, *not* C++. Supposedly, C++'s low-level
memory allocator is OS dependent which means you have to write your own new
(?) and free (?) routines.
> Can you please post the links that you mentioned above. Actually, i
> had the same question for sometime that i wanted to ask: why cant we
> use the standard C library for kernel development?
You can. If the function is OS independent, you use it as is. If the
function is OS dependent, you'll have to write replacement routines for the
OS functions that function calls. Or, you can write your own libraries.
Or, you can use OS libraries like:
http://oslib.sourceforge.net/
http://www.cs.utah.edu/flux/oskit
> Well, the obvious
> answer that came to my mind was OS dependence, but you mentioned some
> independent areas of C library.
It all depends on how customized the C library is to the OS and how much the
OS controls. In general, much (~60%), but not all, of the C library should
be independent of the host OS. The C spec. basically requires some stuff to
be independent. The architecture of computing platforms has standardized
since the mid '70's which helps C "portability".
Rod Pemberton