We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I have one question about accessing high byte of 2-byte idata variable.
Case 1: for xdata variable we can use below to access the higher byte:
#define ADDR *((_2BYTE xdata *) 0x0800) #define ADDRH *((_1BYTE xdata *) 0x0800) #define ADDRL *((_1BYTE xdata *) 0x0801)
If ADDRH is enough to make decision then we can just use ADDRH, instead of ADDR(2-byte)... This save code space...
Case 2: if ADDR is declared as "idata" then is there any way achieving the same goal like Case 1 ?
All we want to do is "save code base"...
Thanks in advance...
Back to C school. What happens if you do a "compare" using just a single equal character instead of two?
You should also not be defining names with leading underscores - these should be reserved for use by the tools!
The standard reserves the right to use symbols starting with a leading underscore. So obviously, you should think twice about using such symbols on your own - unless you are the maintainer of the standard.
Your second post still contains = (assign) instead of == (equals). Don't you recognize the difference.
Try this:
if (a = 5) { ... }
Now try this:
if (5 = a) { ... }
a equals b implies b equals a. But the above code will fail because it isn't a test for equals.
Another thing. Your hw engineer says that if a failure, then the high byte is always 0xff. That is an implication, not an equivalence. To be an equivalence, the reversed condition must also be true, i.e. that the high byte is never 0xff unless there is an error.
0xff00 or 0xff73 may be valid values, while 0xffff is the error value.
First so sorry for making a big mistake "in the post" We really use "==", instead of "="...!
Second, thanks for your opinion about the "equivalence". After checking with H/W engineer we think the reverse condition is also true because H/W behavior is:
if H/W found valid address then return value within [0,400] else return 0xFFFF
Thus by above if failure then high-byte = 0xFF. And if high-byte is not 0xFF then high-byte might be: 00- Ex. 0x0000~0x00FF 01- Ex. 0x0100~0x0190 These are valid/OK cases...
F.Y.I
In that case, you can reduce the code size by just performing an 8-bit test instead of a 16-bit test. An 8-bit processor doing a 16-bit test normally means that the code first checks one byte (high or low depending on compiler choice) and then decides if it needs to test the other byte - but the code is always generated for supporting testing of two bytes.
Your knowledge that the high byte is 0xff when and only when there is an error condition means that you know that there is never a need to check the low byte, and hence no need to generate any code for any such test.
Note that on a 16-bit or 32-bit processor, it may not change the code size or execution speed if you perform a one-byte test or a 16-bit test. It is only for processors that must perform a 16-bit test as two separate 8-bit comparisons - or that must load the 16-bit reference value as two 8-bit reads - that you may be reasonably sure you can get a gain from modifying the code to just look at the high byte.