Making OSes without assembly.

[JamesM]

I don't think that C/C++ belongs in a OS kernel. If you can write code in C with no assembly, chances are the code does not belong in the kernel.

I have no C-code in my kernel. I have some plans for a C/C++ interface using Open Watcom for writing some complex filesystem drivers, but other than that, the need does not seem to exist. At least not for an experienced assembly-programmer.

I think you are wrong. Compilers are good enough now that for 90% of the assembly you write, a C compiler will beat you on speed. The only times when you will beat it are with a very tightly optimised loop that its register allocator can't deal with well (i.e., compilers are optimised for the general case, not the specific case).

Not only that, but C/C++ code is *far* easier to maintain and debug than assembly code, scales better and is easier for an outsider to grok.

In essence, you're wrong on all counts. It's not the 1970's any more.

[gerryg400]

I don't think that C/C++ belongs in a OS kernel. If you can write code in C with no assembly, chances are the code does not belong in the kernel.

I have no C-code in my kernel. I have some plans for a C/C++ interface using Open Watcom for writing some complex filesystem drivers, but other than that, the need does not seem to exist. At least not for an experienced assembly-programmer.

I'm curious about why you would choose assembly language. There are many considerations when choosing a language. Of them, only 2 (possibly speed and possibly code size) would favour assembly. In all other ways that I can think off, c looks a better choice.

[rdos]

I think you are wrong. Compilers are good enough now that for 90% of the assembly you write, a C compiler will beat you on speed. The only times when you will beat it are with a very tightly optimised loop that its register allocator can't deal with well (i.e., compilers are optimised for the general case, not the specific case).

Most compilers cannot handle mixed-mode segmentation, which is the primary reason why I've this far only used assembly. However, the Open Watcom compiler has support for old OS/2 mixed-mode segmentation, which makes it possible to generate this with a high-level compiler.

So, it is not only a speed issue, it is also a protection issue. I use segmentation to isolate drivers from each others, and from userlevel code, and most C compilers does a lousy job on generating code like that, if they can do it at all. If you use software-protection instead, there will be lots of validation code that I don't need that will slow down the system.

Not only that, but C/C++ code is *far* easier to maintain and debug than assembly code, scales better and is easier for an outsider to grok.

It is definitely easier to maintain (no question about that), but in regards to easy debugging, flat memory model kernels are a night-mare to debug (regardless of language used).

In essence, you're wrong on all counts. It's not the 1970's any more.

I forgot the most important reason. It is far more fun to code in assembly than in C. And don't forget the challenge in writing an assembly-only kernel.

[rdos]

I'm curious about why you would choose assembly language. There are many considerations when choosing a language. Of them, only 2 (possibly speed and possibly code size) would favour assembly. In all other ways that I can think off, c looks a better choice.

Its for historical reasons. I started my OS in 1988, and at that time the 386-processor was brand new, and there were no C compilers that could generate code for it (that I had access to). I also early on decided to use all the segment protection features of the 386 processor. I've kept this strategy except for hardware taskswitching which I had to abondon as I added SMP support earlier this year.

[smoothCoder]

When one is writing inline assembly with C, it is like write in an russian chat with latin keyboard - you still are writing in russian language and with inline assembly you are still writing ASM. So it seems ilogical to blame a language that you currently use.
And often dealing with bad compillers, take more time that writing ASM. When I code in ASM, I spend all my time to resolve the real problem-let say APIC, IRQa, when one is using compillers it often spend time to deal with problems like version of compiller, bug list for the compiller, options, declarations, linking - he is spending 80% of his time with compiller stuff and 20% with the core of the OS development. So my opinion is that ASM could be faster.
I still ask myself why people pretend to deal with low stuff, hardware, regs etc. when writing OSes and still blaming ASM.

[JamesM]

I think you are wrong. Compilers are good enough now that for 90% of the assembly you write, a C compiler will beat you on speed. The only times when you will beat it are with a very tightly optimised loop that its register allocator can't deal with well (i.e., compilers are optimised for the general case, not the specific case).

Most compilers cannot handle mixed-mode segmentation, which is the primary reason why I've this far only used assembly. However, the Open Watcom compiler has support for old OS/2 mixed-mode segmentation, which makes it possible to generate this with a high-level compiler.

So, it is not only a speed issue, it is also a protection issue. I use segmentation to isolate drivers from each others, and from userlevel code, and most C compilers does a lousy job on generating code like that, if they can do it at all. If you use software-protection instead, there will be lots of validation code that I don't need that will slow down the system.

Not only that, but C/C++ code is *far* easier to maintain and debug than assembly code, scales better and is easier for an outsider to grok.

It is definitely easier to maintain (no question about that), but in regards to easy debugging, flat memory model kernels are a night-mare to debug (regardless of language used).

In essence, you're wrong on all counts. It's not the 1970's any more.

I forgot the most important reason. It is far more fun to code in assembly than in C. And don't forget the challenge in writing an assembly-only kernel.

Your replies do not match up with your original statement. You originally stated that:

I don't think that C/C++ belongs in a OS kernel. If you can write code in C with no assembly, chances are the code does not belong in the kernel.

NOT, that your own OS is a back-reference to the 8086 era and uses an outdated and deprecated form of memory protection.

You are defending an entirely different point than what you made in the first place.

James

[Solar]

I forgot the most important reason. It is far more fun to code in assembly than in C.

I think this is up to the individual. I might even agree that there is some fun in coding ASM. But debugging ASM... well...

And often dealing with bad compillers, take more time that writing ASM. ...when one is using compillers it often spend time to deal with problems like version of compiller, bug list for the compiller, options, declarations, linking - he is spending 80% of his time with compiller stuff and 20% with the core of the OS development.

I call BS/FUD on this one. The time of "bad compilers" is long over. Today's compilers are much better than most people give them credit for. It's been years since I last encountered a compiler issue. Then again, my coding style is a pretty clean one, so I don't stumble into "undefined country", "implementation-defined behaviour" or the more murky corners of the language standards that often anymore (which is usually where other programmers start to complain about "buggy compilers").

I still ask myself why people pretend to deal with low stuff, hardware, regs etc. when writing OSes and still blaming ASM.

Now let's not get this on the personal level. The people here don't "pretend" anything, no matter which language they're working in. This peer group here stands heads and shoulders above the average code monkey.

But you cannot brag that "only ASM is the really leet stuff", while at the same time claiming that "ASM is the easiest language to OS programming in".

Someone writing C does have it easier than an ASM coder. Someone writing Brainfuck does have more bragging rights.

You don't get to eat the cake and keep it.

I'll hand you ASM people the bragging rights on a silver platter, but there is no way you can convince me that coding in ASM is more productive than C or C++.

[JamesM]

I'll hand you ASM people the bragging rights on a silver platter, but there is no way you can convince me that coding in ASM is more productive than C or C++.

I won't even stretch that far. To a further extreme if someone were to distrust assemblers and hand-assemble instruction opcodes, I would say the same thing:

"Making more work for yourself for no reason is not something that I admire. If you want to code in assembly because you enjoy it, fair enough, but I will apportion bragging rights to the person who chooses the right effort/reward balance. And hand-coding everything in assembler is not it."

So code in assembler if it makes you happy. But don't ***** about how "leet" it is compared to using a high-level language, just because it is more difficult. I can code in assembly too, I just choose not to because it's a waste of my time, in 90+% of cases.

[smoothCoder]

I forgot the most important reason. It is far more fun to code in assembly than in C.

I think this is up to the individual. I might even agree that there is some fun in coding ASM. But debugging ASM... well...

And often dealing with bad compillers, take more time that writing ASM. ...when one is using compillers it often spend time to deal with problems like version of compiller, bug list for the compiller, options, declarations, linking - he is spending 80% of his time with compiller stuff and 20% with the core of the OS development.

I call BS/FUD on this one. The time of "bad compilers" is long over. Today's compilers are much better than most people give them credit for. It's been years since I last encountered a compiler issue. Then again, my coding style is a pretty clean one, so I don't stumble into "undefined country", "implementation-defined behaviour" or the more murky corners of the language standards that often anymore (which is usually where other programmers start to complain about "buggy compilers").

I still ask myself why people pretend to deal with low stuff, hardware, regs etc. when writing OSes and still blaming ASM.

Now let's not get this on the personal level. The people here don't "pretend" anything, no matter which language they're working in. This peer group here stands heads and shoulders above the average code monkey.

But you cannot brag that "only ASM is the really leet stuff", while at the same time claiming that "ASM is the easiest language to OS programming in".

Someone writing C does have it easier than an ASM coder. Someone writing Brainfuck does have more bragging rights.

You don't get to eat the cake and keep it.

I'll hand you ASM people the bragging rights on a silver platter, but there is no way you can convince me that coding in ASM is more productive than C or C++.

Ok! It's right, I took it some personally. But I will take it smoother from now.

Code snippet from osdev wiki:

Code: Select all

static inline void cpuid(int code, dword *a, dword *d) {
  asm volatile("cpuid":"=a"(*a),"=d"(*d):"0"(code):"ecx","ebx");
}
 
/** issue a complete request, storing general registers output as a string
 */
static inline int cpuid_string(int code, dword where[4]) {
  int highest;
  asm volatile("cpuid":"=a"(*where),"=b"(*(where+1)),
               "=c"(*(where+2)),"=d"(*(where+3)):"0"(code));
  return highest;
}

code snippet from me:

Code: Select all

cpuid

my code for convert little to big endian:

Code: Select all

bswap RAX

Your C code for do this.......

[Solar]

With CPUID, you chose an example from the <1% of kernel code that cannot be done in C.

If you are interested in a comparison (instead of something fabricated to prove your point), we could compare implementations of sorting algorithms, linked-list handling, or the code that prints strings and integers to screen. (*)

As for "bswap RAX", I'd either write an inline function using inline ASM, or a macro using a compiler builtin. These things are not about religion, they're about using the most appropriate tools, and in the case of "bswap" and "cpuid", the most appropriate tool is ASM.

That doesn't mean I'll write the whole kernel in it.


(*): Don't. You would only waste your time, because I am not in a mind to waste my time writing up "bragging code" just to prove a point. My QSort is here, the pale ghost of the beginnings of an OS project containing printing code is here, and that's all I'll contribute to this.

[smoothCoder]

I know how attractive is for lazy coders the idea of use just "sortOn(myArray)"

If you see my sorting algorithms in ASM you will convince for the rest of your life, but I will not post here propietary code.

Ok! Think what you want to think. Just let me tell you the story of my life:
I have PC from 5 years(I never saw computer before). So I wanted to be creative with this PC, but all people told me that programing is for super-humans and mathematical. Then I wasted 2 years of my life in modding. One day I tryed to program something in VBScript. And I realised that they has lied to me. This is my problem no? Then all people told me that ASM don't worth the effort and to use OOP. I wasted 2 years more of my time dealing with compillers, forums, updates, bugs etc. But was a lie:.

So the reason I get it personally(a bit) is that all you are lying all the guest users that read this daily. ASM is different, not harder.

[JamesM]

I know how attractive is for lazy coders the idea of use just "sortOn(myArray)"

If you see my sorting algorithms in ASM you will convince for the rest of your life, but I will not post here propietary code.

Ok! Think what you want to think. Just let me tell you the story of my life:
I have PC from 5 years(I never saw computer before). So I wanted to be creative with this PC, but all people told me that programing is for super-humans and mathematical. Then I wasted 2 years of my life in modding. One day I tryed to program something in VBScript. And I realised that they has lied to me. This is my problem no? Then all people told me that ASM don't worth the effort and to use OOP. I wasted 2 years more of my time dealing with compillers, forums, updates, bugs etc. But was a lie:.

So the reason I get it personally(a bit) is that all you are lying all the guest users that read this daily. ASM is different, not harder.

No, actually, he is 100% correct. ASM is much harder. To produce reliable, scalable, bug-free and maintainable code.

How many assembler projects do you know of that have a test suite with them (with the exception of Brendan because he is of course the King of Everything)? None, because they're generally all hack-jobs without any real software engineering practice behind them at all. If you want to hack at something, sure, go ahead, but please don't preach that it's (a) good practice or (b) maintainable.

If I saw your sorting algorithms I still wouldn't be convinced. I honestly doubt your assembler quicksort can beat a C implementation for clarity or (source) code size. I also doubt that it would be very much faster than such a C algorithm compiled at -O3 with a modern compiler.

Not only that, but I doubt very much that your assembler hand-coded version can take advantage of multiple cores, which C can (with the aid of openMP).

Because your life story does not include proper software engineering experience does not mean that the people who taught you were lying to you, nor that you are automatically right.

James

Oh, and:

I know how attractive it is for lazy coders...

No, that is what clever coders do. Clever coders know when to modularise and reuse, and when to reinvent. Clever coders use their time effectively.

[Owen]

How many assembler projects do you know of that have a test suite with them (with the exception of Brendan because he is of course the King of Everything)? None, because they're generally all hack-jobs without any real software engineering practice behind them at all. If you want to hack at something, sure, go ahead, but please don't preach that it's (a) good practice or (b) maintainable.

King of Everything but getting stuff done

(And this I say with the utmost of respect for him; he is a veritable font of knowledge, and I understand clearly why he chooses ASM. Believe me, his reason is better than yours.)

[Solar]

@ smoothCoder:

I was well twice your age when I started programming, but that was a different time then (we're talking the eighties here..). Since then, I went through various dialects of BASIC, ASM/6502, Amiga DOS, ARexx, C, C++, Java, VisualBasic, bash, Perl, PL/SQL, a couple of others which I haven't used long enough to actually remember, and a couple more that were problem-specific and wouldn't ring a bell with anyone who hasn't worked on the project in question.

I learned procedural, object-oriented, generic, and some functional programming. And none of it was a waste of time, because even if you don't use a paradigm, knowing about it expands the ways you can think about a problem.

This year I "celebrate" my 10th anniversary of working as a maintenance coder, meaning I work 40 hours a week expanding on previous work of others. (Quick calculation... that's >20,000 hours total... *phew*...) Most of this work has been done in the field of "system" programming. This time has changed my views somewhat. I'll tell you why:

The number of times I had anything to do with ASM code while at the office: zero.

The number of times having a team of crack ASM coders would have benefitted the project: 0.75, if you're counting generously. (Those 0.75 is my current work project, which I don't count as a "1" because a proper refactoring of the C++ code would probably solve any performance problems we have; I just don't get the budget to do it, just as the guy before me didn't get the budget to do it right the first time around.)

The sad point is that readability and maintainability does count more than raw efficiency 99.999% of the time. And since that means that there are next to no pro-grade ASM coders in any given software company (or the workforce market as a whole), even the 0.001% get implemented in C or higher-level languages.

The only exceptions where things do get done in ASM are some parts of kernels, some compilers, and perhaps (I wouldn't bet money on it) database systems. (Actually my current project includes two different languages and a VM to execute them in, but all this is done in C++, and neither the parsing nor the executing of the code is the bottleneck.) Because you still don't have hordes of ASM geeks standing by to do the job, you try to limit and contain any ASM code, so that you can get by with one or two specialists.

This means ASM is the ticket for the lone specialist.

And even while some people I have worked with (and do work with) are genuine douchebags, I do prefer working with others instead of ticking off assignments in a lone cubicle.

That's why, even when shown ASM code of raw beauty (and I've been in the demo scene long enough to have seen some code that would make your eyes water, like a twelve-line vertex shader), I will never do more ASM work than absolutely necessary, even when working on my own and not on a budget. It's just not worth it for me.

[smoothCoder]

@ smoothCoder:

I was well twice your age when I started programming, but that was a different time then (we're talking the eighties here..). Since then, I went through various dialects of BASIC, ASM/6502, Amiga DOS, ARexx, C, C++, Java, VisualBasic, bash, Perl, PL/SQL, a couple of others which I haven't used long enough to actually remember, and a couple more that were problem-specific and wouldn't ring a bell with anyone who hasn't worked on the project in question.

I learned procedural, object-oriented, generic, and some functional programming. And none of it was a waste of time, because even if you don't use a paradigm, knowing about it expands the ways you can think about a problem.

This year I "celebrate" my 10th anniversary of working as a maintenance coder, meaning I work 40 hours a week expanding on previous work of others. (Quick calculation... that's >20,000 hours total... *phew*...) Most of this work has been done in the field of "system" programming. This time has changed my views somewhat. I'll tell you why:

The number of times I had anything to do with ASM code while at the office: zero.

The number of times having a team of crack ASM coders would have benefitted the project: 0.75, if you're counting generously. (Those 0.75 is my current work project, which I don't count as a "1" because a proper refactoring of the C++ code would probably solve any performance problems we have; I just don't get the budget to do it, just as the guy before me didn't get the budget to do it right the first time around.)

The sad point is that readability and maintainability does count more than raw efficiency 99.999% of the time. And since that means that there are next to no pro-grade ASM coders in any given software company (or the workforce market as a whole), even the 0.001% get implemented in C or higher-level languages.

The only exceptions where things do get done in ASM are some parts of kernels, some compilers, and perhaps (I wouldn't bet money on it) database systems. (Actually my current project includes two different languages and a VM to execute them in, but all this is done in C++, and neither the parsing nor the executing of the code is the bottleneck.) Because you still don't have hordes of ASM geeks standing by to do the job, you try to limit and contain any ASM code, so that you can get by with one or two specialists.

This means ASM is the ticket for the lone specialist.

And even while some people I have worked with (and do work with) are genuine douchebags, I do prefer working with others instead of ticking off assignments in a lone cubicle.

That's why, even when shown ASM code of raw beauty (and I've been in the demo scene long enough to have seen some code that would make your eyes water, like a twelve-line vertex shader), I will never do more ASM work than absolutely necessary.

Glad to read this. Apparently you understand that ASM is the best. And I understand that its use is a denormal porcent number. Sorry I enraged a bit becouse all the world are becoming lazy, I am trying to form a team of ASM coders for my hobby-OS, but nobody want even to code in JavaScript. This make me sad. In 2020 all will be ****** in this world.