Optimising compilers "efficient"?

[qw]

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.

[Casm]

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.

[Casm]

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.

[davidv1992]

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.

[Casm]

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.

[cxzuk]

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.

[JAAman]

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

[Solar]

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.

[JAAman]

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

[gerryg400]

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 )

[gerryg400]

This is the first version you published

Code: Select all

   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   83 ec 04                sub    $0x4,%esp         ; make room for local 'scratch' variable
   6:   8b 45 08                mov    0x8(%ebp),%eax    ; copy parameter (attrib) from stack to eax
   9:   88 45 fc                mov    %al,-0x4(%ebp)    ; copy parameter to scratch variable
   c:   0f b6 45 fc             movzbl -0x4(%ebp),%eax   ; zero extend back to eax
  10:   a2 00 00 00 00          mov    %al,0x0           ; copy al to vattrib (fixup required by linker)
  15:   c9                      leave  
  16:   c3                      ret    

This is the -O3 version

Code: Select all

   0:   55                      push   %ebp
   1:   89 e5                   mov    %esp,%ebp
   3:   8b 45 08                mov    0x8(%ebp),%eax    ; copy parameter (attrib) from stack to eax 
   6:   5d                      pop    %ebp
   7:   a2 00 00 00 00          mov    %al,0x0           ; copy al to vattrib (fixup required by linker)
   c:   c3                      ret    

This is the inlined version

Code: Select all

  10:   55                      push   %ebp
  11:   89 e5                   mov    %esp,%ebp
  13:   c6 05 00 00 00 00 07    movb   $0x7,0x0          ; copy immediate value to vattrib (fixup required by linker)
  1a:   5d                      pop    %ebp
  1b:   c3                      ret    

In all 3 cases the vattrib variable is actually written by an instruction that requires a fixup.