Jump to content
xisto Community
Sign in to follow this  
sottm

OS On Assembler

Recommended Posts

Some people developed their OS on Assembler. It's provides speed OS, but brings hard code and bad ability. How do you think it is necessary to endow speed or comfort?

<{POST_SNAPBACK}>


You'll find that a lot of OS combine both C/C++ and ASM. Usually ASM is used in places where programmers find bottlenecks in their program, codes that can slow the system down, by using inline Assembly they can efficiently speed up the program.

 

There may or may not be a reason to write a program completely in ASM, as C/C++ compilers do a reasonable job and may provide better methods for the code. I find it's best to incorporate both languages, that way you have the best of both worlds.

 

An OS written in entirely in 32bit assembly language is Menuet OS. I highly recommend it, even if it's just to learn about it.

 

 

Cheers,

 

 

MC

Share this post


Link to post
Share on other sites

The reason for programming anything using C++ versus assembler is the sheer amount of coding it requires to program anything using assembler without using libraries of existing pre-programmed functions and procedures. Even in the case of programming a basic(not the language) OS(which is miniscule in size compared to current program sizes) you would expect to spend countless hours structuring the thing and be balding after debugging it. Add to that the fact that it's virtually impossible to use a top down approach and that without many supporting libraries your results will vary widely depending on the machine you are using the OS on. At this point I'm really quite curious why you would want to program your own OS with so many already available. Maybe I'm ignorant, but it seems there would be more fruitful ventures to explore than that. In any case good luck at that. You can locate a compiler with a simple web search for C++ or Assembler.Hope that helps

Share this post


Link to post
Share on other sites

The view that assembly is lightning fast compared to high level languages is less true than it used to be.compilers are much much more sophisticated than they used to be (im talking GNU GCC, not MS's compiler)Often, a programmer can achieve assembly execuion speeds by properly writing c++ code, and properly manipulating GCC optimisation flags.however, bottlenecks can still occur, and when they do Assembly is inserted into C code.

Share this post


Link to post
Share on other sites

Another reason why OS's were written in assembly was that assembly has very tight control over memory usage. When computers had at most maybe 128Mb of RAM, this was necessary. Assemb;y programs are also frequently smaller, so a large Os could fit onto a 1Gb hard drive with plenty of space left over. In this day and age, neither of these two issues are large concerns, so OS writing is moving out of the assembly realm and into higher the higher level realm. However, I still prefer assembly.

Share this post


Link to post
Share on other sites

The view that assembly is lightning fast compared to high level languages is less true than it used to be.compilers are much much more sophisticated than they used to be (im talking GNU GCC, not MS's compiler)

Often, a programmer can achieve assembly execuion speeds by properly writing c++ code, and properly manipulating GCC optimisation flags.

however, bottlenecks can still occur, and when they do Assembly is inserted into C code.


Not realy. The asm code produced by any c++ compiler is realy bad compared with true ASM. Its usualy just a bunch of calls and machine lanuage, but not very efficient or fast. You have more control with direct ASM. Its better to simply have '#include' files to make asm easier.

Share this post


Link to post
Share on other sites

I agree that compiled high level languages are never as efficient as pure assembly. I don't know enough about the various includes to comment on that, unless by includes you mean inline assembly. I love inline assembly and find it is an ever increasingly useful tool.

Share this post


Link to post
Share on other sites

I believe the type of operating systems you're discussing include MenuetOS. Indeed, MenuetOS appears to be the most famous x86 assembly OS project, having been mentioned on Slashdot, among other places. Even so, MenuetOS classifies itself as a hobby OS.

Writing an operating system today is no small prospect. It's simply impossible for a company to manage an assembly project the size of Macintosh OS, Windows, or Linux. And with the constant changes in hardware specifications dictated by the software makers--nobody really wants to write a solid OS in assembly. At least, nobody wants to write another Linux in assembly.

Inline assembly... well... I can't say I've done much of that. Anyone else got an opinion on that?

Share this post


Link to post
Share on other sites

And with the constant changes in hardware specifications dictated by the software makers--nobody really wants to write a solid OS in assembly. At least, nobody wants to write another Linux in assembly.

 

Inline assembly... well... I can't say I've done much of that. Anyone else got an opinion on that?

<{POST_SNAPBACK}>

I beg to differ, but there are many projects designed towards creating large scale osses in assembly. For more information on some of these, visit osdever.net. I believe CottonOS there is a large scale project (I haven't looked at CottonOs, so not 100% sure).

 

As far as inline assembly goes, inline assembly is great. It is highly optimized snippets of code that allow for the ease of coding provided by a higher level language with the power of assembly. The only problem is that many compilers were not designed for inline assembly and thus become very inefficient if making too many calls to inline assembly functions.

 

~Viz

Share this post


Link to post
Share on other sites

Not realy. The asm code produced by any c++ compiler is realy bad compared with true ASM. Its usualy just a bunch of calls and machine lanuage, but not very efficient or fast. You have more control with direct ASM. Its better to simply have '#include' files to make asm easier.

<{POST_SNAPBACK}>


As far as I am concern, C++ have an assembly dump compiler mode where the compiler generates the equivalent assembly code for the obj it generates.

 

Write the main OS on pure C++ then let C++ generate the Assembly code when you compile. After that, be ready with your ASM compiler [prefer TASM] and do some editing on the Assembly file.

 

Most of the bottle necks or slow down is caused by the excessive push and pop commands in every function calls which is often times a redundant move by the compiler.

 

I manage to write a mini-OS using this approach and it only took me 1-2 months developing it compare to my classmate mo made his using pure assembly who take him half a year.

 

He produced an OS with a smaller size but the size difference compare to mine is not more than 10%..

 

Speed difference is minimal..

Share this post


Link to post
Share on other sites

As far as I know, there are not many OSes completely written just in Assembler, most of the OSes have the the kernel (and even, not all the kernel, but just some of the functions) written in ASM. One of the reasons is to take control over the CPU and the machine, sometimes C/C++ just do not provide statements to do so, or they just take "too" long (several millisecs!!!) because of the function callings, etc. For example, if you want to control cache, you'll probably prefer to take control of it directly with ASM. Or if you have to take control of the MMX/SSE resources (I don't guess for what... but who knows! :unsure: ) you can just access them using ASM or with the Intel Intrinsics library... I just cannot imagine an OS which is dependent not only on an architecture but also on a proprietary library...Another differente question is why isn't so common to embed Assembler code in C/C++ code... I prefer this option, however, "puritans of the Assembler" prefer to write the functions completely in ASM... not sure why they prefer to take control of the arguments, initializations of the variables, etc. For me, C/C++ just do a great work with those items.

Share this post


Link to post
Share on other sites
Assembler OSOS On AssemblerReplying to sottmReplying to sottmWhy is it always considered a big problem that some people wants to develop an OS in Assembler.It is not mainstream and that seems to be provoking.I want a fast,stable.Reliable OS were I don´t need to write a line in any C-language.I know they have problems with pointers I have proof of this in linux and windows.I use it because of all the programs you can download.I just wonder if you have experienced problems with C-languages.?I personally think it is the only way to write an OS.Ring 0 only Assembler.Appliancies are better in Dephi,Lisp,whatever language that is not based on C.I would never write a line of code if I were not supportred by an Assembler OS.Assembler is the king and C is a mean unreliable powerhungry prince.People deserve thecrapOS they use.I could care less.Ubuntu allmost work but not more.I have tried W7,XP,Xubuntu,Linux Mint,Fedora,Solaris,Open BSD,and now I write on a Mac which I also consider crap.If you are happy mate it is allright to me but everybody that attacks the few that wants an Assembler OS it makes me a little bit irritatated.Do not step on my toes please.You are a big mainstream mass without a face to me.The more negativity you spread the more eager I will get to learn Assembler and to be a part of a development of Assembler operative systems.If I were a programmer I wouldn´t even give you a line of code for money.Stick to what you like but do not complain to me about your problems with Linux.Mac,Windows,or whatever.Now I am going to youtube to listen to Qeeen so bye bye.-reply by levagastir

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.