I've not yet determined what the benefit/cost ratio of executing multiple instructions concurrently and/or executing some instructions out of order. It's a notion I'm exploring because I'm not sure it's been examined by soft-CPU designers as yet. However, two-byte and three-byte instructions generally are an opcode followed by memory reference addresses, or that form, at least, and, by displaying more of code space at a time, to the execution unit, while also displaying more of internal data memory at once, I can transfer multiple locations' content between locations concurrently without impacting overall performance. It does, of course, consume resources, and, if those resources, combined with the logic with which to make those arbtirations happen becomes too large, it won't be practical. Load DPTR, for example, if not preceded by some DPTR usage, is an ideal candidate for out-of-order execution, and numerous instructions using register indirection can be handled in that way if explicit registers are used, rather than memory locations. I'm convinced that there's a solid way to speed this instruction set up without damaging it, such that when all is said and done, the core will execute standard 805x instructions in a single clock cycle, irrespective of the number of bytes in the instruction. Whether it's practical is, of course, another question. The fact that SDCC and other tools are already well understood and available to all for development within this architecture and instruction set is a compelling reason to investigate this matter.

As for the automatic RI/TI clear, I view that as a way in which to make Mode 0 more useable. I can probably build the hardware in such a way that one will have the choice of using the serial port that has the automatic clear of the status bits, or, at user's option, use the one that operates in the standard way. The SFR's are not impacted in any way, AFAIK. The only effect will be that, once the data buffer is written, it is no longer necessary to clear the status bit.

RE