OSDev.org

Right now I am working on an Operating System, yet I dont know ASM and I find it hard, actually, impossible to write a bootsector without it... So, I am stuck either stealing code, which doesnt work, or learning assembly. What I would prefer is to just learn enough assembly to write the bootsector and get on with it. Its sort of like learning French because you have a two hour layover in Paris. Does anyone know how to do this? Also, I suppose any good assembly tuts out there would be nice. I tried Art Of Assembly, and it scares me, Adams Assembly Tuts are also relitively frightening.

I think learning by doing it the best way !
Just take a bootsector-code from another project,
and rewrite it. So you learn asm and to programm
an bootsector. Don't try to switch to protected
mode so fast. Just 'play' with some instructions ...

And ... you will need asm on some other placed in
our OS !!

Joerg

Where else would I need it?
jimferd

BTW, what langauges have you working in in the past, and what did you intend to use for your OS as the main language (I am assuming either C, C++, or some Pascal variant or descendant, as those seem to be the most popular, but there have been some Java and Basic adherents, and a few, such as myself, are intending to design languages of our own).

I would have to say that you would do better to take the time to learn assembly language carefully, to the point where you understand how it really works. Learning assembly language is important, IMAO, not so much for the ability to write applications or systems in it, but for the insight it gives into the operation of higher-level languages. Used judiciously, it can also give you an amazing ability to use small amounts of assembly code to leverage and optimize programs written in other languages (though I prefer to use separate assembly source files, as find inline assembly to be awkward at best).

While good tutorials do exist online, the best material on the subject which I know of is a book, _Assembly Language Step by Step_ (2nd ed.) by Jeff Duntemann (see http://www.duntemann.com/assembly.htm) for more details, and som e useful links). I would strongly recommend this book anyway, to *any* programmer, as it is one of the best introductory programming books I've ever seen - and stands in strong contrast to what I consider to be *the* best introductory programming books, _How to Design Programs_ (online at http://www.htdp.org/) and _Structure and Interpretation of Computer Programs_ (online at http://mitpress.mit.edu/sicp/), both of which take a virtually opposite approach by going to the highest levels of abstraction first. If you had the time, I'd suggest reading though both HTDP and ALSbS (and as much of the first of SICP as you can stand - I never got past the beginning of chapter four, myself) before continuing, even though neither of them are particular to systems programming. Together they would (I expect) give you a much broader vision of what programming can mean. However, that is assuming you have time and patience to swallow whole two dense texts and nibble at a third before you continue. I won't blame you for it if you lack this sort of superhuman restraint

For your purposes, I'd suggest that you pick a copy of ALSbS, skim the intro and the first three chapters (stopping to cover any unfamiliar ideas in detail), read chapters 4 and 6 very carefully and follow along on the excercises (you can skip chapter five unless you mean to use the NASM-IDE editor, in which case you should skim through it and use it for reference later), skim Appendix A, go back and follow along with the excercises in 7 through 11, and finally skim 12 and 13. A highlighter pen is useful, especially for the chapters you mean to skim; you'll want to mark anything you haven't seen before or didn't undertand, and then go over them again before moving on to the next section.

HTH. CCW.

ISRs, port I/O, paging, read/write CR?, multitasking, interrupts, and probably a bunch of other places I can't think of off-hand.

You should really have a good handle on assembly and low level system architecture before even attempting to write an OS.

Trust me, you'll feel a lot better/confident developing with a solid background.

Jeff

With all do respect, most of the operating systems that I have seen have been written soley in C, of course using an asm bootloader or gruB. I do not mean to doubt, but are you sure I cannot write the drivers I need in C...? I thought many of the drivers for devices used today like printers and cdrom drives were written in C or some variant thereof.

Yes, you can write a lot of stuff in C.
But for some things (try to enable or disable
the interrupts in C/C++...) you'll need ASM !
And the knowledge of the low-level asm will
help you to survive in your os prject !

Joerg

Ahh, yeah... you _can_ write drivers in C - from a driver developers point of view!  But you, being more enlightened, and from an operating system developers point of view, realize that each of those routines used to develop drivers encompass all the low level assembly language routines that _cannot_ be written in C.

Make no mistake, I don't lie, you will indeed need assembly for all the previous instances I've noted simply because ANSI C doesn't not provide adequate methods.

ISRs - can't iret in C!
port I/O - you'll have to write your own inportb/outportb, etc routines
paging - can't invalidate a page or load CR3 in C
read/write CR? - for page fault address, enter pmode, paging, etc
multitasking - can't jump to tss in C
interrupts - sti, cli

I can't believe people can make a parallel between osDev and writting a "guess the number" game.  osDev is not easy!  You'll need more than a good background in C and Asm...

Jeff

The vast majority of it can be written in C, yes - or in just about any other  compiled language (or even an interpreted one, as were the case with UCSD Pascal, Smalltalk-80, and the various Forth OSes), provided that the compiler isn't dependent on the features of a different OS (as is the case with VB) and that the resulting code runs at an exceptable efficiency.

There is, however, a small amount - perhaps 5% - that absolutely must be written in assembly (even discounting the boot loader), and another 5% or so in which you will probably want to use some assembly to optimize the 'hot spots' (performance-critical inner loops). Also, a strong knowledge of assembly language is useful, along with an understanding of your compiler's behavior, in order to know just what the system is really doing at all times. You should, at the very least, know how your compiler passes function arguments, and be able to read it's assembly output if it has an option for it.

So yes, even though only a small portion of the the OS needs to be hand-written in assembly, it is important to have a solid grounding in ASM in order to write your OS, even for the parts written in a high-level language. Studying up on assemblers, compilers and linkers is also a Very Good Idea before even starting an OS project, as well.

Thanks, all.
Ill learn assembly then

Say, has anyone done anything with Intel 386 Programmers Reference. It seems a good learning tool... either that or I printed 500 pages of worthlessness.

I actually just got volumes 1 - 3 in the mail a couple days ago (only took about 4 - 6 MONTHS!).  Been skimmin' through them now and then for definitions and what-not.

I find them a great reference, but to learn from, I still like the PC System Architecture Series from MindShare Inc. and my ol' Tasm 4.0 Blue Book

Intel's docs are notoriosly wholy, and "unkept", though.  I've already noticed a few errors, and the almost complete ommision of vm86 extensions (gotta go to Dr. Dobb's journal for that stuff...)

Jeff