OSDev.org

EDIT: Please leave a msg if you choose "Other" plz. Thanx. ;D

Hello , I'm switching from QB to a new Language (I have NASM and DEV-CPP). Any support is appreacheated.

Hi
I am useing fasm, Because this was made to go on a new OS,
The guy that made it, Lost most of the code when he had a pc crash, he lost hart after he lost all that code, but still had the code for the assembler , thats how fasm came about .
This makes it ideal for making OS's, and allso it is small 1 exe 45k in size, and easy to port and self compiling , and is already ported to Menuet OS .
Nasm is a great compiler if you are going to use C, but to make your OS independent you would have to port not only Nasm but allso gcc which is very big.
To port my OS from Nasm i only had to change 3 lines of code .
I dont want to come across as calling Nasm or C it is just my opinion.
ASHLEY4.

If anyone is interested, I'm going to set up a system language design thread in the General Programming forum, for those who want to discuss the matter further.

EDIT: Actually, I added three, for three different languages:
Basis
Sibilance
Obscene
HTH.

I would not recommend assembler. Many people may prefer it for osdev, but that depends on the personality.

Pros:
- if you are very good, you may create smaller and faster code in asm
-you will learn asm very much
Cons:
-on the other hand, one C line would mean one page of assembler code
-isn't that somehow.. hard to debug?

C is much better for the task. C++ gives an even higher abstraction level if you are ready to write the runtime bits.

C++'s got classes, which look pretty in the code.. ::) lol

Here's something I wrote in one of the newsgroups recently, which I think sums up my opinion of assembly vs. high-level languages.

Say I find the need to store an arbitrary number of integers in memory:
-- In C++ I can declare a std::vector<int> and use push_back to store each one
-- Using C I'd need to use realloc to reallocate a block for each new integer; I'd need to keep track of how many I'd stored; ideally I'd allocate new memory in larger blocks (say, 16 ints at a time) so I didn't need to call realloc too often.
-- In assembly... well, I'd have to code a substitute for realloc first (granted, I could use HeapRealloc here). Once I'd done that, I could then start thinking about how to store each element.

Then I realise I needed to store floating point numbers after all:
-- In C++, I change the 'int' to a 'float' and recompile
-- In C, I search and replace 'int' with 'float'. I make sure that any sizeof() assumptions I'd made still hold. I curse myself for not using a typedef in the first place.
-- In assembly, I realise I need to convert all my integer maths to floating point. I throw the whole lot away and start again.

In Scheme, I cons the numbers into a list. If I need to be sure about it, I'd use the [tt]number?[/tt] predicate to check the type of each variable, but odds are I won't need to.

To fix it to work with floating point... I leave it alone. It already works fine with them.

On reflection, there's nothing to say I can't write the numbers down on a piece of paper.

I'm currently writing compilers for two languages, both kinda Schemish, but more "practical" type.

The reason for two languages is that a good modern lisp dialect needs garbage-collection and runtime support and what not, but I don't like the idea of writing this all in C, so I'm currently experimenting another language, which is probably going to be something like "assembler with lisp syntax" which is to say, a very high-level assembler, but still one where you can do almost anything you can with a real, low-level assember. So basicly C-- with LISP syntax and macros

Frontend for the "scheme-like" is ready, although it needs some optimizations (self-recursion to interative conversion comes to mind, inlining when declared acceptable by user is another).

Backend and the second frontend remains to be written. After I've got my dual-language fully bootstrap with no external library support, I am going to try to write a kernel with those, so they can be fully self-hosted.

To thoes voting, tell others to vote too. I really aprecheate the info. ;D I think I'll remove the QB block....

I am writing mine in nasm, but will port it to fasm later...
One line of C code is one page of asm code? Don?t think so... (that would be really bad coding)

Two gripes with ASM:

* You don't have a standard library, and ASM code is not as expressive as HLL code. Everybody working on / with your code has to figure out how your version of __foo actually works, what registers to place parameters in and how to receive return codes etc. - every C++ coder knows what x.size() means...

* You have to be a wizard to generate more efficient code than your average C/C++ compiler; and it would imply significant additional work for every function so optimized.

If I may add to that comment that Solar made, it is a very bad idea to code an OS in pure assembly. At first you might be tempted to think you got the better idea, since coding bitfields and IO is a lot easier and quicker in assembly. However, as soon as you get to a slightly higher level, you get so incredibly stuck with complex structures that you wish you had chosen some high level language. For instance, make a hashing function in assembly, or make a TCP/IP stack. These are so incredibly complex that you really REALLY don't want to mess around with MOVs or PUNPCKLBWs, for that matter.

On the other hand, I cannot advise not using it either. It's near impossible and not recommendable either. It has its uses, but until you realise that it's not that suited for huge projects, but rather speeding up things that you have, and are slow, then you'll get the full benefit.

You also get a more or less free comparison function for the harder ASM things, so you get a lot easier testing.

Instances where I WOULD recommend ASM usage, after testing (that is, these are the places I think most OSes could benefit most from asm optimization):

TCP checksum generation
File checksum generation
Encryption
Compression
Stream handling
Bitfield handling (more because the defacto compiler (gcc) really sucks at making bitfield code)
Page zeroing (GCC generates a 4-opcode sequence in which each instruction relies on the one before)

These aside from the obvious places such as task switching and direct processor access. It's tedious to do them without.

If you really want to do a lot of ASM coding (or even only in these places), read up on optimizing, understand why some structures are slow in assembly, what you can do to speed it up, try some things in blank environments, and profile them for speed (just let a page zeroing algorithm zero the same page a billion times and check the time on your wrist watch, or better yet, a thousand times with a check on your TSC) to learn and understand what works good. Also, consider targetting one or more processors specifically, instead of the bunch of "all x86-compatibles from the 486 and up", it allows for some neat and quick optimizations (20% faster with SSE/3DNOW prefetch for instance)

Last bit, you don't have to be a wizard to be better than your compiler. You just have to be a wizard, or take the time to do it professionally (that is, profiling and testing each possible version, even though you're pretty sure it's slower).

C&CW, Candy

I guess that writing an entire OS in ASM wouldn?t be simple, but my kernel will be in asm. Later on i may write GUI/TUI and (more) drivers in C (with much inline asm.. ).
But the MenuetOS coders did it and so can i (if i wanted to).

/Christoffer

There are good and bad things that can be said for all programing languages.
But i must say that one of the miss conception's, is that programmers that do not use ASM have, Is that people that program in ASM, think that they are writing more efficient code, this is simple not the case (we do not think that we are writing more efficient code than the average C compiler).
The idea that ASM programmers may enjoy programming in ASM goes straight over there heads.

I have tryed most languages and the one that suits my personality is ASM, it is so logical.

My idea of a higher level language is closer to human than machine language , my idea of a lower level language is one that is closer to machine than human language.
Most of the time i find ASM closer to human language than say C(with words like mov, add, inc,sub, comperd to fseek, scanf, void) .

Some of us like useing ASM its FUN ;D

ASHLEY4

I see your point. But in everything I do, I try to achieve two things at once - I just have too little time on my hands to do anything but - and any ASM knowledge I'd pick up during OS development is most likely to be useless to me about anywhere else. C++, on the other hand, can (and does!) earn me a living.

ASM coders are sought for in the embedded industry... but they don't use i386...

And as for ASM being closer to human language... quick, show me an ASM equivalent that's more readable than "for (int i = 0; i < MAX; ++i);"...

...and what means "rlwinm", again?