Pelles C forum

Assembly language => Assembly discussions => Topic started by: akko on July 25, 2012, 10:34:38 PM

Title: Best way to "do" assembler in POIDE
Post by: akko on July 25, 2012, 10:34:38 PM
[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)
Title: Re: Best way to "do" assembler in POIDE
Post by: Stefan Pendl on July 26, 2012, 04:26:49 AM
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.
Title: Re: Best way to "do" assembler in POIDE
Post by: akko on July 26, 2012, 07:12:34 AM
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?
Title: Re: Best way to "do" assembler in POIDE
Post by: Bitbeisser on July 26, 2012, 07:32:05 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?
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
Title: Re: Best way to "do" assembler in POIDE
Post by: CommonTater on July 26, 2012, 10:09:57 AM
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.
 
Title: Re: Best way to "do" assembler in POIDE
Post by: frankie on July 26, 2012, 10:48:25 AM
EDIT: This message was intended for this thread http://forum.pellesc.de/index.php?topic=4644.0 (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.....  :(
Title: Re: Best way to "do" assembler in POIDE
Post by: akko on July 26, 2012, 04:53:28 PM
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?
Title: Re: Best way to "do" assembler in POIDE
Post by: CommonTater on July 26, 2012, 05:48:35 PM
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. 
 


 
Title: Re: Best way to "do" assembler in POIDE
Post by: Bitbeisser on July 26, 2012, 06:17:22 PM
Everybody want make programs, nobody want waste time studying basic concepts.....  :(

:D  Last week I couldn't spel progrimmer ... This week I are one!
c00l DuDe, mee 2....

Ralf  ;)
Title: Re: Best way to "do" assembler in POIDE
Post by: Vortex on July 26, 2012, 07:38:02 PM
For those who have doubt about assembly, you are kindly invited to visit the the Masm forum. (http://masm32.com/board/index.php)
Title: Re: Best way to "do" assembler in POIDE
Post by: CommonTater on July 26, 2012, 11:45:16 PM
For those who have doubt about assembly, you are kindly invited to visit the the Masm forum. (http://masm32.com/board/index.php)

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.
Title: Re: Best way to "do" assembler in POIDE
Post by: CommonTater on July 26, 2012, 11:46:27 PM
c00l DuDe, mee 2....
Ralf  ;)

ROFL  ::)
 
 
Title: Re: Best way to "do" assembler in POIDE
Post by: frankie on July 27, 2012, 02:35:56 PM
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.
Title: Re: Best way to "do" assembler in POIDE
Post by: akko on July 27, 2012, 04:43:33 PM
One should rename this forum section " DO NOT USE ASSEMBLER - IT IS BAD AND GIVES BAD HABITS "

 ;D

Title: Re: Best way to "do" assembler in POIDE
Post by: CommonTater on July 27, 2012, 05:23:51 PM
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".



Title: Re: Best way to "do" assembler in POIDE
Post by: frankie on July 28, 2012, 10:36:31 AM
I don't know what happen to my browser, but it removed the post from Tater.
I report it below.
Sorry.

Common Tater
Everybody want make programs, nobody want waste time studying basic concepts.....  :(

:D  Last week I couldn't spel progrimmer ... This week I are one!
Title: Re: Best way to "do" assembler in POIDE
Post by: Vortex on July 28, 2012, 10:46:10 AM
[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.

Hi akko,

I guess you didn't interpret correctly Pelle's statement. Mixing C and inline is not recommended as this will degradate performance. The reason is that inline assembly will interfere with the C\C++ compiler's optimization engine.
Title: Re: Best way to "do" assembler in POIDE
Post by: CommonTater on July 28, 2012, 11:11:57 AM
I don't know what happen to my browser, but it removed the post from Tater.
I report it below.
Sorry.

Common Tater
Everybody want make programs, nobody want waste time studying basic concepts.....  :(

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


No worries, I was just making a joke, it's not like anything important was lost.
Title: Re: Best way to "do" assembler in POIDE
Post by: JOE++ on January 09, 2015, 06:25:08 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?
Well, what do you REALLY gain using assembler?

Ralf

Have you programmed in serious assembly before?
Title: Re: Best way to "do" assembler in POIDE
Post by: Bitbeisser on January 09, 2015, 07:01:17 PM
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?

Ralf

Have you programmed in serious assembly before?
Yes, ever since I got started with programming back in 1976. 6502, Z80, x86, 6809, 68k, ...

Ralf
Title: Re: Best way to "do" assembler in POIDE
Post by: JOE++ on January 10, 2015, 01:58:17 AM
Yes, ever since I got started with programming back in 1976. 6502, Z80, x86, 6809, 68k, ...

Ralf
[/quote]

Good for u. Then u should know programmers can GAIN a lot by doing some things in assembly. In fact, for the part where you said assembly is buggy, it is the other way around. C programmers often rely on assembly / debugger listing to find their hard-to-trace bugs. Not the other way around. My assembly library is strong enough to make my C program skip <stdio.h> and <math.h> entirely and I still get twice the speed and half the size of typical C program relying on those two standard headers. That's a big GAIN especially on embedded system.

It is not good to give people misleading statements when in the end C is compiled to machine binaries anyway.
Title: Re: Best way to "do" assembler in POIDE
Post by: Bitbeisser on January 11, 2015, 06:18:09 AM
Quote
Yes, ever since I got started with programming back in 1976. 6502, Z80, x86, 6809, 68k, ...

Ralf

Good for u. Then u should know programmers can GAIN a lot by doing some things in assembly.
As with a lot in life, "it depends"...
Quote
In fact, for the part where you said assembly is buggy, it is the other way around.
Please quote the sentence where I said that!
Quote
C programmers often rely on assembly / debugger listing to find their hard-to-trace bugs. Not the other way around. My assembly library is strong enough to make my C program skip <stdio.h> and <math.h> entirely and I still get twice the speed and half the size of typical C program relying on those two standard headers. That's a big GAIN especially on embedded system.
You are comparing apples and oranges here.
Yes, in some cases, you can gain some benefit from programming in assembler, for certain, limited use cases. And as far as embedded programming goes, I have done my fair share of this and rarely bother with assembler these days. For example, for the popular Arduino boards which use the 8bit Atmel AVR RISC micro-controllers, you barely gain anything by using assembler, as Atmel designed the chips and their instruction sets right from the start with view on allowing a C compiler to produce the most optimal code by consulting a C compiler developer company (IAR in Sweden (http://www.iar.com/Products/IAR-Embedded-Workbench/AVR/)) during the initial chip design phase. And the GCC based AVR compiler used by Arduino is producing pretty identically optimized code. Trying to get a couple of bytes here and there is a waste of time and energy in that case.
Quote
It is not good to give people misleading statements when in the end C is compiled to machine binaries anyway.
Why is it "misleading"? You use the best tool for the case. And in a lot of cases (and in case of Pelle's C, and that includes POIDE) when programming for Windows based code, you can rather gain a lot more by concentrating on your program concepts and the algorithms used rather than trying to do things in assembler. That applies to personal use cases and even more so for anything serious/professional.

It is rather a myth that assembler is always better/faster/more efficient...

Ralf
Title: Re: Best way to "do" assembler in POIDE
Post by: jj2007 on January 11, 2015, 10:35:27 AM
It is rather a myth that assembler is always better/faster/more efficient...

- "faster": It is a myth that C compiler can produce code that is as fast as hand-crafted assembler code; in the Masm32 lab, we typically get a factor three on CRT routines. However, there are examples where the CRT can compete - and if you look under the hood, you may find out that the compiler found by accident exactly the same sequence as the experienced assembler programmer ;-)

- "better": Difficult to define, but code size is definitely much smaller. OTOH, maintenance is more difficult, unless it's your own code and it's well documented. Many people claim "portability" as an argument, but 1. x86 is everywhere nowadays, Mac and Linux included and 2. I have yet to see a truely portable hello world proggie that comes along with less than a megabyte for exe plus runtime/dll size.

- "more efficient": C programmers often claim that assembler takes a lot of time, but they judge by their own time, which is comparing apples and oranges. For myself, for example, it takes a lot of time to write a simple program in C, simply because I have a huge experience in assembler and little in C. For the great majority of coders, it's the other way round: huge experience in C but maybe only a few thousand lines in assembler. And obviously, for them C is "more efficient".

Besides, there is a bunch of idiots who insist that assembler must be the language that existed before Microsoft added macros to asm and called it MASM.
Title: Re: Best way to "do" assembler in POIDE
Post by: frankie on January 11, 2015, 12:19:10 PM
I would point-out that you are all right.  8)
As I said in a previous post the use of one language or another depends on the specific task. Using the motto borrowed from my americans collegues: "Use the right tool for the right job!".  ;D
JJ said that sometimes a compiler found the exact sequence that an experienced programmer would have used, this is not magic simply the process is the same for a human and the compiler: a well known code sequence have a well known assembly sequence. Who coded the compiler added the correct strategy for that case and that's all.  :)
Of course providing the compiler with all possible code variations optimized strategy is impossible, so maybe you want to consider the average...
The portability is an issue, consider the Linux OS, you can found kernels for almost whatever processor or hardware actually existing on the face of the earth. What if it would have been wrote all in assembler? Also in this case you'll find the demonstration that the assembler still is foundamental because some tasks cannot be done in 'C'. In fact looking at sources you'll discover many assembler modules. Of course that modules *must* be rewritten for each hardware they are intended to.

For the sake of portability some trials were made to create a 'portable' assembler, meta-assemblers that define an abstract instruction set that would be tailored to the target processor during compilation, but this is still a compilation and the result is not guaranted to be 1:1 with pure assembler.

Portability last frontier nowadays seems to be Java, that defines a virtual machine that runs on each platform.

Last we don't need to be foundamentalists of a language ... unfortunately there are too many of them out there ...  :-X
Title: Re: Best way to "do" assembler in POIDE
Post by: jj2007 on January 11, 2015, 02:35:38 PM
JJ said that sometimes a compiler found the exact sequence that an experienced programmer would have used, this is not magic simply the process is the same for a human and the compiler: a well known code sequence have a well known assembly sequence. Who coded the compiler added the correct strategy for that case and that's all.  :)

Who coded the compiler ... translates C source code to assembler, so they must be excellent assembler programmers ;-)
Title: Re: Best way to "do" assembler in POIDE
Post by: frankie on January 11, 2015, 03:04:38 PM
Who coded the compiler ... translates C source code to assembler, so they must be excellent assembler programmers ;-)
You're absolutely right!  ;)
Maybe we can consider that without excellent assembler programmers is hard to have good compilers...  ;D ;D
Title: Re: Best way to "do" assembler in POIDE
Post by: czerny on January 11, 2015, 05:52:54 PM
Btw. has meanwhile anyone answered the initial question 'Best way to "do" assembler in POIDE'?
Title: Re: Best way to "do" assembler in POIDE
Post by: Grincheux on March 19, 2015, 06:19:19 PM
A good IDE : PELLES or RADASM and an assembler ML32 or ml64.
After a good debugger is important too, MS has the best.