Maybe not so relevant. The question is: Do you have recent knowledge from extensive work in both assembler and C? To compare an apple to a pear, you need similar experiences with both.


The question is: Do you have recent, extensive, knowledge of doing similar things in both C and assembler? If you do one type of program in C and another type of program in assembler, you will not compare the same thing. When doing a bread-and-butter administrative tool, I may produce 1k+ lines/day of C code for day after day. If implementing a highly efficient search routine for geographic data, I may produce 100 lines/day. When working with some problems, the complexities of the problem may mean I only averages 10 lines/day.

So when comparing how efficient I am when using C or assembler, I have to compare when doing similar things. How efficient am I decoding NMEA data from a GPS when using assembler or C? If I haven't a big set of similar problems I have worked with using different tools, it will be very hard to estimate the productivity.

In your case, you don't seem to use any C compiler for 8051 work. But you claim you have done a lot of C programming of old MS-DOS applications using Turbo C.


I think most people here do know what a macro assembler is. But the instantiation of a macro is basically a paste of a fixed expansion, combined with a search/replace depending on supplied arguments. When implementing more comples logic (the kind when documentation, testing etc really matter), you will get little use of macros, because so few assembler source lines will match any pre-written macro.


For someone who don't know how a C compiler works, it is easy to think of it as a macro assembler. a=a+1 can be seen as the instatiation of the macro INCREMENT_WITH_ONE(a).

The important thing here is that the existence of a large number of assembler macros may be nice. But when solving real problems, the parts of the code that will take time will not match any pre-cooked macros, so the assembler programmer will have to spend significant time trying to figure out what registers to use to manage an efficient solution. And when the complexity of the problem is high, it is quite likely that the developer will have to modify the code a lot until reaching a good solution. Rewriting the C code is way faster than rewriting the assembler code. And the rewriting need not be caused by a bad developer, but because you need to make a lot of test runs to find out the exact behaviour of the system you are going to control. In some situations, you may tune constants. But in some situations, you will have to make changes to the algorithms depending on the feedback you get from test cases.


I think you are the only one who believes I am making such a claim. But a significant percentage of a C application is possible to move from a 8051 to a PIC or AVR with very minor changes. The business logic of an application isn't so much affected by what processor you have. I know because I have moved code between processor architectures many times. Whenever I do write new code, I know one thing: I don't know if I write the code for the final processor, or if the code may jump. I have even regularly moved code for 8-bit processors to 32-bit machines to let the build machine test significant parts of the code in a simulated environment. The only real language issues when moving Keil C51 code to another compiler is the bit variables. But it is not a big job to get the code to compile on a processor that doesn't have bit variables if I can live with each variable expanding from a single bit to a byte. And with use of #define, I can use TEST_XX, SET_XX, CLEAR_XX in the code, and compile the code to directly use a bit variable or set/reset/test a specific bit in a byte.

If I can move the business logic from one processor to another, and then merge the business logic with copy/paste code for the timers, UART etc from other applications already using the new architecture, I can get very significant code reuse when moving an application between processors. Even when there are big differences in architecture.

I would not like to produce the same hw for 20-30 years, desperately buying surplus batches of old processors just because the cost is too high to switch to newer processors.


But the controlling part can be quite complex. And when a system is non-linear, or you have unknown constants, it may not be applicable to use lookup tables.


It may be simple, but only capable of handling a subset of problems without exploding to infinite size. And if the customer is allowed to configure the behaviour, you may have to build the tables dynamically and store in way more expensive RAM. And if the system is non-trivial, you would normally not build your tables by hand, but instead use software to generate them.