| ??? 08/24/09 16:30 Read: times |
#168520 - Some things depend on your point of view Responding to: ???'s previous message |
Per Westermark said:
Richard Erlacher said:
I've never encountered a memory leak in my ASM programming, and, with my preference for table-driven dispatch processes, I have little trouble tracking where things go under which circumstances. HLL's can, but don't necessarily, generate memory leaks because they use dynamic memory allocation which students are taught to use and otherwise essentially ignore, as an automatic feature. Without it, you don't see memory leaks. Did you not read what I wrote? Let me repeat myself: "if we ignore memory leaks etc that should not be applicable for most embedded systems". I don't expect people to need help tracking normal dynamic memory allocations (malloc() or new) in most embedded systems. If an embedded application do have problem with leaks, it is probably an application with threading and/or TCP or similar, where it may leak messages or TCP buffers or similar. These leaks can't be detected by normal memory allocation trackers, but a number of analysis tools can learn that OpenXX() should have matching CloseXX(). This analysis helps with a number of other situations too, where you have function call pairs that must be matched. Richard said:
In ASM, you don't easily lose track of numeric value range, since you have to provide a place for each value, into which it fits. Same thing with C. But the problem isn't really that you have a big enough variable to store a value. You have more issues. May you add two numbers and get a sum that overflows - possibly becoming negative? May a multiplication overflow? The analysis tools may track min-max values for multiple input parameters and perform full range checking of intermediate results. A mixup of unsigned/signed may be caught - this is extremely hard to catch in assembler. Not if the coder is awake! Frankly, I've only occasionally had to deal with negative numbers. It happens some of the time, but it's easy enough to deal with them if one is aware that they are used in a particular context. I guess the reason I don't see them often is because I consider the MCU to be a large and complex piece of hardware rather than a small computer. Either view is valid, I suppose, but I just use it as "just another bit of hardware." Richard said:
Unreachable code could be a problem, but I've never encountered it. I doubt HLL helps much with that. The problem is that you do not know if you have unreachable code until you finds and fixes it. And then it isn't unreachable anymore. C helps a lot when looking for unreachable code. Next thing is that when developing non-trivial code, you may have code looking like:
state = <complex evaluation>;
switch (state) {
case 0:
...
break;
case 1:
...
break;
...
case 15:
...
break;
default:
...
}
A good analyzer may figure out that state 13 and 15 may never be reached, because your <complex evaluation> may never produce the values 13 and 15. When just looking at the code, this will be impossible to notice. You will have to set up special tests with the full parameter range to find that the code coverage analysis shows that state 13 and 15 haven't been reached. Having a code analyzer find this using static analysis can save a lot of time. You may either save code space by being allowed to remove the two unreachable states. Or this may represent an error in <complex evaluation>. If dispatch tables are used, you can easily find where code goes. Symbols are used to identify those entry points, and, in fact, every entry point. The assembler quickly and easily identifies unused labels. Won't that satisfy your need for finding and fixing "unreachable" code. The only possible exception, IMHO, is a branch not taken because an external stimulus doesn't occur. Those sometimes have to be present "just in case." Richard said:
Type conversions aren't helped by 'C' any more than by ASM. You can stub your toe in either language type. Any language that doesn't allow you to stub your toe is unsuitable for general embedded programming. I'm not sure that's true ... PASCAL is one that slaps your wrist when you do something untoward. It has certainly got a substantial following in the embedded community. But the type declarations in C allows orders of magnitude better static analysis of the code. The normal C compiler can catch a huge number of problems that an assembler can't know anything about. An assembler thinks a byte is good for 0..255, while a C compiler can note that an enumerator only has values between 0 and 93. An assembly language program can do that as well. After all, the compiler has to generate assembly language output anyway, doesn't it? The programmer can't go to sleep while coding such procedures, but covering all cases is really important. All that requires is that there's a table entry for each possible state. It doesn't have to transfer control to a unique location for each state. Processing ASCII alphanumeric input, for example, could easily use the same destination for every printable character, except, say, the CR-LF sequence and, probably should treat those two as a special case. RE |
