OSDev.org

For me, the main argument not to use C as the base for most of a kernel is because C cannot effciently handle the requirements of my OS-kernel, which include effective segment protection combined with effective page-protection schemes. C does have a place in more complex device-drivers for filesystems and ACPI.

Even if I have been able to use a very particular memory-model of OpenWatcom, that does seem to work for complex device-drivers, it is generally unsuitable for simpler tasks as the overhead is too large. The best thing with the memory model is that protection schemes can be gradually relaxed as the device-driver is getting mature. I do this by either allocating one selector per memory-request, with zero base, or by allocating a linear address, and casting it to a far pointer with a flat selector. This is what I would want to do for applications as well some day. The only problem is that they must use the 32-bit compact memory model with DS always refering to DGROUP. That requires a new executable format.

Of course, GCC can do none of this.

rdos wrote:I think you are the one providing misinformation now. (...) The startup also must setup a stack

Hypocrite alert.

I said it before, but it apparently needs repeating: do not mix toolchains and their requirements with how your kernel is designed. Most of us have better designs by the very definition of the word opinion, including ones where absolutely none of your assumptions hold.

Combuster wrote:I said it before, but it apparently needs repeating: do not mix toolchains and their requirements with how your kernel is designed. Most of us have better designs by the very definition of the word opinion, including ones where absolutely none of your assumptions hold.

I have no toolchain requirements, and thus am free to do whatever is best for my kernel.

In fact, only adaptable toolchains could be used for building device-drivers, and that does not include most C/C++ compilers. I set the standards, and if the toolchain cannot adapt, it is out.

Solar wrote:No professional will ever recommend writing a project this size completely in assembler.

I'm a professional, and I recommend it.

rdos wrote:The whole idea about making an OS is to make everything that boots-up your PC yourself. When you base your design on an existing GCC compiler, and it's runtime library, you have a solution that is only partly your own.

Yeah, I absolutely agree: There are people who think that you should use an existing bootloader. But just like leaving out the development of your own BIOS, this is not really doing things yourself.

I'm glad to find someone in you who really does things properly and builds everything from scratch. Just wondering: How long did it take you to build your PC-compatible computer? And I surely hope that you've got your own copper mine so that you didn't have to rely on other people's work?

rdos wrote:

Solar wrote:No professional will ever recommend writing a project this size completely in assembler.

I'm a professional, and I recommend it.

There is a certain truth in the above, if you are willing to find it.

BTW: Your toolchain requirements are that your toolchain must support segmented addressing. That is a requirement.

But that is neither here nor there. It is policy of this board to recommend a GCC cross-compiler toolchain as well as C - and possibly C++ - as development language, unless the poster has stated specific requirements (and possibly backed them up with some reasoning, other than "I don't know C/C++", which in turn is a bad sign as to the qualification of the poster regarding OS development in general). It is consensus that this is the all-around easiest way to go. Wikipedia would call your posts a "minority view", and make sure that it does not get "undue weight in the article". We do something similar.

I hereby invoke forum rule 8.

rdos wrote:I'm a professional

No, you're incapable enough that you deliberately ignore security in payment terminals.

Kevin wrote:I'm glad to find someone in you who really does things properly and builds everything from scratch. Just wondering: How long did it take you to build your PC-compatible computer? And I surely hope that you've got your own copper mine so that you didn't have to rely on other people's work?

Hmm, no, but I've:
1. Built complete computers with integrated chips
2. Written my own BIOS-replacement for a specific system
3. Built CPU-elements with discrete ICs

The only thing I've not done is to build ICs. Would be fun to do, but I've not yet done that.

I do not think C is a good OS-Developing language. My reasoning is that I am unable to understand and comprehend the system as a whole in it. I am much more in tune with objects and the stage metaphor way of thinking.

"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. Hoare

@ rdos: It looks like you have many folks against you. I guess they have their reasons. Hang in there buddy .

I'm glad to find someone in you who really does things properly and builds everything from scratch. Just wondering: How long did it take you to build your PC-compatible computer? And I surely hope that you've got your own copper mine so that you didn't have to rely on other people's work?

@ Kevin quote:
The truth is it takes more than one men to start mining copper and enormous cooperation from others who are willing to participate. Like wise OSdev is similiar in many ways. Bill Gates, Linus Benedict Torvalds, Steve Jobs didn't do it alone.

Is C a good OS-Developing language?

Since I am new to OSdev I'll leave that question to get answered by the experts .

Is C a good OS-Developing language?

It definitely is. Even rdos won't argue on the usability of C(Note that we're arguing on a good OS-development language not on the best one). I am still well aware that there are well defined reasons to choose another programming language over C. I've no problem with people writing codes on assembly or even directly on machine code. You got to chose the language you're good at and of which you can grasp the better coding logic. Even C programmers tend to rely on assembly for lower level stuffs.

But again, I'd recommend C because I've dozens of good reasons for it. If I start listing them, it would trigger yet another C Vs Assembly arguments, so I better not.

Jvac wrote:@ rdos: It looks like you have many folks against you. I guess they have their reasons. Hang in there buddy .

Several of them are just jealous because I have an OS in production state and they don't

rdos wrote:In fact, only adaptable toolchains could be used for building device-drivers, and that does not include most C/C++ compilers.

This seems a little extreme. While assembly language would be needed for doing certain things in device drivers, the sheer number of device drivers written purely in C/C++ which already exist indicates a flaw in this.

It might be reasonable, however, to say that a standard C toolchain would not be usable for device drivers in a context where segmentation is important. This is quite a different statement.

SDS wrote:This seems a little extreme. While assembly language would be needed for doing certain things in device drivers, the sheer number of device drivers written purely in C/C++ which already exist indicates a flaw in this.

It might be reasonable, however, to say that a standard C toolchain would not be usable for device drivers in a context where segmentation is important. This is quite a different statement.

You need a perspective on this. RDOS was designed at the time when 286-processors were common, and the 386 processor was brand new (at least on the market). It was 1988. There were no toolchains at all that supported the 386-processor, and no affordable compilers that produced code for 386. GCC was not invented. Bochs was not invented. Linux was not invented. There was an assembler (MASM) that produced 32-bit code. RDOS was designed based on these premises, and because there existed no open "reference" systems, rather only the Intel processor docs, the OS design-decisions were never burdened with toolchain peculiarities. The tools needed were instead developped, like a way to "link" device-drivers, a way to build an image file and a useful memory model for an assembly-only project.

rdos wrote:You need a perspective on this. RDOS was designed at the time when 286-processors were common, and the 386 processor was brand new (at least on the market). It was 1988. There were no toolchains at all that supported the 386-processor, and no affordable compilers that produced code for 386. GCC was not invented.

Not challenging either your claim or your achievement, but it should be pointed out for historical precision that the first release of GCC was published in March 1987.

@ rdos, no one is saying that your OS isn't a good piece of work in its own right. But one cannot help but get the impression that your involvement with that 1988-born project has got you stuck in time. Back then, building your own toolchain for your project was an act of necessity. Today it's an act of stupidity, period.