Should my Kernel be written in C or C++?

[Anton]

>Assembler is at the lowest possible level of abstraction because it does no
>hw abstraction while C and C++ are usually referred to as high-level
>languages because they are in themselves abstractions. With C and C++ your
>control of the machine is not as comprehensive as with assembler exactly
>because you are working at a higher level of abstraction. C and C++ do not
>give you absolute control of every single detail and therefore they also do
>not give you explicit control over those details.

For me C and C++ are high-level asm languges, since i know exactly how the program will look, when translated to asm. (For me a real high-level language is Java, SML, Refal, Lisp, ... )

>In an assembly OS? By directly manipulating relevant hardware state without
>any extra abstraction/indirection/protection layers. Protection is necessary
>but that could be guaranteed without assembly programmer hindering
>abstractions or indirections.

So, this means that you ever have a one man project,where every line of code(even in applications, if there is such a thing in you os) will be written by you. And you garanty protection between your programs=>no data will be lost of hdd or in memory, no corrupt screen, ...
Ever you are trying to make a unstable(without protection) os, since if at least one program(application) will be faulty, it will bring the whole system down?
Abstaction is used, not because programers wont to make there os complex and unyielding, but because it is a necessity, if you whant alot of programers to take part, and if you whant portability(at least some), and if you whant reusable code, .. . Abstaction is used to cooperate the work of programs ran together=>does this mean that your os does not have multitasking, paging & virtual memory(since any program which need some pages, allocates them by it self), you can't run untrusted applications => and therefore you have a stand alone program?

So, "hello world" program will be writen like this(for PC compatible-notice this, in an os with a HAL, you don't need to say this)
uint8 *buffer=(char*)0xb8000;//uint8 ~ unsigned char
buffer[0]='H';buffer[2]='e';buffer[4]='l';buffer[6]='l';...

Let me ask an even tougher question. Say you have an application which works with a com port(COM1-COM4) (say a modem), and now we install a usb-com adapter. Now
1)Could you say what steps will you need to take, to make that application work with this adapter?
2)Will you have two seperate programs for the com1 and for the usb-com adapter, or what ...?(remember decided not to have a HAL ) ?
Anton.

Anton

[ezanahka]

True, especially because at least Java and some Lisps compile byte-code instead of native. That is definitely high-level...

Of course if something can go wrong it usually will. I know that. The exokernel papers at MIT explain pretty well what I mean. And I di know that unprotected OSes have their own problems. That is why I will try to avoid ever making one.

Look at
http://www.pdos.lcs.mit.edu/pubs.html
and you'll find stuff about exokernels which is more like what I'm trying to do. I'm definitely not writing another DOS.

I do know the value and necessity of abstraction. I create abstractions and generic code even with assembly. However unnecessary or badly made abstractions suck and basically usually only create more problems than what they solve. These problems are discussed and explained quite well at (which is definitely worth a look for everyone interested in programming and software engineering)

http://www2.parc.com/csl/groups/sda/default.shtml

Yes, abstraction is needed but I don't have to put every single abstraction in the kernel. It is possible to put for example the filesystem related things into shared libraries and include only filesystem independent protection of disk data into the kernel (exactly what I'm planning to do).

I will have multitasking, paging, virtual memory as those are services implemented mainly in the hardware and therefore I don't have to abstract them. I will simply make a secure interface for them between the kernel and applications...

I will have a HAL (kind of and mainly because I need that in order to protect the resource) but it will be as low-level as possible.

And about the "hello world!" program... yes, that is how it would be done IF you don't want to use the abstractions that will be available in libraries that you can link to your application. I will make or port a C compiler to my system eventually. Remember that I said that asm programming will not be necessary in my system but it will be possible in my system (and you will be able to bypass many more abstractions than in most OSes but not protection). One thing was missing from your example though... requesting the screen from the kernel and then releasing it when done.

1) and 2) are solved by using object-oriented technologies. If possible I want to have a meta-object protocol and aspect-oriented programming supporting HLL for my system for application programming... Also I should mention that my system also will resemble a customisable OS because the kernel will be customisable by the root user at runtime. And BTW the kernel's core interpreter is probably the only thing I'm gonna write in asm (will be about 2-4 KBs in size). Everything else is written with the Forth-like interpreter that is the core of the kernel...

No, I did not decide to not have a HAL. I simply decided to have as little HAL as possible because every abstraction is not the best possible abstraction for every application...