OSDev.org

Please give me break .
1. I did not say asm is more readable than C .
2. I said when i ran my test, i got the result that all persons tested got 3 of the asm right, none got the C right .

What i will say is C is not very readable to the nonprogrammer.

PS: C for boy, assembly for men , i will now go and hide

\\\\||////
(@@)
ASHLEY4.

allow me to guess the assembly ones:
The first one enabled protected mode but doesn't jump to anything so would be wrong. The second one switches on 800*600*24-bit color mode with linear frame buffer using the Vesa standard, v1.2 and up (not sure ). The third one seems to map/unmap the lowest page in the probable page table location using a word instead of a dword, and then invalidates the page containing dx (which would not assemble in 32-bit mode, and be horribly incorrect in 16-bit mode).

Not sure the test is entirely valid, but the point does carry along

ASHLEY4 wrote:2. I said when i ran my test, i got the result that all persons tested got 3 of the asm right, none got the C right .

Right, and when I ran my test, everyone got the C right and nobody got the ASM right. All this proves is that both of us were using extremely biased and utterly meaningless tests. If you want to spout nonsense, go ahead, but if you want to actually say something meaningful, use a test like the one I suggested (compare using code for the same functions).

What i will say is C is not very readable to the nonprogrammer.

With the expection of contrived or trivial examples, no programming language ever devised is very readable to the nonprogrammer. No calculus proof is very readable to a nonmathematician. No schematic is very readable to a nonengineer. Hmm. I could go on all day stating patently obvious truths, but why?

A more interesting fact is that C is a couple orders of magnitude more readable than ASM to minimally experienced programmers, and to the majority of experienced ones as well.

C is more legible without vast numbers of macros, just deal with it.

I'd also say that a lot depends on your familiarity with the language. I mostly use assembly, so reading through lengthy assembly routines doesn't really bother me at the moment. However when I switch to C (Which I know, but don't use very often) I often get confused over some incredibly trivial things until my memory of using it comes back. If someone put a non-trivial Fortran program in front of me (A language I used extensively about a decade ago) I'd be totally lost for a day or two.

I imagine if I stopped working with assembly for a few months and started using something else then my assembly code would look pretty damn confusing when I picked it up again (Which is the reasons I overcomment my code ).

There are really no new arguments in the language debate any more. It all boils down to using a language that you're comfortable with and which is appropriate to the task in hand.

Proposition: Let's use Lisp for everything, it's the easiest one to read.
Argument: Once you know the (op arg1 arg2 arg3 ...) syntax there's really nothing more in the surface syntax you need to know. We can argee to write '(quoted lists) as (quote (quoted lists)) and '(a b . c) as (quasiquote (unquote (ct-cons 'a (ct-cons 'b 'c))) and so on to avoid all the minor inconsistencies. The ct-cons version can be described trivially as: Indeed, I propose we develop a OSdev specific Lisp dialect in terms of itself (which we could all OCDTEL for "OSdev Common Documentation and Tutorial Language"), so as to avoid following anyone's subjective preferences.

Since I am probably subjective in proposing a Lisp dialect, we can use function{arg1|arg2|arg3|...} as syntax instead because I find it rather unlike that anyone would find THAT a personal preference, and the even whole (and holy) /.-readership knows that surface syntax is what defines a language, semantics being rather irrelevant trivialities.

So there you go. Let's not close this wonderful, warm (if not burning) discussion alive some more time. Anybody hasn't even brought up Nazis yet...

Right so we all agree asm is not the most readable progamming language, but it's the BEST!, i think i can go along with that.

\\\\||////
(@@)
ASHLEY4.

damn! are you guys still arguing on the language to be used for the tutorials ??

btw, pkd, i've just had a look at the "IDE r/w" tutorial so far ... i must say i'm a bit disappointed. There are mainly raw constants instead of symbolic EQUs, and very little text about what is to be done and how.

Despite the fact it's of highest interrest to read/write to an IDE drive, i feel that latter on miss the "tutoring" part ...

psuedo code is the best for tutorials... that way u let the reader do the actual coding, but give enought hints on how.

I think it's better to use pictures instead. First of all, one image tells more than a thousand Forth words, and second, that way you let the the reader do the actual thinking, not just copy-paste the pseudocode, and use that as a template. Art deco preferred today.

[ok, so I shut up]

I agree Pype.

I Just threw the IDE Read/Write to answer a question about IDE stuff, I will write better docs for it over the comming days now im finished with my floppy code (which will appesr tomorrow or so), which is much better documented.

I also take the point that i should you equates for port addresses so that it is easier to modify.

bye
pkd

hi again,
I have added full commenting to the routines in IDE_r/w as well as some extra explations in the HTML file. Im still not using equates but i will try adding them as i write more code, I think the commenting has greatly improoved the readability of the code and would like your further comments.

bye
pkd

Pkd, wish you had post you floppy tut a week a go, just nearly finished my floppy driver.
But lets face it, most people want you to give then code, so they can cut and past it, and as soon as no code is found in your tut, they are not interested.
But to me if you want to make a top tut, you best bet is see how Intel right them.
Of all the things that i have had to code, if Intel do a manual,
i find it much essayer to code.
eg: writing a floppy was easy compeared to a atapi driver.

\\\\||////
(@@)
ASHLEY4.

copy-pasters will sooner or later discover than copy-pasting will not bring them far (because pasted pieces from misc sources will not work together properly)

i consider having some working code that you can compile and run will give more credit tutorial: you found code that works and the guy wrote a text to explain *how* it works and *why* ... isn't it more interresting than just some guy explaining what is to be done in the abstract and you can't even ensure his technique will work on your system ?