Matt Thomas wrote:
>
> On Mar 8, 2006, at 3:59 PM, Garrett D'Amore wrote:
>
>> Jason Thorpe wrote:
>>>
>>> On Mar 8, 2006, at 1:47 PM, Garrett D'Amore wrote:
>>>
>>>> Steve Woodford wrote:
>>>> Yes, I have such hardware.  But on my platform its a feature of the
>>>> bus
>>>> I'm on, and not a device specific thing.  (So I naturally take care of
>>>> it in the parent bus.)  The problem is when the actual *chip* has
>>>> weird
>>>> things about it that you try to solve at the bus level...
>>>
>>> I think a combination of things are necessary...
>>>
>>> 1- Adjusted bus_space tags for the access-width / stride issue
>>>
>>> 2- A register offset map for the "registers are laid out differently"
>>> issue.
>>>
>>>> Oooh.... I like that idea.
>>>
>>> I don't... a single indirect function call is bad enough :-)
>> How does an indirect function call compare against say the cost of
>> another array index lookup and an extra shift/mask operation>
>
> for vax, about an order of magnitude.
OK.
>
>> Also, folks seem *really* concerned about the performance of these
>> things.  Are folks really wanting to drive *non-FIFO* older parts at
>> 115200+?    For newer parts it shouldn't matter that much.
>
> Not every platform is N hundred MHz CPU.
Even a 25MHz cpu should be able to get decent performance with a
reasonable FIFO.

Yes, there are parts that are *even slower* than 25 MHz, but they
probably aren't very interesting for running NetBSD.  (They probably
don't even have MMUs...)
>
>> FWIW, this is like 14k extra indirect calls per second.
>
> That's a lot.
It doesn't seem like it to me.  But I'll give you the point.
>
>> I'm also willing to consider that for low performance systems we use an
>> #ifdef that makes the call not go thru the extra indirection.
>
> Then why bother with the extra indirection?
Because on some platforms you can have *multiple* different com
variants.  E.g. you might have one one a PCI bus that is pretty much
standard, and you might also have the onboard one that is really weird. 
So you need something at run-time, or you wind up with separate drivers.
>
>> Its not as if these are really high data rate parts... :-)
>
> They might seem to be for some platforms!

Yes, on a 1MHz 6502 it would seem that these appear to be fast.  But
even on a 386 they aren't that bad.  The only problem that older PCs had
with these (older being early generation 386s) was that the 16450's
lacked a FIFO.

On machines with the older busses, it would makes sense IMO, to #ifdef
out this extra run-time logic, because they probably don't need the
bizarro mapping support.

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