Assembly language > Assembly discussions

Best way to "do" assembler in POIDE

(1/6) > >>

akko:
[Pelle:] Mixing C and inline assembly code is almost always a bad idea; It will usually lead to the slowest and most bloated code. Using __declspec(naked) and writing the entire function body is better, but the best is to use a separate assembler.

Then what do you recommend, if not POASM???  FASM??  If yes, then how can it best be automated and debugged within the POIDE? How avoid the bloating? Although a bit bloated, won't it be faster at least? When I inspect the generated code by POCC, there nearly always seems to be room for further "hand optimization". (I like using the disassembler window in the POIDE debugger)

Stefan Pendl:
You can use POASM, but you shouldn't inline assembly code into C programs.

Keep the assembly code separate and include it through a library.

akko:
Source library of __declspec(naked) functions?
Then I have to push all arguments on the stack and/or use shared global variables to communicate with the caller. This slows down as well.

Precompiled objects for the linker?
How do I then communicate with say local variables of the caller?

I understand that Pelles C optimizer and new inliner can sometimes get "out of step" when it has to digest a chunk of asm statements. But when and how often is sometimes? What is the REAL penalty if you have just a few asm lines in your code? How do other C compilers behave?

Bitbeisser:

--- Quote from: akko on July 26, 2012, 07:12:34 AM ---I understand that Pelles C optimizer and new inliner can sometimes get "out of step" when it has to digest a chunk of asm statements. But when and how often is sometimes? What is the REAL penalty if you have just a few asm lines in your code? How do other C compilers behave?

--- End quote ---
Well, what do you REALLY gain using assembler?

Seriously, my experience with Windows programs is that there is barely anything gained as there is so much other fluff going on at the same time that any such assembler optimization is not worth the time you put into it and in fact might rather introduce more bugs that are harder to debug than a plain C (or C++, Pascal, <your favorite other compiler 'de jour'>) code.

Ralf

CommonTater:
Following up on Ralph's suggestion...

Let me toss in a little note of caution about "Premature Optimization".  I've seen some truly horrible syntactic concoctions created in the interests of optimizing otherwise workable code.  Most often the result is not a significant increase in performance.  Rather you end up with code that is painfully hard to maintain and update that runs about the same speed as well written standard code. 

When writing code I always ask myself: "If I have to come back to this in a year and make some changes, will I still be able to follow it?" ... If my response is anything except a resounding "Yes"... I need to write better code.

Also consider the time and effort spent optimizing... You can spend days --even weeks-- optimizing a few functions only to end up saving a few milliseconds when it runs.  This is neither economical nor sensible for any professional programmer.  Generally what I suggest is that if you need well written and maintainable code to run faster... buy a faster computer.

Finally, let me point out that ASM is not inherrently faster than compiled C (etc.).  If you take well written C code and well written ASM code and run them head to head, the result is almost always so close to a tie that the differences don't matter.
 

Navigation

[0] Message Index

[#] Next page