OSDev.org

Posted: **Wed Jan 11, 2017 10:58 am**

Hello.

Someone said that OS development is not for me if I didn't learn C. Assembly is much better. It might not support multiple architectures but it's lightweight. It's quite fast. You can use Wikipedia for references. Most of the time, C requires YouTube tutorials. I'm sorry but if you want to say C is so good, why don't you kiss Dennis M Ritchie, huh? Without Assembly, we wouldn't have anything.

Windows used C and C++. Many of the operating systems in this world did and they require 1GB RAM or more. The Linux Kernel used C and that takes a hour to build (depending on your system).

KolibriOS, MenuetOS and Baremetal OS were 100% fully written in Assembly. They are only a few megabytes! How can you explain that? They even have a GUI. C is absolutely useless for OS development.

USE ASSEMBLY! STOP COMPLAINING ABOUT C! USE ASSEMBLY. OTHERWISE, YOU WILL HAVE A SLOW OS. People encourage you to use something like Assembly. C is hard but does make you look like you need it so bad. You can learn quite a lot from Assembly.

C has got functions like gets(); that cause viruses and worms!

Please stop saying that C is so good because it only has more work.

Posted: **Wed Jan 11, 2017 11:26 am**

Regardless of whether C is better or not, it is (mostly) portable, which assembly isn't. This allows a system such as Unix (and it's derivatives such as FreeBSD or Linux), or OS-9 (the old 6809 and 68000 operating system, not the version of Mac System from the 1990s), or several others, to be reimplemented on new hardware platforms (such as ARM for tablets and smartphones) far faster and easier than one that would have to be re-written from scratch in that CPU's assembly language.

Furthermore, while the individual instructions in assembly language are far simpler to use and understand (for some people, anyway), they require a lot more effort put into expressing any given construct, and that complexity increases almost exponentially with the complexity of the data structures being used.

More to the point, here, is that the majority of example code already written is written in C, mainly because most programmers find it easier to read C than the read assembly, and more programmers know C or related languages such as C++ (or, going a bit further afield, Java and C#).

Regardless of whether you write your code in C, or assembly, or any other suitable language, you really need to be able to read C code in order to study OS design.

Finally, most of the bloat you complain about has nothing to do with the programming language - a good C compiler (which admittedly, neither GCC nor VC++ count as) will produce better machine code than all but the best assembly coders, and do so more consistently than any human being is capable of doing. The bloat is in all the added features and support systems: the GUI (or rather, in the chrome that has been getting stuffed into them over the past several years - the original MacOS GUI ran in about 96K of the system's 128K, though admittedly the Quickdraw toolkit in the 64K system ROM was in fact written in assembly language); in the network code (when sockets were added to the Unix kernel in the early 1980s, it more than doubled the kernel size!); in providing the application developers a 'rich' system API; in the vast 'backwards-compatibilty' code that they need to provide for the 0.001% of the users who needed it (which IIUC accounts for maybe 25% of the Windows system image); in supporting drivers for tens of thousands of different CPU models, motherboard models, and peripherals; and so forth.

It is notable that the Version 6 Unix kernel described in Lions' Commentary on the Unix Kernel (circa 1976) ran in less than 16K (IIRC), and that was after it expanded substantially from the previous version. The xv6 reimplementation is somewhat larger, due to the differences in hardware, but it is still far smaller than some assembly-language operating systems.

Posted: **Wed Jan 11, 2017 11:27 am**

He is just a troll. I don't think he is serious.

Posted: **Wed Jan 11, 2017 11:40 am**

I suspect I am going to cause a lot of trouble doing this, but...

If you really want to focus on performance above all else, I recommend reading the works of Alexia Massalin, specifically regarding the Synthesis operating system kernel (both the original Quamachine version and the Sony NEWS port) and the Aha Superoptimizer.

Note that she never claimed that the kernel was efficient because it was in assembly, or because it was simple, but because of the - quite complex - optimizations it applied. She even stated that the process could be applied to a higher-level language, provided that the language was homoiconic and/or had sufficiently robust reflection (both metaprogramming attributes primarily found in languages far higher-level than C), though she did state that the Lisp compilers she was familiar with were not up to the task (something I am quite certain is not the case today, and probably wasn't even true in 1992).

Posted: **Wed Jan 11, 2017 12:28 pm**

Schol-R-LEA wrote: Note that she never claimed that the kernel was efficient because it was in assembly, or because it was simple, but because of the - quite complex - optimizations it applied. She even stated that the process could be applied to a higher-level language, provided that the language was homoiconic and/or had sufficiently robust reflection (both metaprogramming attributes primarily found in languages far higher-level than C), though she did state that the Lisp compilers she was familiar with were not up to the task (something I am quite certain is not the case today, and probably wasn't even true in 1992).

I was enamored of the actual hardware based lisp machines of the late 80's...

For reflection, I don't think you can really beat lisp... Schol-R-LEA what do you think?

Then the Japanese tried to build a Prolog machine and Godzilla ate it.

I thought the whole process of specifying rules ended up being a precursor to C++ Template Meta-Programming

Posted: **Wed Jan 11, 2017 1:27 pm**

dchapiesky wrote: I was enamored of the actual hardware based lisp machines of the late 80's...
For reflection, I don't think you can really beat lisp... Schol-R-LEA what do you think?

Depending on the internal representation, lisp could be very hard to beat.
My implementation is SICP-esque, where functions are simply tagged lists. So modifying arguments, body, or execution environment of a function during runtime is trivial.

Posted: **Wed Jan 11, 2017 3:06 pm**

Hi,

andrewthompson555 wrote:KolibriOS, MenuetOS and Baremetal OS were 100% fully written in Assembly. They are only a few megabytes! How can you explain that? They even have a GUI. C is absolutely useless for OS development.

Most of the size of a modern OS is in data (graphics, fonts, sound, help systems, etc) and not code. Ignoring that, less hardware support (fewer drivers, etc), less features and worse optimisation (loop unrolling, etc) all help to reduce code size.

andrewthompson555 wrote:USE ASSEMBLY! STOP COMPLAINING ABOUT C! USE ASSEMBLY. OTHERWISE, YOU WILL HAVE A SLOW OS.

As someone that has been doing OS development in assembly for about 20 years now I can guarantee this is wrong in practice.

The problem with assembly is that the more you optimise the longer it takes to write and the harder it becomes to maintain. For this reason, any assembly language programmer that has the skill needed to create code that is faster than C will not optimise the majority of their code, and the majority of their code will be slower than C. It's only people that lack the skill needed who think that assembly is faster than C in practice (for "apples vs. apples" comparisons - e.g. equivalent code with the same functionality, features and algorithms).

For maximum performance, what you really want is the majority of the code in a higher level language, with only the performance critical minority of the code (e.g. the pieces identified as important by profiling/testing) written in assembly.

andrewthompson555 wrote:Please stop saying that C is so good because it only has more work.

I don't think I have ever (in my entire life) said that C is good.

The main thing you need to understand is that all programming languages suck (for different reasons); and that the best approach is to use the "least worst" tool for the job.

Cheers,

Brendan

Posted: **Thu Jan 12, 2017 12:17 pm**

dchapiesky wrote:I was enamored of the actual hardware based lisp machines of the late 80's...

For reflection, I don't think you can really beat lisp... Schol-R-LEA what do you think?

Given that the systems-programming language I am designing (Thelema) is in the Lisp family, and am also writing an s-expression based assembler to go with it, I would definitely have to agree.

Posted: **Thu Jan 12, 2017 1:23 pm**

Schol-R-LEA wrote:a good C compiler (which admittedly, neither GCC nor VC++ count as) will produce better machine code than all but the best assembly coders, and do so more consistently than any human being is capable of doing.

I agree on all what you said, except this one. A human is always smarter than any compiler, therefore can produce better assembly. I mean a human can take the big picture, and knows what registers is used for. Eg.: rbx=5. The compiler would only see that rbx is used, but without knowing what for. On the other hand a human would know that 5 is a partial result for a calculation in question and would simply use that instead of writing a code to do the whole thing from the begining. Does that make any sense to you?
A good example is in my libk.S the ksend() function. There's nothing platform specific about it, it just simply copies 64 bytes to a circular buffer and updates indices, but the C version was so terrible and full of jumps and the same calculation over and over again that I've rewritten it in assembly to be effective. (Yes I know you've said gcc is not a good C compiler, but hope you get my point).

As one exception, once I saw this assembly on a specific hardware (in x64 as I can't recall the exact mnemonics, it was more than 20 years ago):

Code: Select all

ret
mov result, eax

Here saving the result for a function came *after* the return instruction in the source, as they are executed simultaneously because of the CPU pipeline. I couldn't remember what CPU it was, but I do remember I saw this on Ultrix. That optimized source could not have been written by any human for sure

Posted: **Thu Jan 12, 2017 2:03 pm**

bzt wrote:
Schol-R-LEA wrote:a good C compiler (which admittedly, neither GCC nor VC++ count as) will produce better machine code than all but the best assembly coders, and do so more consistently than any human being is capable of doing.
I agree on all what you said, except this one. A human is always smarter than any compiler, therefore can produce better assembly.

I agree that the best hand-coded assembly is going to be better than the best compiler-optimized code, yes. However, a) very few assembly programmers are capable of producing hand-coded assembly which is that good, and most produce code that is far worse than the compiler-generated code would be, and b) no human programmer can produce optimized code on a sustained basis that a compiler can as a matter of course.

As for the 'big picture', that is true of most compilers, yes, but not so true of globally-optimizing compilers such as Stalingrad or the Intel C compiler. Those can leverage the elephantine memories of the computer to great effect. The result is going to be different from what a human coder would do, with the compiler losing in some places and winning in others, but they could do things no human coder could just as a human coder could do things they couldn't.

In any case, focusing only on performance fails to take into account both the effort needed to produce assembly vs the equivalent (if less optimal) code in a more abstract notation, and the feasibility of using higher-level abstractions in a fine-grained language such as assembly (or C, for that matter). Even in terms of pure performance, if by using C a coder is more readily able to use a more complex, but more efficient, algorithm than would be feasible in hand-coded assembly (i.e., it would not be impossible to implement the same algorithm, but would be impractical given the time and effort needed for both coding and debugging), then it would hardly matter how inefficient the compiler was.

Posted: **Thu Jan 12, 2017 2:25 pm**

School-R-LEA, How do you get to read C language without having to write it?

Posted: **Thu Jan 12, 2017 2:28 pm**

bzt wrote:Here saving the result for a function came *after* the return instruction in the source, as they are executed simultaneously because of the CPU pipeline. I couldn't remember what CPU it was, but I do remember I saw this on Ultrix. That optimized source could not have been written by any human for sure

Was it MIPS, perhaps? Filling in MIPS branch delay slots is a fairly easy optimization for humans. (Of course, it's even easier for machines - some MIPS assemblers do it automatically!)

Posted: **Thu Jan 12, 2017 2:29 pm**

Mark12 wrote:School-R-LEA, How do you get to read C language without having to write it?

Well, that's the thing, you really can't - I mean, you can learn to read it to some degree, just from the similarities it has to other procedural languages if nothing else, but without practice at writing C code, you'll never really get a feel for the language. So in that sense, yes, you would need to write a significant amount of C code before you could read it well.

Posted: **Thu Jan 12, 2017 2:36 pm**

bzt wrote:Eg.: rbx=5. The compiler would only see that rbx is used, but without knowing what for. On the other hand a human would know that 5 is a partial result for a calculation in question and would simply use that instead of writing a code to do the whole thing from the begining. Does that make any sense to you?

No, compilers have constant folding and constant propagation and liveness analysis and many other techniques that it will do automatically for any piece of the program. In assembler you'd have to apply these same techniques 1) by hand, 2) each and every time. Guess who tires of that sooner. Guess who makes more mistakes while doing it.

Posted: **Thu Jan 12, 2017 3:57 pm**

@Schol-R-LEA: agree, if you take those other factors into account, you're right. Hand writing (good) assembly takes a lot of time, and a very optimized code can be a real headache to understand later. And you're also right that most programmers don't write good assembly, so most likely they loose on ineffective implementation what they gain on algorithm.

@Octocontrabass: could be! According to the wiki, DEC have used MIPS. I really don't remember, I can only recall my "wtf is happening here?!?" moment

But I'm sure the answer for "shuffled" instructions was that the CPU is using several pipelines and therefore reads and executes more instructions at a time.

@dozniak: what I meant constant folding and constant propagation and liveness analysis never will be as good as algorithmic optimalization. If you came up a better, simpler solution for the same problem that would always beat those. There are (and were) experiments with evolutionary programming (is this the proper translation?), but I've never heard of any game changing results so far. Computers still (and will in the foreseeable future) need guys like us to tell them what and how to do.

OSDev.org

Why do people say C is better than Assembly?

Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?

Re: Why do people say C is better than Assembly?