First, thanks to Andy and Oliver for the responses. It is certainly fair to question any assumption not based on data from a manual or other reliable source. Clearly our situation demonstrates the shortcomings in such an approach.

For the record we did perform a very thorough compiler evaluation which indeed uncovered the fact Andy pointed out that Keil does not make extensive use of the second data pointer even when it is enabled. In fact, that was one of the reasons we chose IAR. It was clear from the IAR listing files that they do make extensive use of the second data pointer when it is available. Obviously we allowed our focus on which compilers did/did not use the second data pointer to blind us from the obvious question of whether or not there was an advantage to using the second data pointer. Shame on us.

For anyone interested, we did investigate further to understand the behavior of the IAR compiler and the unexpected difference in code size and performance. Read on for details....

Unfortunately there is a key fact that does not exactly jump out at you when examining the IAR listing files and other documentation. It turns out that since we are using the xdata reentrant calling convention, in most cases the cost of stacking and unstacking the second data pointer, quickly washes out the advantages gained by the use of the second data pointer. In fact a close analysis reveals that just the act of stacking/unstacking the second data pointer requires an additional 56 bytes of code and 90-96 machine cycles in each function that uses the second data pointer.

As stated earlier, this phenomenon results in as much as a 4k cost in code space when using the second data pointer. We will soon be reworking our assembly routines to be compatible with the single data pointer model.

Thanks,
Keith Richeson