re> Maybe you shouldn't think of the register banks of 8 registers
re> each as being what they're called.  They are, after all, just
re> 8 of the 128 iRAM locations, more specifically, 8 of the 32
re> locations in iRAM that can be addressed as such, aren't they?

    Yes.  I understand that and have no trouble thinking of the
    registers as RAM locations.

re> The access to them as registers is really just an alternate
re> logic path to the physical iRAM, right?

    Sort of.  More precisely, it's an alternate way of forming the
    addresses of the iRAM locations that represent the registers.

re> Unlike "real" registers (A, B, SP, DPH, DPL) they're physical
re> ram locations and aren't accessible through SFR space.
re> Consequently, they don't have directly accessible flipflops,
re> as a piece of I/O hardware might.

    Yes.  And that's exactly the reason we need to shadow R0 and
    R1 (yes, all four pairs) in "real" registers--so that we
    can have direct access to those flip flops, in order to
    speed up instructions that us the @Ri addressing mode.

re> In the case of the use of registers R0 and R1, for indirect
re> access, those are loaded in to the ABL with the internal RAM
re> selected.  ABH is not used for internal RAM, so it doesn't
re> matter, hence, isn't affected, or even relevant.

    I have no idea what ABL and ABH are.

re> It's easy to become entangled in details of the construct
re> being implemented and allow that to hamper one's vision of how
re> it can be implemented.  There's no reason you cannot shadow R0
re> and R1 in RAM if it benefits you in some way.  It's just a
re> problem for me because it's really already in RAM,
re> specifically, in iRAM, and I see it offering absolutely no
re> benefit.  Since arguments such as address bytes have to come
re> from somewhere, I'd guess it won't take any longer to fetch R0
re> or R1 from iRAM, or, for that matter, from dedicated hardware,
re> than from a shadowed location.

    The key is that if R0 and R1 are shadowed, they don't
    have to be fetched from anywhere.  They're just there.
    Richard, please take another look at my notes at
    http://www.8052.com/users/rmac/r8051.pdf.  As an example, look
    at the line in the big chart for INC @Ri and DEC @Ri.  I show
    those instructions being executed in three clocks, and that's
    only possible if the contents of R0 and R1 are immediately
    available to form the required address of the operand.  If I
    had to fetch R0 (or R1) from the RAM first, the instruction
    would take one more clock time to execute.  All we're talking
    about here is a little tradeoff--the investment of a little
    bit of hardware to improve performance.  I think the buffalo
    will understand.

 -- Russ

PS: If you have the time, I would be quite interested in a clock-
    by-clock description (similar to those in my notes) of what
    happens for two or three instructions in your shared ALU
    design.  INC @R1 would be a good one, since we're talking
    about it already.  I would also like to see how you think
    that LCALL would work with the shared ALU.