OSDev.org

Like title says, has anyone here done this? What are your feedback?

I write my OS entirely in assembly, and I think it is great.
I don't know other languages well, TBH. But I'm not even willing to learn C/C++; I'm very comfortable with assembly.
Pros:
- Smaller size files.
- (Probably) faster execution.
- More control over what goes on behind the scenes.

Cons:
- Not portable.
- Gets cluttered and unreadable with time.

I did and do write; though, the OS is not quite public yet. Well, it's just a tiny OS and lacks very basic features (yet), but it has a text-editor, FASM port, and 2048-like game--everything in an assembly language. Just drop me a PM, if you're interested.

(I'm not advertising anything here; the whole project is free and in public domain.)

Just as Omar, Assembly is the only language that I know good. Disadvantages are (1) Assembly is complex, though not hard (2) "real" OSDev'ers would hate you.

I write in assembly because I want to control exactly what instructions the CPU is executing. I want to be able to say that the CPU is running only what I have written, not some compiler's interpretation of what I have written.

I believe that trying to write an OS entirely in assembly is a classic beginner's mistake which most (eventually) grow out of. The advantages of using a high-level language are overwhelming; the advantages of assembly are overrated (and mostly wrong).

But don't worry - even some of the pioneers made this mistake (until they had written a suitable language).

onlyonemac wrote:not some compiler's interpretation of what I have written.

You sound like someone speaking language X not good enough and blaming someone speaking that language natively for not properly understanding you.

Maybe because of all flavours of braces failing on braille displays?

I think I'll write an operating system entirely in microcode. That way I'll be sure that the processor is doing exactly what I want it to.

iansjack wrote:I think I'll write an operating system entirely in microcode. That way I'll be sure that the processor is doing exactly what I want it to.

I actually considered this, until I learned that Intel doesn't allow you to update their microcode.

But if it weren't for that, I probably would have tried it.

Combuster wrote:Maybe because of all flavours of braces failing on braille displays?

Actually I don't have a braille display. But while C code is a pain to listen to with a screenreader, assembler is even more painful. Opcode mnemonics get slurred into their operands and unless you kind of know what you're expecting to hear you're going to be spending a lot of time pressing the arrow keys to read each line character-by-character. And you can show a brace character on a braille display but it's not easy to read, no, because it involves multiple braille characters in a row. But then, listening to C code without headphones generally just leads to my mother saying "why does it keep saying 'rat race'?" when she mis-hears "right brace" as "rat race" and refuses to shut up when I tell her to!

SpyderTL wrote:I actually considered this, until I learned that Intel doesn't allow you to update their microcode.

But if it weren't for that, I probably would have tried it.

I assume you would have acquired an adequate stockpile of CPUs, as it is rather easy to brick them by damaging the microcode.

onlyonemac wrote:I assume you would have acquired an adequate stockpile of CPUs, as it is rather easy to brick them by damaging the microcode.

Are you sure? I don't think microcode updates are persistent, so shouldn't a simple power cycle fix things?

I wrote a smallish OS in assembly before moving on.
http://ready4dis.8m.com/cgi-bin/i/PhatO ... 271105.JPG

32-bit, preemptive multitasking, virtual memory manager, keyboard, mouse, hdd, fdd, file system (fat), supported VESA (VBE). It wasn't to bad to write, came out to like 12kb total. With the font set and graphics it was a whopping 24kb. The GUI was written in C, the OS written in assembly. While it was a great learning experience, which is the reason I did it in the first place, I re-wrote it in C as I originally planned. I don't have any benchmarks, but I doubt the asm version is any faster in reality, and the fact that it's much easier (for me) to implement more advanced algorithms in C, the C version probably ended up faster in general due to a better design, and it's much easier to extend or use on other hardware. Of course, the C version ended up being much larger, but it also ended up with many more features (virtual file system, vs individual file systems, a better task scheduler, a command line as well as GUI, SMP, and 64-bit is working, but not done...). Could I write it all in asm, yes. Do I want to? No, it'll take a lot longer for little benefit in my opinion.

Kevin wrote:

onlyonemac wrote:I assume you would have acquired an adequate stockpile of CPUs, as it is rather easy to brick them by damaging the microcode.

Are you sure? I don't think microcode updates are persistent, so shouldn't a simple power cycle fix things?

Normally an "update" system is designed such that the device retains the latest version.

Actually I've just researched it some more and the updates are not persistant.

However it is certainly possible to update the microcode on an Intel CPU.