Best way to "do" assembler in POIDE

[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]

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?

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.
 

[frankie]

EDIT: This message was intended for this thread http://forum.pellesc.de/index.php?topic=4644.0


While opininions are opinions and are always respectable, there some strictly technical points that are not opinable.
The theory of programming, the basic meaning of execution module, resources (memory & CPU) and speed of execution are well defined and clear.
The C language, altough it was born for 'system programming' (OS), is independent from a character output or a graphic one. The rules for good programming remains the same.
You can consider that most WIN programs use slow graphic output and bloated GUI interfaces so the effort to develop optimized code is not worth of, but this is a specifica case, the general programming rules remain unchanged.
If your icons shows up slow you can buy a most powerful machine, then the programmers will bloat more the OS adding more unusefull effects that in turn will slow again the machine, and so on....
The beginner should learn a programming language from the ground (whichever C compiler it's ok) to at least understood the meaning of variable name, its address and its value (so don't try to print the variable name as string....  ).
The WIN programming involves the concept of threads, concurrent processes, global data storage, access and synchronization, that are not basic concepts at all.
Everybody want make programs, nobody want waste time studying basic concepts..... 

[akko]

Thanks to everybody for their well-meant and correct suggestions. However I am not programming for Windows (I'd probably use C# for that) but my project comprises a virtual machine (with a multitasking Forth kernel) where speed IS important (eg when compiled for a controller as target system). The project in Pelles C is the prototyping and simulation tool for it. Nearly all controller board manufacturers provide a C compiler for their board, but I can develop and test the higher level stuff much better on a PC . Once the highlevel code runs, the bottom level connection to the "bare metal" of the board(s) is very much simplified, ie when you encounter bugs you can reduce your search space dramatically.

But speed is only one aspect. Other aspects comprise the limitations of the C language. Eg it does not really make fun to program "add with carry", or modulus arithmetics of large integer numbers (C anyhow is rather peculiar about modulus of negative numbers), or somesuch in C, when you could do it better in just a few assembler lines.

But this is not the topic here, thus back to the original question:
What is the best way WHEN one has to use assembler?

[CommonTater]

In my experience (which is admittedly limited) your best bet is to go all the way back to your original message and follow Pelle's advice... He wrote this stuff, nobody knows it better.
 
Again... be careful not to trip over the "premature optimization" thing. You say speed is important but are you shure it won't be just as fast in C?  There is no truth to the assumption that ASM is automagically faster and it hasn't been true since the nasty old days of Interpreters. 
 


 

[Bitbeisser]

Everybody want make programs, nobody want waste time studying basic concepts..... 

  Last week I couldn't spel progrimmer ... This week I are one!

c00l DuDe, mee 2....

Ralf 

[Vortex]

For those who have doubt about assembly, you are kindly invited to visit the the Masm forum.

[CommonTater]

For those who have doubt about assembly, you are kindly invited to visit the the Masm forum.

I have no doubt about ASM... I just try to keep things in perspective.  ASM has it's place and it's advantages... so does C... but speed wise, I don't see a really big difference.

[CommonTater]

c00l DuDe, mee 2....
Ralf 

ROFL 
 
 

[frankie]

Other aspects comprise the limitations of the C language. Eg it does not really make fun to program "add with carry", or modulus arithmetics of large integer numbers (C anyhow is rather peculiar about modulus of negative numbers), or somesuch in C, when you could do it better in just a few assembler lines.

Dear Akko this is *not* a limitation of C language, remember that the main value of 'C' programming is *to write portable code*.
This answers to your questions (it seems that you are making SBC development), the use of assembler inside a C module is discouraged because the code become no more portable on other platforms (different CPU specifically, but also different HW chips, address decoding, etc).
The correct use for professional development is to write all the portable code in 'C', and only small snippets in assembler.
This way you can write a multiple set of assembly snippets each for a different CPU then link the right one depending on the development HW.
The use of inline assemby is not uncorrect unless the whole module is used for a specific platform.
The practical example can be found in the abstraction modules (a well known one is the HAL=Hardware Abstraction Layer).
All your doubts can be solved looking i.e. at Linux sources, or whatever open source alternative OS, where you will find general (portable) code and platform dependent modules. The last are write in assembly or in mixed language.

[akko]

One should rename this forum section " DO NOT USE ASSEMBLER - IT IS BAD AND GIVES BAD HABITS "

 

[CommonTater]

One should rename this forum section " DO NOT USE ASSEMBLER - IT IS BAD AND GIVES BAD HABITS "

Well... to be fair, nobody has said anything like that.  In fact the ASM group wroking with POASM is quite active both here and on other forums. 

What we all seem to be trying to say in our own ways is that ASM, while certainly having a place in programming, is not some magic nostrum that can cure all your problems.  As Frankie correctly points out ASM is not portable code, you can't take the source for an x86 chip and compile it for ARM... which you can do with properly written C.  As I've tried to point out expecting that ASM is somehow faster or more optimal code is often a mistake since many C compilers produce machine code that rivels the best ASM output. 

Prototyping imbedded applications for Uc chips on x86 using C makes sense.  Not true with ASM.

If there's a lesson from this, it is:  "All things in their places".