I'm actually starting to wonder whether about the costs vs. benefits of
using a register map all the time.

Its a real pain in neck to have the #ifdef logic that conditionally
enables an indirect register map.  And I'm starting to doubt whether the
performance difference is worth it even for slow architectures. 
Specifically, I think we are considering the cost of an extra level of
memory indirection.  So instead of using fixed constants for register
offsets, we would use an index into an array.

On systems that have a reasonable cache and have performance
considerations for serial IO, the array is likely to be cached.  So the
performance hit should be minimal.

Does anyone strongly feel that an extra indirect reference on com(4)
register accesses is unacceptable on some architectures?

    -- Garrett

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.  (I.e. actual register
> offsets are located in an array in the softc.)  This would be
> conditionally compiled, to minimize impact on VAX, i386, m68k, etc.
>
> What this would do is let me get rid of custom aucom.c, and weird bus
> space mapping logic ( a custom bus space just for this chip!) in
> com_arbus.c.  I'm also hoping this will resolve a bug in aucom.c.
>
> One question cropped up though.  I noticed that if COM_HAYESP is
> defined, the probe for a HAYESP device is used, which just uses the ISA
> trick of writing to special ports.
>
> This is fine for ISA, but it is a really bad idea on other busses, e.g.
> PCI where writing to the named addresses might result in a system crash
> or other unexplainable behavior on non-i386 systems.
>
> I'd like to move this code to com_isa.c, if we can confirm that it
> really is ISA specific.  I.e., are there PCI or PUC devices that match
> this logic?  I _suspect_ the answer is _no_, but I'm interested to hear
> more specific details.
>
> Any objection with relocating the HAYESP support to com_isa.c (still
> leaving it #ifdef COM_HAYESP, of course)?
>
>   


-- 
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