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.
07DH = 01111101B Bank 3
In assembler, you can write constants in binary. You'd have saved yourself the problem if you'd written it in Binary! Always consider which is the most appropriate notation to use - and use it! (Aside: for this very reason, it's a real pain that 'C' doesn't provide a binary notation for constants!)
This should be reasonably portable:
#ifndef BINCONST_H #define BINCONST_H /* Binary constant generator macros evaluating to compile-time constants * * Based on work by Tom Torfs donated to the public domain * * Sample usage: * * B8(01010101) = 85 * B16(10101010,01010101) = 43605 * B32(10000000,11111111,10101010,01010101) = 2164238933 */ /* For up to 8-bit binary constants */ #define B8(b) ((unsigned char)B8__(HEX__(b))) /* For up to 16-bit binary constants, MSB first */ #define B16(b1,b0) (((unsigned short)B8(b1)<<8) | B8(b0)) /* For up to 32-bit binary constants, MSB first */ #define B32(b3,b2,b1,b0) (((unsigned long)B8(b3)<<24) | ((unsigned long)B8(b2)<<16) | ((unsigned long)B8(b1)<< 8) | B8(b0)) /* Helper macros not to be used directly */ #define HEX__(n) 0x##n##UL #define B8__(x) (((x&0x0000000FUL)?0x01:0) | ((x&0x000000F0UL)?0x02:0) | ((x&0x00000F00UL)?0x04:0) | ((x&0x0000F000UL)?0x08:0) | ((x&0x000F0000UL)?0x10:0) | ((x&0x00F00000UL)?0x20:0) | ((x&0x0F000000UL)?0x40:0) | ((x&0xF0000000UL)?0x80:0)) #endif
Well, that didn't work out too good. I'll post a link to binconst.h after a little while.
http://www.8052.com/users/dhenry/binconst.h
In assembler, you can write constants in binary. (Aside: for this very reason, it's a real pain that 'C' doesn't provide a binary notation for constants!) I'm using "modified binary" for C an example (SILabs f12x:
the .h looks like for SCON sfr S0_SCON0 = 0x98; // UART 0 CONTROL sbit SB0_SCON0_SM0 = 0x9F; sbit SB0_SCON0_SM1 = 0x9E; sbit SB0_SCON0_SM2 = 0x9D; sbit SB0_SCON0_REN = 0x9C; sbit SB0_SCON0_TB8 = 0x9B; sbit SB0_SCON0_RB8 = 0x9A; sbit SB0_SCON0_TI = 0x99; sbit SB0_SCON0_RI = 0x98; #define SM_SCON0_SM0 0x80 #define SM_SCON0_SM1 0x40 #define SM_SCON0_SM2 0x20 #define SM_SCON0_REN 0x10 #define SM_SCON0_TB8 0x08 #define SM_SCON0_RB8 0x04 #define SM_SCON0_TI 0x02 #define SM_SCON0_RI 0x01 The initialization then looks like S0_SCON0 = 0 + SM_SCON0_SM0 + SM_SCON0_SM1 + SM_SCON0_REN; and is crystal clear Erik PS the added characters have purposes irrelevant to the "pseudo binary"
"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.
For your amusement this was a solution for 8 bit values I came up with a while ago: #define BIN(x) ((unsigned char)(((1##x##UL%2UL) | (((1##x##UL/10UL)%2UL)<<1) | (((1##x##UL/100UL)%2UL)<<2) | (((1##x##UL/1000UL)%2UL)<<3) | (((1##x##UL/10000UL)%2UL)<<4) | (((1##x##UL/100000UL)%2UL)<<5) | (((1##x##UL/1000000UL)%2UL)<<6) | (((1##x##UL/10000000UL)%2UL)<<7)))) Which allows things like: unsigned char x=BIN(01010101);
"For your amusement this was a solution for 8 bit values I came up with a while ago: #define BIN(x) ..." Which could also be at the core of 16-bit and 32-bit 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.