I'm more interested in this for console type activity.   I suspect
*most* people only use serial ports for console ports and slower
peripheral accesses (signature readers, cash drawers, command channel
for other ICs, etc.)

Anyway, what I've done is make a macro for this, but even that has
possible impact.   The old code looked like this:

int
somefunction(struct com_softc *sc)
{
    bus_handle_t   ioh = sc->sc_ioh;
    bus_tag_t iot = sc->sc_iot;
    ...
    bus_space_write_1(iot, ioh, com_data, byte);
    ...
}

Note that the handle and tag are cached in local variables.  It was
harder to do this cleanly in the new code with register access macros,
so my new code looks like the following.  Ultimately, there could be a
performance impact depending on how smart the optimizer is:

struct com_regs {
    bus_tag_t iot;
    bus_handle_t   ioh;
#ifdef COM_REGSMAP
    bus_size_t map[16];
#endif
};

struct com_softc {
    ...
    struct com_regs   sc_regs;
    ...
};

#ifdef COM_REGSMAP
#define   COM_REG_RXDATA   0
#define   COM_REG_TXDATA   1
#define   OUTB(r, o, v)   bus_space_write_1(r->iot, r->ioh, r->map[o], v)
#else
#define   COM_REG_RXDATA   com_data
#define   COM_REG_TXDATA   com_data
#define   OUTB(r, o, v)   bus_space_write_1(r->iot, r->ioh, o, v)
#endif

int
somefunction(struct com_softc *sc)
{
    struct com_regs   *regsp = &sc->sc_regs;
    ...
    OUTB(regsp, COM_REG_TXDATA, byte);
    ...
}

In any case, I'll finish coding this up and send out a patch, which
folks can then test.  I'm not sure how to *performance* test the serial
ports in a way that will show any difference.  I certainly don't have
any 20MHz-ish systems around my home. :-)

    -- Garrett

Allen Briggs wrote:
> On Wed, Jun 14, 2006 at 12:04:44AM -0700, Garrett D'Amore wrote:
>   
>> I'm in the process of hacking up a com.c that has an #ifdef
>> COM_USE_REGMAP that does register remapping.
>>     
>
> Is this primarily for console use, or something that you're planning
> to handle more constant "high-speed" traffic?
>
> I've often thought that we could use a simpler com(4) for console
> use that could be separate from the com(4) that's been tweaked for
> more performance on slower primarily-x86 boxes.
>
> No clue on COM_HAYESP.  Sorry.
>
> On Wed, Jun 14, 2006 at 02:52:56AM -0700, Garrett D'Amore wrote:
>   
>> I'm actually starting to wonder whether about the costs vs. benefits of
>> using a register map all the time.
>>     
>
> I think the only way to justify this really acceptably is with
> numbers.  I can see a bus_space_read_1(t,h,reg) being basically
>
> 	mov.b	rD,reg(rH)
>
> in some implmentations (pseudo-asm ;-), given an ignored bus_space_tag,
> a bus_space_handle already loaded in register rH and 'reg' a constant.
> You're talking about 'reg' being loaded from an array, so the pseudo-asm
> becomes something like:
>
> 	mov.l	rO,reg(rA)
> 	mov.b	rD,rO(rH)
>
> which requires one more temp register (offset), one more function-level
> register (array base register, one more memory fetch (as you note,
> likely cached after the first reference), and one more instruction.
> The instruction cost is paid for each bus_space call, and the others
> are kind of amortized over the function.
>
> So it doesn't seem like it's a no-brainer that it's effectively zero-
> cost.  Nor does it seem given that it's more expensive.
>
>   
>> Its a real pain in neck to have the #ifdef logic that conditionally
>> enables an indirect register map.
>>     
>
> Can it be done by wrapping bus_space access in another layer of
> preprocessor macro?  Similar to how some register accesses are
> handled in other drivers (e.g., CSR_READ() in if_wm.c).
>
>   
>> On systems that have a reasonable cache and have performance
>> considerations for serial IO, the array is likely to be cached.
>>     
>
> I'm not sure that we're talking about systems with reasonable cache.
> What's "reasonable"?  ;-)
>
>   
>> Does anyone strongly feel that an extra indirect reference on com(4)
>> register accesses is unacceptable on some architectures?
>>     
>
> I'm sure someone does, unless you have numbers to back up your
> argument.  ;-)  I don't feel really strongly about it, but I haven't
> used serial ports for data transfer for some years now...
>
> -allen
>
>   


-- 
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191