There are some semantics that C simply does not simplify. You are ultimately writing it to produce assembly (well, machine code).
SIMPLY FORTRAN AUTOCOMPLETE FUNCTIONS CODE
Which leads to a deeper truth: you are not writing C code for any high level purpose. Because inevitably, you will find a problem, where what you thought you were writing is not what you get. But the translation process is still pretty straightforward, and it's easy to see what's going on. On -O3 or so, many extraneous instructions are culled, and others are grouped for time/size savings. Nothing in common is saved between blocks, they fully stand alone.
Understand that, on -O0, it simply translates statements into blocks of instructions.
Other reasons: Even if you don't have a single care in the world to ever write a single opcode, You should still know assembly so that you understand the compiler output. The best example of loading external functions would simply be a bootloader. But, since you're limited to what's loaded in PROGMEM anyway, it doesn't make much difference. There's no recursion problem that can't be solved in this way.) Dynamic linking comes to mind as another one of those "high tech" approaches (so to speak not that it's anything new at all). (Of course if you're doing recursion, it adds up, but you probably shouldn't be doing semantic recursion on the AVR with what little RAM it has, anyway iterate over an array instead. Tail calls don't exist (i.e., return by way of a different function), but that's usually only a special case for recursion semantics and you can call it from the head at the cost of only one additional stack level. Well, you can do that in C with an array of voids, too. So if you want to go beyond simple tasks like the above then maybe consider learning to program in c or basic and skip over the assembly language option. Most people seem happier with higher level languages because you can do all the above with a few lines of code and let the compiler do the rest. Within these boundaries I think assembly code is ideal but go much beyond this and it quickly becomes difficult, especially if you want to start dealing with complex equations and floating point numbers. Also, it's easy to write efficient assembly code to control LCD or LED displays and to work with 2D or 3D lookup tables (with interpolation). These devices could be other ICs or they could be a complicated system that has a data IO port that I can tap into with the AVR. A typical use for me would be to decode stuff or to communicate with or to program or to control other devices. I like writing assembly code for AVRs but I tend to just do fairly simple stuff. I think a lot depends on what your ultimate expectations are.
0 kommentar(er)
