OSDev.org

I was wondering if I could write my kernel in assembly instead of C, and if so are there any advantages or disadvantages compared to writing it in C, any comment would be of great help ,thx

Assembly code isn't portable, so you would have to rewrite pretty much everything if you want to port it to additional architectures.

assembly is tedious to use. After a few steps, it will lead you to seek for the simplest solution (which is the only one you can afford with that tool) instead of using the best (or at least a better) one...

Moreover, assembler quickly turns into a nightmare once you try to both debug and optimise your code (for there may be inter-dependencies that you had in mind when you wrote the code and that you can't remember of when patching it ...)

Nobody's thought of any advantages .

Assembly code can be faster than C if you are an expert.

I have never seen anyone who can write better assembly code than a C compiler, except maybe for 5 lines at a time. Certainly a whole OS written in asm can expect to be worse-optimised than one written in C or C++.

"assembly is tedious to use." - Pype.Clicker

Actually I find it quite enjoyable, but that's just a personal thing and probably has something to do with having studied digital electronics many moons ago. The boolean algebra/logic of assembly language can feel more natural depending on where you are coming from.

"I have never seen anyone who can write better assembly code than a C compiler, except maybe for 5 lines at a time. Certainly a whole OS written in asm can expect to be worse-optimised than one written in C or C++. " - Tim

I've seen it, but still over a relatively short program and it was targetted at a specific processor. Over any large program there are simply too many things to keep track of to write optimal code (Unless you are very good).

***

Myth 1: Assembly language programs run faster than HLL programs

This is misrepresentative. Assembly language programs always have the potential to run faster than C programs (Because as a last resort you can sneak a peak at the assembled C and improve on it), but the vast majority of programmers do not possess the skill to pull it off. An average assembly language programmer won't be able to beat the compiler over anything but the shortest distance.

Myth 2: Assembly language programs are difficult to make and debug

This just isn't true. It's a myth propogated by HLL programmers who have seen a few heavily optimised programs and run back to momma. Assembly language is no harder than an HLL so long as you actually use assembly language reguarily. The same goes for debugging. I couldn't debug a common LISP program to save the universe, because I don't know common LISP. The debugging myth comes from people whose strength is in an HLL and occasionally come across, as they see it, deep voodoo assembly language embedded in large programs.

Myth 3: You can do things in HLL's that you can't do in assembly language

This is untrue. There is nothing, repeat nothing, that you can do in an HLL that you can't do in assembly language. However there are plenty of things you can do in assembly language that you can't do in an HLL. The problem, as Pype touched on, is that some things are just a serious pain in the @$$ to write in assembly (Even worse to write in optimised assembly). On the upside the flexibility of assembly language means that sometimes an assembly language programmer has access to better methods than an HLL programmer, but unless you are Knuth then you will most likely get more bang for your buck by using an HLL.

Myth 4: Using C makes your code portable

This is one that irritates me. Simply writing your code in C does NOT make it portable between architectures. It makes porting easier, but it does not magically make your code architecture independent unless you're are programming nothing more taxing than "hello, world". However since if you use assembly language you have to rewrite the entire program rather than porting the existing code to another architecture the HLL wins hands down on code efficiency. On the flip side the algorithmics behind your code will be the same on any architecture, so writing the code for the port will take a far shorter time than the original (Assuming you know both architectures equally well, big assumption ).

Myth 5: Assembly language programmers get more respect from their peers

This used to be the case, but we're living in a world where even C/C++ programmers get laughed at for persevering with an "outdated" programming language when they could be using whichever incredible OO HLL is flavour of the month. Outside a few niche arenas assembly language programmers get about as much respect as your average train spotter. If the computing community was a house party we'd be drinking cheap wine in the garage, waiting for an invite to the kitchen.

***

I could go on, but I think you get the idea. Writing everything in assembly language is certainly possible, but just not a very efficient way of doing things. It's far better to at least prototype your algorithms in a higher level language, like C, then optimise where required in assembly (If you're confident you can beat the compiler or do something different). You shouldn't write the whole thing in assembly language unless you have some reason, external to the actual program, to do so. I, for example, write in assembly language, but I do so because I enjoy it, not because I have any expectation that I can beat a compiler or because I want kudos for doing it. Unless you get a similar pleasure from some aspect of assembly language programming then I strongly reccomend you look into using your favourite HLL for the bulk of the work.

I agree with Curufir.
Check out www.menuetos.org

i am all so with Curufir.

Asm is like a shopping list, whilst C is like a end user license from MS .

Asm may look long, but it is only some three or four small words wide, so what looks like a lot of code takes no time to do

An OS written in asm is like a shopping list of parts for a nuclear bomb. Each line is only a couple of words, but there are lots of lines, and if any of them are wrong then the whole thing doesn't work.

Curufir wrote:Myth 2: Assembly language programs are difficult to make and debug
This just isn't true. It's a myth propogated by HLL programmers who have seen a few heavily optimised programs and run back to momma. Assembly language is no harder than an HLL so long as you actually use assembly language reguarily.

It is true that with enough practice, you can become fluent in pretty much any sane programming language. However, since HLLs almost by definition provide higher level abstraction and more intuitive syntax, they inherently require less effort to learn. For the same reason (easier to get the "big picture" about what the code is doing), they may also be intuitively easier to debug.

"Is it possible to create a cathedral using only toothpicks ?"

Yes. It is ... Xyz did it and now it's in the guiness book records! Using only toothpick gives you better sound & thermal isolation than third-party bricks ...

Would you choose toothpicks to build a cathedral because of this ?
Don't you thing when creating something that large, being able to reuse the same framework to solve similar problems, have a higher abstraction on what you're doing will help ?

You are tellin' me that it's as easy to hint a bug in a 30-pages asm stuff where you're not assured your comment still match with the actual computation performed as it is to do in a 3-pages C text ? You must be kiddin' aren't you ?

Any code or routine that spans 3 pages in any language, be it Asm or HLL, will be very hard to understand or debug. That is a rule in computing science and the reason why we use modular design which can be used in any language.
functions are supposed to perfom a single task in a few lines or code. 1 task per function will make debugging easier.
Clicker,you are missing the point here. We are saying that if you are proficient in any language that is suitable for os dev then you can use it.
I mean, using C/C++ for kernel dev still requires the developer knowing it intimately.
If I know asm enough, I can code in it after all its a programming langauge.
Bugs are an end result of bad design and poor programming practices, not a result of using ASM.
Or don't we all get bugs in our HLL code?

I find Asm is easyer to trace bugs because 99% of the time you wrote all 30 pages, in C sombody els wrote 20 pages (the libraries and include files).

Any code or routine that spans 3 pages in any language, be it Asm or HLL, will be very hard to understand or debug.

That is correct.
Now, how many lines of Assembler would you need to implement a dynamically-sized vector of dynamically-sized strings with two strings in it?

"Unfair", you might cry, "you're using the standard library!"

Not unfair, I would answer: This standard library is a standard library, a part of the language, and any decent C++ coder would immediately understand the above code. It is also immediately clear that myStringVector.size() would give the number of elements.

Now, you could of course implement the same functionality, put it in a library, and call that when you need a vector of strings, as I did with the standard lib. For anyone looking at your code, that would make no difference however: He still would have to read the source code of your library function (or your documentation of the same, if that is sufficient).

You simply don't get this level of immediate understanding with Assembler, since there are no "standard" libraries. Add to this that above code would compile on any compliant C++ compiler, while any feature-using Assembler code usually runs on a specific Assembler only.

Code Slasher wrote:Any code or routine that spans 3 pages in any language, be it Asm or HLL, will be very hard to understand or debug. That is a rule in computing science and the reason why we use modular design which can be used in any language.

It's also a reason why we use structured programming, which is syntactically much clearer in a HLL when compared to assembly.

Code Slasher wrote:Bugs are an end result of bad design and poor programming practices, not a result of using ASM.
Or don't we all get bugs in our HLL code?

That's at least debatable. Sure, we're bound to have bugs no matter what language we use, but the tendency to make mistakes is generally less when you have less "grunt work" to do. In addition, the types of bugs possible in assembly can be more difficult to track down as a direct result of your increased low-level control (most of which isn't need 95% of the time anyway).

I guess the reall matter comes to these factors:

• How good are you at assembly, and are you better or worse at it than you are with C? While assembly is in some way easier to learn the basics of, competent assembly programming is much more demanding. This applies to optimizing and debugging, as well;
• How much do you enjoy assembly programming? Unless you really love it, you shouldn't try something this large in it. The same applies to any language, in fact.
• How good are you at keeping your focus? A compiler may not be as efficient as a programmer, but it can be more consistently efficient than most programmers can be.
• How much time do you mean to spend on it? Assembly language generally takes 2-3 times as long to write and debug than C, even for a capable programmer. Line by line it may be simpler, but a line of C code may represent 20+ lines of assembly code.

In the end, it is your choice; if you feel confident enough to write an OS in assembly, feel free to try it.

General opinion these days, even among assembly gurus, is that you get the most bang for your buck by writing and debugging the system in an HLL, then using profiling and timing tools to locate the critical regions. Only after doing as much optimization as you can in the HLL, you would then pick out the absolutely most time-critical portions for rewriting in assembly. To paraphrase Michael Abrash, getting the most effiicent code means using assembly, but you only need that level of efficiency for a very small part of even a highly optimized system.

Speaking of him, I would definitely recommend douwnloading and reading the online version of his Graphics Programming Black Book. While much of it is now dated, the general spirit of the book is still quite relevant. You will probably find the whole book too much to swallow at once; I've only gotten to chapter 13 or so myself. Chapters 1, 3, 7 and 8 are particularly helpful.