OSDev.org

Casm wrote:Variables should be available to different parts of the operating system on a need to know basis, and in this case that means procedures involved in text output to the screen, and all living within a single file.

I totally agree, I just don't see why "set_foo(x)" is preferred above "foo = x", especially since we're discussing efficiency. There may be a reason for not having a "get_foo()" but I don't see it here.

Solar wrote:If your code doesn't work, it's the fault of your code, not the fault of the language or your toolchain. (Freak chances in the 0.01-per-mille range nonwithstanding.)

Especially with an operating system, where there is no nice source code debugger to help out, I will go with whichever language delivers the goods, and if that be assembly language - so be it. Pragmatism rules so far as I am concerned.

Hobbes wrote:

Casm wrote:Variables should be available to different parts of the operating system on a need to know basis, and in this case that means procedures involved in text output to the screen, and all living within a single file.

I totally agree, I just don't see why "set_foo(x)" is preferred above "foo = x", especially since we're discussing efficiency. There may be a reason for not having a "get_foo()" but I don't see it here.

A get_foo function can go in if there turns out to be a need for it, but I don't foresee any need arising, and, if there is no need, why write it?

Also, if the internal operation of set_foo needs to become more complicated in the future, there is no need for anything else in the system to worry about it.

If your C code doesn't work when optimized I would look into why that is, and not simply blame the compiler. Microsoft might not have the best name in code quality, the compiler will most likely be correct unless your doing very very weird stuff, since A LOT of the world's software is written using it. Switching to assembly just because you after 5 seconds decide it is most likely a compiler bug will get you into trouble, because it means you lack the both the self-awareness and drive to really look into a bug.

davidv1992 wrote:If your C code doesn't work when optimized I would look into why that is, and not simply blame the compiler. Microsoft might not have the best name in code quality, the compiler will most likely be correct unless your doing very very weird stuff, since A LOT of the world's software is written using it. Switching to assembly just because you after 5 seconds decide it is most likely a compiler bug will get you into trouble, because it means you lack the both the self-awareness and drive to really look into a bug.

Like I said, I go with what works. If the assembler code works, I don't much care why the C code doesn't. One advantage of assembler is that you can recognise the disassembly when you look at it, because it was you, and not a compiler, who wrote it. That being the case, it had better not involve you in many fruitless hours of staring at a disassembly when the C code doesn't work.

A LOT of the world's software is written using it.

And a lot of the world's software was written in an IDE, with a source code debugger built in. I have been programming in both C and assembler for about a quarter of a century, so I do know what I am doing.

Casm wrote:

Hobbes wrote:

Casm wrote:Variables should be available to different parts of the operating system on a need to know basis, and in this case that means procedures involved in text output to the screen, and all living within a single file.

I totally agree, I just don't see why "set_foo(x)" is preferred above "foo = x", especially since we're discussing efficiency. There may be a reason for not having a "get_foo()" but I don't see it here.

A get_foo function can go in if there turns out to be a need for it, but I don't foresee any need arising, and, if there is no need, why write it?

Also, if the internal operation of set_foo needs to become more complicated in the future, there is no need for anything else in the system to worry about it.

yes, its all about maintainability. consider a bank account balance. today its just a variable, tomorrow its calculated from a audit log. reading directly would mean changing code elsewhere.

i also believe its unusual not to have kind of checks involved in reads and writes.

check out uniform access principle.

Casm wrote:

Solar wrote:If your code doesn't work, it's the fault of your code, not the fault of the language or your toolchain. (Freak chances in the 0.01-per-mille range nonwithstanding.)

Especially with an operating system, where there is no nice source code debugger to help out, I will go with whichever language delivers the goods, and if that be assembly language - so be it. Pragmatism rules so far as I am concerned.

i think you completely missed Solar's point here:

your code is wrong it really doesn't matter if you wrote it in C, or ASM, or hickbacknoggingclin... your code doesn't work when using optimizations because you told the compiler to do something different than you intended

lets look at a summery of this thread:

optimizing compilers are bad because this code is not optimized

--(what switches did you use? are you telling the compiler to optimize the code?)

i used /Ot

--(this is an old switch, that should never be used, and does not tell the compiler to optimize the code)

well, i tried to use the correct switch to optimize the code, and it showed that there were bugs in my code, so i stopped using it

--(if you have bugs in your code you should fix them)

exactly, thats why i use ASM and forget about C when doing OSdev

...
my next question then is, why are you blaming the compiler for not optimizing the code when you dont tell it to, and why are you blaming the language for the bugs in your code?


in all honesty, what his function is doing and why he chooses to do it in that way, is rather irrelevant, its his code, he should be able to do it any way he wants, the point is, he is blaming the compiler for his own mistakes

Since I had my hands in this thread, let it be said that I have no problem if Casm makes the decision to write in ASM if it floats his boat.

But he should be aware that he makes this decision because of his relative skill in ASM and C, and because of personal preferences.

Sometimes, people walk away from such a decision and don't take care when making statements about their reasons, going from "I can't do hardware programming in C" to "you can't do hardware programming in C"... that's what I wanted to avoid here.

solar's reply just now made me rethink my post... i want to clarify that i don't have any problem with using ASM, but "i use ASM because there was a bug in my C code" is certainly not a reason to create a thread against optimizing compilers in general... that is all i was trying to say

Berkus, that code looks fine. It's reading/writing from above and below the ebp (which contains a copy of the function's original esp) to access the parameter and a hidden local variable. No problem with that.

Now to the main point. Inlining this type of function (as GCC will do if the code is available) will make the C code much faster than calling an assembly routine to modify the static variable.

Which proves that C is always better than ASM. (just kidding )

This is the first version you published This is the -O3 version This is the inlined version In all 3 cases the vattrib variable is actually written by an instruction that requires a fixup.