upper 128byte of 89S52

"The problem here isn't if the compiler inlines or not. The problem is that if you do use an 8-bit loop variable, you might be very surprised at the slow runtime if you write:..."

Sorry, but I simply don't follow that one. His code used a 16 bit variable, so your comment of using an 8 bit one is highlighting a situation of your making ... Isn't it?

Sure, he had the pointer and index badly initialised, but that would not have affected the number of passes through the loop.

The examples you show for an overflow of an 8 bit count are, to be blunt, errors of a beginner in such matters - In the same manner, for example, as the lack of appreciation of sign-ness of a char.

Per, I really don't mean to offend - And I REALLY don't want to appear to be saying this Zeusti character is some sort of hero. Just though I should highlight what I see as a strange rejection of something that IS acceptable (re: the idata part).

"The problem here isn't if the compiler inlines or not. The problem is that if you do use an 8-bit loop variable, you might be very surprised at the slow runtime if you write:..."

Sorry, but I simply don't follow that one. His code used a 16 bit variable, so your comment of using an 8 bit one is highlighting a situation of your making ... Isn't it?

Sure, he had the pointer and index badly initialised, but that would not have affected the number of passes through the loop.

The examples you show for an overflow of an 8 bit count are, to be blunt, errors of a beginner in such matters - In the same manner, for example, as the lack of appreciation of sign-ness of a char.

Per, I really don't mean to offend - And I REALLY don't want to appear to be saying this Zeusti character is some sort of hero. Just though I should highlight what I see as a strange rejection of something that IS acceptable (re: the idata part).

And I haven't rejected the idata part.

In this case I'm not talking about a beginner stepping one step too long in their loops resulting in an ifinite loop.

But for a beginner of 8051, it is quite common/reasonable to use int all the time just because it represents the most efficient variable type on 99% of all processors in existence, and is the recommended/preferred data type in the C language.

So what I noted is that when using one of the most 16-bit unfriendly processors in existence (excluding 4-bit processors) loop constructs should when possible be written so that they do not need an int.

As you can see yourself, the loop in question could have been trivially rewritten in a way where an 8-bit variable had been ok. It doesn't matter if you know this. This thread will be read by a lot of people. It is still significant to remember the cost of 16-bit manipulation in the 8051 world.

"It is still significant to remember the cost of 16-bit manipulation in the 8051 world."

Yes, I totally agree with that.