Anyone else think assembly is (mostly) useless?

[AlfBaz]

Please raise your hand if you think assembly is useless and you know nothing about it 

[amspire]

Micrcontroller assembly is for when management refuse to do the project properly and want a cheap 'patch job' instead.
- More code needed in an already full micro.
- More speed from existing micro instead of using a newer/faster one.
- Substandard micro selected for the job due to price.

I find this totally weird.

It is good engineering to get the maximum performance out of a part. If you can save 20c on a micro by using assembler, that is good design. C is good. Assembler is good. Well written assembler is better then badly written C.

I have done a number of micro jobs where the performance depends totally on a small interrupt routine that has to be optimized for clock cycles. Using assembler can reduce the clock cycles sometimes by 10%, but sometimes by over 50% and that is huge. It means by using assembler, you can often double the speed of your hardware if the interrupt is the bottleneck.

If a micro can do the job if assembler code is used, how can it be a "substandard" micro? That is like calling a LM324 a "substandard opamp" just because there are better ones that cost several times more.

I think what you are referring to is substandard engineering where the solution is to spend more money on components to compensate for the lack of design skills.

[Ed.Kloonk]

I have done a number of micro jobs where the performance depends totally on a small interrupt routine that has to be optimized for clock cycles. Using assembler can reduce the clock cycles sometimes by 10%, but sometimes by over 50% and that is huge. It means by using assembler, you can often double the speed of your hardware if the interrupt is the bottleneck.

I have only limited ASM exp. from only getting other's code to work on a desktop. But can't you inject ASM into C?

The only micro I program is arduinos from that awful IDE for small hobby projects, but I would have thought for serious micros, you'd write everything in C for cross platform swap-ability on micros and drill down on the bottlenecks.

That's how I was taught. Don't waste time on optimising for bottlenecks you envisage because the real ones you don't think about are the ones that get you.

I only speak a little of x86, can any of you tell me how much difference in dialect the new micros are with each other and also with ARM?

I want to know if you can build a collection of your own routines in ASM like you do in C, but I wonder how you'd switch to different CPUs.

Or is the normal use of ASM in microcontrollers just moving regs to/from input/output pins?

[caroper]

I confess I have not read the whole thread so I will not comment on the relative merits of C vs Assembler, I am sure there are many excellent post on that already. What I would like to do I point out that Assembler is certainly not redundant, in fact it is critical to the C programmer.


The C compiler is really just an Assembly Language pre-processor, in the same way that C++ is a C language pre-processor.


The C compiler produces Assembly language out put which the linker combines with Object Files (also assembler even if generated in C)  to assemble the final code.


Saying that Assembler is useless because you use C is the same as saying your car needs no Gearbox because you have automatic transmission.


The need to lean Assembly language may not be as great as it once was, in the same way that you don't have to learn to use a manual gear shift and clutch, but is Assembly Language Redundant? not until CPU architectures change dramatically, no.


Cheers
Chris

[BravoV]

Edit: I made a quick video on this topic. Not, by any means, a thorough comparison of assembly and C code, but it shows that while knowledge of assembly is very useful, often the compiler will do a good enough job (with well written code) that you don't need to use it.

...video...<snip>...

I'm really surprised that you updated your 1st post with that new video as an example to emphasize what are you trying to say after all replies you've received here. 

[mikeselectricstuff]

It is good engineering to get the maximum performance out of a part. If you can save 20c on a micro by using assembler, that is good design.

Only if the volumes are such that the cost saving in production is more than the cost of the additional development time.
Engineering is about the whole picture, not one detail.

[mikes]

So, while I think it's very beneficial to know assembly, I have never found a place where it was necessary to use assembly in a real design.

Then you've never worked on a real time system where one needs to count cycles. Or had to fit a new feature into a fixed space (anything a compiler can do, an assembler can do better, but probably with more difficulty).

If someone doesn't understand/use assembly, it in no way makes it "useless," any more than prepackaged sliced bread makes flour and knives useless.

[flynnjs]

My analogy is that assembly is like a scissors and high level language is like shears.
You can make a more accurate hair cut with scissors.
You can shave your head quicker with shears.

Some people want a nice styled haircut, others just want a quick method to rid excess hair.

Selecting a language is an engineering choice and good engineers think
commercially not just technically (real ones, not just hobbyists).

PS:  Not trying to pick a %-B with anyone who grows their hair longer 

[jpb]

accuracy depends on the scale of the project.

I'd say assembler is more like a small pair of scissors that you get on a pocket-knife - good for trimming your eyebrows but larger scissors (higher level language) will do a better job on a complete haircut!

In the same way, I'd trust code for something large and complex more if it was written in c than in assembler simply because the volume of assembler code would be a lot more and harder to follow so more chance of human error.

[amyk]

I wish all the best to anyone implementing TCP/IP protocol in assembly (if you are up for the challenge, shoot for a web server).

Or how about a whole operating system complete with network support?

One thing I've noticed (on non-embedded platforms) is that learning order is significant; those who start with Asm and then work their way up to some HLL like C also tend to write more efficient HLL code, while those who start with a HLL and then have to use a small bit of Asm for whatever reason tend to write it much like a compiler would, i.e. not very well and they have to go back and do even more work to optimise it. Those who say a compiler can easily beat a human in size or speed are probably comparing to the latter, and in that case I'd agree, but the former, starting with knowing how to do things that HLLs can't, will win easily.

[AlfBaz]

It strikes me that many of the comments here are by people who don't really know what it is to do a major project in assembly.

Following it would be easier than you think. It would nearly all be written with macros, its not uncommon for a proper assembly programmer to have massive libraries of macros and custom pre-processor directives, you would be amazed at the crafty techniques utilising the compilers' pre-processor.

Encapsulation, data hiding, type checking and a lot of the other HLL paradigms have been around since programming began, only you had to implement them yourself. As HLL's progressed, more and more of these OOP principles where added and developed and they became more strict to prevent silly mistakes

As computers became more prevalent, people and businesses started to rely on them more and more it became unacceptable to have a rogue program taking down the whole system. So OS's became more robust and more restrictions placed on what software could and couldn't do. CPU's with privileges and terms such as ring 0 ring 1 etc would prevent user software "hitting the metal".

Programming languages have also taken this road but in the embedded world, many times the only thing running is your software and the only underlying "system" is the programming environment. It's effective not only at compile time but also at run time.
HLL's seem to offer a far more robust environment but it comes at a cost and you can find yourself writing a lot of code to get around some language restriction to achieve something can be accomplished with a hand full of assembly instructions. In these circumstances, ignore assembly at your own peril.

[kt315]

I wish all the best to anyone implementing TCP/IP protocol in assembly (if you are up for the challenge, shoot for a web server).

Or how about a whole operating system complete with network support?

One thing I've noticed (on non-embedded platforms) is that learning order is significant; those who start with Asm and then work their way up to some HLL like C also tend to write more efficient HLL code, while those who start with a HLL and then have to use a small bit of Asm for whatever reason tend to write it much like a compiler would, i.e. not very well and they have to go back and do even more work to optimise it. Those who say a compiler can easily beat a human in size or speed are probably comparing to the latter, and in that case I'd agree, but the former, starting with knowing how to do things that HLLs can't, will win easily.

I never said it is impossible, it is just impractical. You can do this as well, except there are more efficient ways to do it. There is nothing wrong with that while you are doing it for fun. If you are aiming for results, it is just not the best way to do it.

And regarding optimization a compiler can do, I would not discard it so easily. I know I am going to open a new can of worms, but embedded development tools are still at its infancy. It looks exactly as desktop software development looked in 1995: there is a ton of compilers each with it is own idiosyncrasies, and "ANSI C" support is considered to be a major features (as oppose of lack of thereof being considered as a design flaw). "Michrochip releases a graphics library"!!! Yay! We can now draw a line ... again. And we have a bunch of widgets, all of which look like Win 3.11. We still publish API documentation in PDF, and distribute software libraries in source form as windows installers. There are sure other companies out there, but they are not far ahead in terms of software development support ...

[andyturk]

Edit: I made a quick video on this topic. Not, by any means, a thorough comparison of assembly and C code, but it shows that while knowledge of assembly is very useful, often the compiler will do a good enough job (with well written code) that you don't need to use it.

Just watched a couple of your videos. Nice work!

BTW, I don't think the compiler inlined your bit flipping code because the main program didn't "see" the function definition. If you put the definitions in the .h file with the 'inline' keyword, then the compiler has a choice to generate a call or expand it like a macro. The PSoC IDE probably doesn't work that way, so you'd have to jump through a few hoops to actually inline generated functions.

Newer versions of GCC (which is probably the compiler used in Cypress' stuff) support Link Time Optimization (LTO) which lets the linker have a crack at inlining small functions. I've never tried it though.

[jmole]

Edit: I made a quick video on this topic. Not, by any means, a thorough comparison of assembly and C code, but it shows that while knowledge of assembly is very useful, often the compiler will do a good enough job (with well written code) that you don't need to use it.

Just watched a couple of your videos. Nice work!

BTW, I don't think the compiler inlined your bit flipping code because the main program didn't "see" the function definition. If you put the definitions in the .h file with the 'inline' keyword, then the compiler has a choice to generate a call or expand it like a macro. The PSoC IDE probably doesn't work that way, so you'd have to jump through a few hoops to actually inline generated functions.

Newer versions of GCC (which is probably the compiler used in Cypress' stuff) support Link Time Optimization (LTO) which lets the linker have a crack at inlining small functions. I've never tried it though.

Thanks!

The .h file with the function is eventually included (through some series of files) into main.c.  I am wondering if it's because the inline keyword wasn't used in the definition.

[andyturk]

The .h file with the function is eventually included (through some series of files) into main.c.  I am wondering if it's because the inline keyword wasn't used in the definition.

It seems unlikely that the function definition (i.e., the stuff between the {}'s) would be in the .h *without* being declared inline. Doing that usually leads to multiply defined symbols because every file which includes that .h will generate code for the function. The inline keyword not only tells the compiler that it *might* want to expand the function in-line, it also tells the linker not to complain if there are multiple definitions at link time. The main thing to remember is that 'inline' is only a suggestion. The compiler can still emit a function call if it thinks expanding it would be too complicated or incompatible with other compiler options.

All of which goes to show that knowledge of assembly/machine language is pretty useful, but writing a lot of it yourself might not be as good as understanding what your compiler is doing to your code.

[jmole]

It seems unlikely that the function definition (i.e., the stuff between the {}'s) would be in the .h *without* being declared inline. Doing that usually leads to multiply defined symbols because every file which includes that .h will generate code for the function.

This is what header guard defines are used for.

The inline keyword not only tells the compiler that it *might* want to expand the function in-line, it also tells the linker not to complain if there are multiple definitions at link time. The main thing to remember is that 'inline' is only a suggestion. The compiler can still emit a function call if it thinks expanding it would be too complicated or incompatible with other compiler options.

All of which goes to show that knowledge of assembly/machine language is pretty useful, but writing a lot of it yourself might not be as good as understanding what your compiler is doing to your code.

Very true, and cuts straight to the point of this discussion. You gotta know what your tools are doing to really know if assembly is a worthwhile undertaking.

[andyturk]

This is what header guard defines are used for.

Not really. Consider the following:

header.h

Code: [Select]

#ifndef _HEADER_H_
#define _HEADER_H_

void my_function() {
  // yada yada
}
#endif // _HEADER_H_

foo.c

Code: [Select]

#include "header.h"
#include "header.h"

void foo_fn() {
  // yada yada
}

bar.c

Code: [Select]

#include "header.h"
#include "header.h"

void bar_fn() {
  // yada yada
}

foo.c and bar.c will be compiled separately. Each .c includes the .h twice, but gets exactly one definition of my_function() because of the include guard. Thus, each .o file will also have object code for my_function().

When you link the .o files into the same executable, the linker will complain that my_function() has multiple definitions. However, if you add 'inline' to the definition in header.h, the inline property carries through to the object code and the linker will simply pick one definition and ignore the others.

For C++, the inline behavior is implicit in member functions defined within the class declaration. That's how you can include gazillions of function definitions from STL header files without getting linker errors.

[jmole]

This is what header guard defines are used for.

Not really. Consider the following:

header.h

Code: [Select]

#ifndef _HEADER_H_
#define _HEADER_H_

void my_function() {
  // yada yada
}
#endif // _HEADER_H_

foo.c

Code: [Select]

#include "header.h"
#include "header.h"

void foo_fn() {
  // yada yada
}

bar.c

Code: [Select]

#include "header.h"
#include "header.h"

void bar_fn() {
  // yada yada
}

foo.c and bar.c will be compiled separately. Each .c includes the .h twice, but gets exactly one definition of my_function() because of the include guard. Thus, each .o file will also have object code for my_function().

When you link the .o files into the same executable, the linker will complain that my_function() has multiple definitions. However, if you add 'inline' to the definition in header.h, the inline property carries through to the object code and the linker will simply pick one definition and ignore the others.

For C++, the inline behavior is implicit in member functions defined within the class declaration. That's how you can include gazillions of function definitions from STL header files without getting linker errors.

That's why you define functions in a .c file, rather than a header. PSoC Creator does this with it's generated source files, as well. The declaration is in whatever.h, the definition is in whatever.c

[c4757p]

That's why you define functions in a .c file, rather than a header. PSoC Creator does this with it's generated source files, as well. The declaration is in whatever.h, the definition is in whatever.c

Anyone who puts functions in a header should have his hands cut off.

Hyperbole? What hyperbole?

[marshallh]

[andyturk]

That's why you define functions in a .c file, rather than a header.

Anyone who puts functions in a header should have his hands cut off.

Guys, if you want your compiler to inline for you, it has to see the actual function definitions. Conversely, splitting the definition from the declaration in the typical way *prevents* inlining:

silly.h

Code: [Select]

int plus_one(int x);

silly.c

Code: [Select]

int plus_one(int x) {
  return x+1;
}

main.c

Code: [Select]

#include "silly.h"
#include <stdio.h>

int main(int argc, char *argv[]) {
  printf("the value is %d\n", plus_one(10));
  return 0;
}

The compiler *has* to emit an actual function call to plus_one() because it can't inline a function it hasn't seen.

If you want the compiler to inline, then put the entire definition of the function in the .h file.

silly2.h

Code: [Select]

inline int plus_one(int x) {
  return x+1;
}

If you're using a C99 compiler, you (somewhat perversely) have to put an extern definition in exactly one .c file to make sure there is an actual non-inline implementation:

main2.c

Code: [Select]

#include "silly2.h"
extern int plus_one(int x);

int main(int argc, char *argv[]) {
  printf("the value is %d\n", plus_one(10));
  return 0;
}


PSoC Creator does this with it's generated source files, as well. The declaration is in whatever.h, the definition is in whatever.c

And that's why the GPIO calls in the bit bang example weren't inlined.

Generally speaking, inlining in straight C is a pain in the neck because different compilers do it different ways. It's much easier to get the same effect in C++ with inline member functions.

[c4757p]

Guys, if you want your compiler to inline for you, it has to see the actual function definitions. Conversely, splitting the definition from the declaration in the typical way *prevents* inlining:

True. It was an intentionally kneejerk-ish response meant to be a joke, coming from someone with mostly PC programming experience (where inlining functions really isn't a big deal). MCU programming is indeed the Land of Intentionally Broken Rules.

[c4757p]

As a bit of an aside, a long time back I had a pet project (never finished) - a sort of "modernized" C-like programming language and compiler. It could inline across compilation units - both shared libraries and unfinished (not linked yet) object files had a serialized, compressed version of the parse tree for any inline functions, to be quickly grabbed by a compiler and embedded as an inline function into the current compile unit.

[andyturk]

As a bit of an aside, a long time back I had a pet project (never finished) - a sort of "modernized" C-like programming language and compiler. It could inline across compilation units - both shared libraries and unfinished (not linked yet) object files had a serialized, compressed version of the parse tree for any inline functions, to be quickly grabbed by a compiler and embedded as an inline function into the current compile unit.

Seen this? Looks interesting, but I haven't tried it yet.

Also interesting is LLVM/Clang because the linker is the part of the system that emits actual machine instructions (and it has all the definitions to look at).

[jmole]

And that's why the GPIO calls in the bit bang example weren't inlined.

Generally speaking, inlining in straight C is a pain in the neck because different compilers do it different ways. It's much easier to get the same effect in C++ with inline member functions.

nice explanation, thanks!