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.
If I execute an instruction: MOV PSW, #07DH what is the active register bank? I believe its bank 2.
"This should be reasonably portable" True - but we shouldn't be having to mess around with inventing such stuff just because of such a glaring hole in the language! What were Kernighan & Ritchie thinking of?!
"This should be reasonably portable" True - but we shouldn't be having to mess around with inventing such stuff just because of such a glaring hole in the language! portability in small microcontroller code is an illusion. Thay all imply different meory schemes, different I/O schemes, different .... since the topic directly refer to I/O portability does not matter one iota. Erik
"portability in small microcontroller code is an illusion." I'm not quite sure what you are referring to here. Are you saying that the C preprocessor's token merging operator is not portable among small microcontroller C compiler preprocessors? "Thay all imply different meory schemes, different I/O schemes, different ...." The C preprocessor is not involved whatsoever with these matters. "since the topic directly refer to I/O portability does not matter one iota." "The topic(s)" have been:
"Thay all imply different meory schemes, different I/O schemes, different ...." The C preprocessor is not involved whatsoever with these matters. I do not know why you specifically mention the preprocessor, but C (for the '51 and such) is "involved" with the above. I/O, or the oxymoron "I/O portability" for that matter, wasn't even in the discussion until you brought it up. sorry, I misspoke, I should have said "SFR portability" since the PSW, while a SFR is not I/O Erik
"I do not know why you specifically mention the preprocessor ..." The discussion about binary constant macros is not part of the original thread. The original thread about bank selection in assembly language has stopped with Andy's first post. At the end of Andy's first post, he added a side comment (using the word "aside") about C's lack of binary constant notation. A new thread has started on that fork speaks to how some have addressed C's lack of binary notation. That's the thread you are in and were in when you introduced the notion of portability illusion, memory schemes, and I/O schemes. It is the C preprocessor's text replacement and token merging facilities that allow the binary constant macros to work, that's why I specifically mention the preprocessor. It's the part of the toolchain that expands the macros. The binary contant macros and the C preprocessor that have nothing to do with memory, I/O, SFRs, microcontrollers, microprocessors, RISC, CISC, mainframes, etc. You see, it's a text replacement thing. The preprocessor, when expanding the binary constant macros, "translates" a number that is represented in binary notation in the program's source into a normal C integer and produces preprocessed temporary source code output with the integer translations. There is no binary notation in the output passed to the C compiler. Any additional non-portable memory, I/O, SFR stuff for your specific toolchain pass through and are not affected by the binary text replacement. "... I should have said "SFR portability" since the PSW, while a SFR is not I/O" Again, the assembly language PSW (SFR) bank select thread has stopped for the time being with Andy's first post. We're not talking about "SFR portability" (another oxymoron), we're in a forked thread talking about portable binary constant macros.
"I do not know why you specifically mention the preprocessor" The reason you don't know is either because you didn't bother to read the thread or you didn't understand the content. You are so busy looking for an opportunity to chuck in one of your ludicrous generalisations such as "portability in small microcontroller code is an illusion" that you miss the whole point of the discussion. Doubtless you'll start whining about 'personal attacks' or some such - well, if you think this is a personal attack I suggest you grow a thicker skin. Those who throw their ignorance around in public quite as much as you do need one. You'll be pleased to know that I have no intention of wasting any more of my time following up whatever nonsense you choose to post in response.