OSDev.org

Oh well, they should know ASM while OSDeving

Nelson wrote: Oh well, they should know ASM while OSDeving

Sure, you need asm for some specific things, but my point was that no one wants to read through reams and reams of pages of assembler for the entire OS. C is a lot easier on the eyes (and brain).

Perhaps provide psuedo code with an ASM example?

Colonel Kernel wrote:

Nelson wrote: Oh well, they should know ASM while OSDeving

Sure, you need asm for some specific things, but my point was that no one wants to read through reams and reams of pages of assembler for the entire OS. C is a lot easier on the eyes (and brain).

Not always. Remember: "All the elegance and power of assembly language with all the readability and maintainability of assembly language." Now, of course, I happen to think that no language can make code readable if the author doesn't intend it to be, but C is still somewhat messy.

PASCAL is hard to read (:P)

Someone should write a tutorial which forwards people to either the Wiki or the Intel Docs.

Hi,

Nelson wrote:Perhaps provide psuedo code with an ASM example?

That would be the idea - psuedo code in Parts I and II with real code in Part III. The code in part III would be carefully selected to illustrate the content of the book - the guts of the single-CPU scheduler without any of the SMP/NUMA/hyper-threading detection code (for that they can see the full source on the CD).

Very well commented assembly would be used for machine specific code - all the boot code, the micro-kernel and half of the device drivers. A HLL would be used for portable code, but I haven't invented a language for that yet ..

The code itself wouldn't be designed for educational purposes either - instead it'd be realistic code designed to work, with explanations around the ugly bits.

For example, rather than using the CPUID instruction directly and hoping things work it'd have about 40 pages of CPU detection code which takes into account most manufacturer's features and errata, with several paragraphs explaining why using CPUID directly must be avoided for stable code.

The idea would be to present something that shows people how to write code that works on all computers, rather than something simple that only works when you're lucky.

@Colonel Kernel

IMHO being able to read assembly (and understanding how the CPU works) makes OS development much easier. An example would be taking EIP and the other registers contents from an exception report, disassembling your code, finding where it crashed, and then mentally converting the disassembly back into the C source code to figure out where the bug in the C source is.

Knowing assembly also helps for single stepping through code with Bochs (one disassembled instruction at a time), or comparing what the compiler generated to what you thought it should generate, and other things (e.g. writing emulators and/or your own development tools).


Cheers,

Brendan

Nelson wrote: PASCAL is hard to read (:P)

Someone should write a tutorial which forwards people to either the Wiki or the Intel Docs.

No language can make code readable if the author doesn't intend it to be.

Then all authors intend it to be hard to read! Actually I'm just kidding .

Boy, did I ever step into the troll hole.

Remember: "All the elegance and power of assembly language with all the readability and maintainability of assembly language."

OK, "well-written" C. Well-written assembler takes a lot longer for the human eye and the human mind to process than well-written C (or Pascal, or C++, or OCaml -- whichever).

Brendan wrote: @Colonel Kernel

IMHO being able to read assembly (and understanding how the CPU works) makes OS development much easier.

I'm not disputing that. I meant literally what I said -- not that many people are interested in reading through pages and pages of assembly, especially if they have to pay money to buy the book that explains it all in the first place. The Minix 2.0 source was bad enough IMO, but at least with Minix the C code acted as both the "pseudo-code" and the "real" code. Anything else is a duplication of effort (remember, we're talking about publishing a book here).

For example, rather than using the CPUID instruction directly and hoping things work it'd have about 40 pages of CPU detection code which takes into account most manufacturer's features and errata, with several paragraphs explaining why using CPUID directly must be avoided for stable code.

The idea would be to present something that shows people how to write code that works on all computers, rather than something simple that only works when you're lucky.

I think at that point you're crossing the line between teaching people concepts and just doing their work for them. If you intend to make your OS a commercial venture, you'd just be handing your competitors a big chunk of your advantage.

If I rant any longer, I'll end up opening the "why are we all doing OS dev" can of worms, so I'll stop now and get some sleep. ;D

Wow! How did I miss Brendans post!

On the topic of the CPUID, this isn't information which is new (afaik) so it can be obtained with a little research and implementation. I don't think they gain any significant advantage.

Code should be split into logic and then an example implementation. The logic would allow the person to understand how it works and why you would do x and what would be stored in y. Then if there is any trouble they have understanding it they can refer to an implementation and the combination of those two allows the user to further understand what he's doing.

@Brendan
Are you serious in writing this? I thought it was just a thought you had.

Hi,

Colonel Kernel wrote:

The idea would be to present something that shows people how to write code that works on all computers, rather than something simple that only works when you're lucky.

I think at that point you're crossing the line between teaching people concepts and just doing their work for them. If you intend to make your OS a commercial venture, you'd just be handing your competitors a big chunk of your advantage.

No - I'm a little more devious than that!

Part I would teach principles, Part II would be implementation details (mostly intended for any OS, with 80x86 specific psuedo code as examples).

Part III (in conjunciton with the slightly biased information in the first 2 parts) would make the reader familiar with my OS, so that they know everything they need to know to be good kernel hackers, device driver writers and applications programmers for my OS. ;D

As for handing competitors a big chunk of my advantage, did you know that my assembly to html utility handles "protected sections"? It actually does up to 4 sets html pages, censored and uncensored, multi-page and single-page.

For an example see:
http://bcos.hopto.org/latest/inc/i386as ... e_inc.html

The idea here is that the single-page censored version goes in the book itself (one chapter for each selected module), the multi-page censored version goes on the CD (all source), and the uncensored versions are for my own personal pleasure. ::)

Then there's the new "modular micro-kernel" design. This allows me to have (for example) a fully-fledged high performance scheduler as one module and a simple round-robin scheduler as another module. Full source for the round robin scheduler would be available, while large parts of the other scheduler could be supressed if I have a good enough reason. People would also be able to choose which scheduler to use when the OS is installed, which would be great for comparing the performance and behaviour of each.

Nelson wrote:On the topic of the CPUID, this isn't information which is new (afaik) so it can be obtained with a little research and implementation. I don't think they gain any significant advantage.

The CPUID instruction itself is simple enough. The problem is tracking down all the errata for the CPUs and working out which manufacturers use which flags for their own proprietory extensions.

Half the problem is that it's information that's old and no-longer available (especially for CPUs that don't support CPUID and CPUs where the manufacturer disappeared - UMC, NexGen, Cyrix, SiS, etc).

As a quick check, how long do you think it would take you to write code that detects if the CPU supports VIA's "Advanced Cryptogrophy Extensions", or find all the CPUs that support the CMPCHG8B but don't set the feature flag in CPUID because of a bug in Windows NT?

For the original version of this code I spent around 6 weeks researching and implementing it. In the last week or so I've got half of it into the new version of my OS, but I'm still working on cache detection and haven't even started going through errata properly.

It's extremely ugly (hasn't been commented/formatted or anything yet), but the "progress so far" is on my web page..

Code to detect the family, model, etc and find a CPU name:
http://bcos.hopto.org/latest/sys/i386/k ... cpuid.html

Code to figure out which features the CPU supports, and build a set of "standardized" feature flags:
http://bcos.hopto.org/latest/sys/i386/k ... tures.html

The beginning of the code to check for and fix CPU errata:
http://bcos.hopto.org/latest/sys/i386/k ... rrata.html

The beginning of code to detect CPU caches:
http://bcos.hopto.org/latest/sys/i386/k ... cache.html

Nelson wrote:Are you serious in writing this? I thought it was just a thought you had.

I'm serious about writing my source code with full explanations, etc, so that it could be used for Part III without much change, and if I knew I could get a book published I'd start working on Part I and Part II now.

I guess at the moment I'm seriously considering writing a book sometime in the future. It's likely I'll get the 32 bit 80x86 version of my OS working well first, then use the book as a way to attract interest in the OS.


Cheers,

Brendan

What about in PDF format .

I'm serious about writing my source code with full explanations, etc, so that it could be used for Part III without much change, and if I knew I could get a book published I'd start working on Part I and Part II now.

You could publish it with a print on demand service like lulu. I think that its free to get it sold on their site, or about US$125 to get a ISBN so you can order it from bookstores or on Amazon.com.

-Stephen