If you write 20k lines of code (quite a small program and well in line with the code space of a 8051 chip), you will have made one or more decisions for each and every line of source. Of course the coder is awake, but lint and similar tools are there because we humans do sometimes makes mistakes. Lint can catch a number of them. If it catches one single error before the application is released, it will most probably have been worth it.

It doesn't matter if you think "small computer" or "another bit of hardware". If you implement some form of regulator, you may have to work with negative values. Your assembler will not help catching an overflow converting a large positive value into a negative value. And an assembler will not think twice about what status flags you will check for in conditional jumps. Saying that we don't need code analyzers because the coder shouldn't sleep is ridiculous. We don't need safety belts in the car either, because the driver should not make a mistake. Or are you willing to tell the world that you have never (!) made a mistake when programming?


I can see that you did not spend 5 seconds looking at my example. I showed code that made some form of computation, and used the result of that computation to select the case statement. Good analysis tools could figure out that the formula used in the compuation could have holes - values that are impossible to get. There is no way the assembler will be able to figure out that a computed, complex, expression can never have the result 7, so there is no way the assembler can note that the code following the state_7 jump target is unreachable. Spend time thinking about other peoples arguments, instead using the first second to decide that other people must be wrong!


And you missed my point again. A HLL can use data type tracking to catch strange type conversions. An assembler can't, because it doesn't have the required type declarations in the first place. The Pascal implementations available will allow you to stub your toe too - they have to, since they have to let you access the SFR and if Pascal doesn't allow you to use pointers to handle conversions between ordinal values and raw bytes most of the type declarations in Pascal would be impossible to use. For embedded, the language has to allow you to do some type casts or direct accesses. But a HLL can limit the percentage of code that is affected - in assembler, every single line is basically affected.


You are kidding, aren't you?

To the assembler, your registers and memory cells are bytes with the capacity to store 0..255. How can you inform the assembler that a specific variable may never store a value larger than 93? So how would the assembler then be able to analyze your code and catch a bug where you try to increment one time too much? And the assembler may know that something represents a memory address. But it will not be able to know what data type your index register is intended to point at. The HLL compiler can have a pointer to an enumerator, in which case the compiler or external tools can validate that your code don't assign the value 0xff, unless 0xff is part of the enumeration.

I know that you have never looked at tools to analyze source code, or you would not claim that it doesn't matter if you have assembler or C or Pascal code. A HLL adds extra structure, and it is this extra structure that the software analyzers can use to figure out possible problems.


Not sure what your point was. Having printable characters grouped together and individual handling for HT, CR, LF, etc isn't an argument in a datatype discussion, and both assembler or a HLL can either have multiple jumps point at the same target, or have specific tests to find sub-ranges that should be processed identically.

A static analyzer can scan a large state machine and decide that no combination of states can allow the code to reach state 94, so a switch statement having a case 94: can result in an error. Your assembler can't, and I don't think anyone have written a static analyzer that can find such problems in the assembler code. You will have to rely on code coverage tests, and if you find that the state 94 has never been accessed during the test, you will have to manually read the code again to try to figure out if state 94 just is very rare, or if it is actually impossible to reach.

If you have a C or Pascal function set_baud(baud_type baud) where baud is a value 0, 1, 2, 3, ... with the enumration:

enum {
    baud_300,   // 0
    baud_600,   // 1
    baud_1200,  // 2
    baud_2400   // 3
};

a C or Pascal compiler will complain 0=300, 1=600, 2=1200 etc, the C or Pascal compiler will complain if you try to send the value 4. Your assembler will just note that you are sending a one-byte parameter to the function, and will not care if the value sent was 0..3 or something else.