How to use upper 128byte of AT89S52. i.e. SFRs(80H to FFH) Address indirectly with KEIL C51 for general purpose which are not in use. They are directly addressable only as SFR.
according to datasheet: 1. The lower 128 bytes of RAM (00H to 7FH) are directly and indirectly addressable. 2. The higher 128 bytes of RAM (80H to FFH) are indirectly addressable. 3. The special function registers (80H to FFH) are directly addressable only.
Please help me thanks!
Yes, I am aware of optimizing compilers.
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:
uint8_t i; for (i = 0; i < 256; i++) { }
or possibly:
uint8-t i; for (i = 0; i <= 255; i++) { }
The problem here wasn't what a compiler may optimize but the issue that the loop variable had to be 16-bit just so it wouldn't overflow on the end-of-loop test. That is a relevant warning. I prefer code written for an 8-bit processor with lousy 16-bit support to be written in a way where the code can stay in the 8-bit realm as much as possible.
And the comment should also be read in the light of the paragraph I wrote directly above, about the start address of the pointer in relation to the offses used in the loop. The pointer started at 0x80 and the loop index started at 0x80.
The big problem with "chief master programmer professor Zeusti" is that it impossible to know if he is shooting a random answer from his hip, or if he happens to know what he writes. Some posts indicates that he is totally 100% clueless, while some other posts are directly usable and indicates that he only makes attempts to pretend to not understand exactly the meaning of what he writes.
If he is regularly pretending to be clueless, then he obviously wants to get critique. If he really is clueless and still answers questions then the OP always deserves the right to know that he has to be careful about answers from the "professor".
"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.