You can simplify things by taking another look at the superficial diagram I made up,

http://www.8052.com/users/richard/805x00.pdf

and consider how it might implement the "general" instruction.

In the case of each instruction, the first thing that happens is that an opcode is loaded into the IOR, from which it is decoded and the timing and datapath control state machines initialized. Each load, store, increment, decrement, AND, OR, COMPLEMENT, etc, is performed in the ALU, whether operating on address or data objects.

This keeps things small and simple. I can't, at this moment, think of even one instruction that requires more than two operands. A simple ALU can deal with that. The SP is just another register, right? On its way to the address bus, it can be inremented or decremented, as well as loaded, as needed, as can the PC or DPTR.

That way, you don't need any long, or even relatively short, synchronous presetable up/down counters, which chew up lots of logic. Everything is just another mapped location, whether SFR or code memory. Where and how it's mapped determines the operations that are valid for any object. There are no operations on 16-bit quantities, aside from those that obviously have to be performed in two steps. (I assume that you have the freedom to determine your own timing.)

You don't have to do things in this way, but it's quite simple and quite easy. Long counters chew up lots of silicon. They also become the rate-determining step in your MCU. An 8-bit ALU, no matter how complex, will probably have fewer delays than a 16-bit counter, if the ALU is designed in the most obvious way. Some of these advantages fall away in FPGA, since the LUT's are so narrow, and multiplexers become slow, but in hard silicon, the ALU can be done quite well.

RE