York Jong's Library tagged 8051 →  View Popular

Passing lots of parameters to a function on an 8-bit machine is not a great idea. Here are some things you can try to get around this limitation:








• Group data into structures and pass a pointer to the structure.
• If you need to pass four chars, you can group them as a union of four chars and one long and then pass the long. (Not pretty, but it works.)

Parameter ordering

This is a limitation that often surprises people. Consider a function foo() that requires a char, an int, and a generic pointer to be passed to it.

void foo(char a, int b, int *c);

This will result in all six bytes (one for a, two for b, and three for c) being passed in registers. However, rearranging the parameter order to:

void bar(int *c, int b, char a);

will result in only five bytes being passed in registers, with parameter a being passed in a fixed memory location. This results in a significant performance hit.

Function calling summary

Take a hard look at all of your function prototypes. The following changes will usually result in worthwhile performance increases:










1. Convert generic pointer arguments to typed pointer arguments.
2. Make sure that any bit or structure arguments are passed last.
3. Notwithstanding #2, don't pass structures!
4. Minimize the number of arguments-but not at the expense of violating rule 3.
5. Look at the ordering of your parameters to see if a reordering will result in all (or more) of the parameters being passed in registers.
6. Experiment! If you have a function that is called regularly, experiment with the order of its parameters. You may be surprised at the gains you realize.
7. If you need to assign a structure from a function call, then return the structure instead of a pointer to the structure.

From the preceding examples, we can come up with a few rules of thumb for decision-making:










1. Avoid the use of the ternary operator.
2. When testing for TRUE / FALSE, omit all explicit tests and rely on the compiler to cast the variable to a Boolean.

From the preceding examples, we can come up with a few rules of thumb for calling one of N functions:










1. If consistent execution time is important, use an array of function pointers. But if the number of indices is greater than six and the indices are contiguous, use a switch statement.
2. If code size is important, always use an array of function pointers.
3. If average execution time is of paramount concern, then you have to do some analysis:
4. For six or fewer choices, use an if-else chain.
5. For more than six choices, where the choices are contiguous, use a switch statement.
6. For all other cases, use an array of function pointers.
7. If you have a situation where the number of choices may be altered over time, and especially if the choices may become noncontiguous, then use an array of function pointers. This will prevent big changes in performance from small changes in code.

To summarize, the memcpy() routine has the following handicaps:














• Needs eight bytes to be passed in registers
  
• Uses a 16-bit looping index-even when eight bits will do
  
• Determines at run time the memory spaces to use
  
• Has to return a value
  
• Hand optimized assembly language
  
• If the 8051 derivative has two DPTR registers (a common extension to many 8051 families), then the function can make use of this to dramatically improve performance for XDATA-XDATA or CODE-XDATA moves.

1. The memcpy() function requires about 56 to 64 cycles of setup time. This is a lot, and is attributable to the number of registers to be loaded and the fact that the memory spaces are determined at run time.
2. The most efficient method of coding one's own copying data routine seems to be the most straightforward, namely a for-loop with arrays (test 8). This is another example of where the simplest coding construct works best. It's also notable that the array-based code is faster than pointer-based code. So much for the adage of "pointers are faster than array subscripting."
3. If we compare the for-loop to memcpy(), the break-even point occurs around seven bytes in most cases. So if you have to copy more than seven bytes, use memcpy(). Otherwise use a for-loop.
4. The big exception is when doing XDATA-XDATA moves on an 8051 with a single DPTR register. In this case, we are comparing the results of test 4a with test 8. Here memcpy() is always slower than the for-loop. Of course, if you need to copy more than 256 bytes, this result doesn't hold. Notwithstanding this, I still find this result pretty amazing.















If speed is what you need, then use these results. However, if you are copying blocks of data around as part of system initialization, I urge you to consider code size, readability and maintainability before making your decision. Indeed, if code size is your prime consideration, you may want to avoid memcpy(), even if you use it in multiple places. The reason for this is quite subtle. It takes about 19 bytes of code to call memcpy() (the compiler has to load eight registers). In addition, the actual library code is 246 bytes. By comparison, the code size for Test 5 is only 16 bytes, while the code size for Test 8 is 30 bytes. You'd have to duplicate this code numerous times to equal the code required by memcpy.