Hi Neil,

There is a reason that only certain registers are bit-addressable. To show this, consider the SETB command.

The opcode for SETB is 0xD2 (11010010), followed by the bit address in one byte. So how, exactly, does one specify a specific bit address, with only one byte, in a given memory map? By restricting the bit-addressable locations. A single byte will address, at most, 256 unique bits. It just so happens that there are 256 bits which are bit-addressable in a '51 derivative. They are the 128 bits from 0x20 to 0x2F, and the other 128 bits that make up the 8-byte aligned bytes on the SFR map (bytes addressed at 0x?0 and 0x?8 | ? = 8 thru F). If memory serves, the bit-addresses for the first 128 bits (byte addresses 0x20 to 0x2F) are 0x00 thru 0x7F (00000000 thru 01111111), and the bit-addresses for the 8-byte aligned SFRs are 0x80 thru 0xFF (10000000 thru 11111111).

Thus, to set the first bit of memory location 0x20, one would write 0xD200. Similarly, once assembled the instruction SETB P1.7 becomes 0xD297.

Now, by adding a third byte to the D2 opcode, by specifying a 16-bit address, one could directly address 64k of bits. But that would add execution cycles. As it is, SETB uses 1 cycle (12 clock pulses). All 3-byte instructions require a minimum of 2 cycles (24 clock pulses). So increasing the bit-addressable memory space to 64k bits would at minimum double the execution time of all of the existing SETB instructions, unless you made a special instruction to operate only on those added bits (e.g. SETBX).

But there is already a special opcode that allows you to manipulate those extra bits in 2 cycles. It's ORL direct, #data. Moreover, ORL isn't limited to just 64k additional bits. It'll do all of them. And ANL direct, #data will clear arbitrary bits.

Conclusion: The SETB opcode, as it exists, is justified only because it saves cycles on select direct bit manipulations. One might argue the choice of those select bits, but the quantity can not be justifiably expanded. Modifying the existing SETB opcode to address additional bits will deleteriously affect its existing operations, to the point of negating the justification for its existence. And adding a special opcode would be both superfluous and lacking, in that an equivalent opcode already exists and the new one would still be limited to a finite number of bits.

But that's just my two cents worth.

Joe