Subject: Re: com rumblings...
To: Garrett D'Amore <>
From: Allen Briggs <>
List: tech-kern
Date: 06/14/2006 09:29:33
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...


                  Use NetBSD!