Subject: Re: com rumblings...
To: Christos Zoulas <>
From: Garrett D'Amore <>
List: tech-kern
Date: 06/16/2006 08:40:53
Christos Zoulas wrote:
> In article <>,
> Garrett D'Amore  <> wrote:
>> Charles M. Hannum wrote:
>>> On Thu, Jun 15, 2006 at 01:17:06PM -0700, Garrett D'Amore wrote:
>>>> Wouldn't those 4- or 6- (or more!) port cards generally have working
>>>> FIFOs on them?
>>> Sure, but that only helps so much.  At 115200, you're still talking
>>> about 1000 interrupts/sec (you can't just divide by 16) per port, per
>>> direction.  And that's assuming no control signals are being toggled.
>>> On a 386, this added up very quickly.  That's why the "hard" interrupt
>>> routine had the absolute highest priority, even outside splhigh().  It
>>> worked, at the time, before a lot of crap was added in the path.  Also,
>>> even in the mid-90s, people were starting to "overclock" com-like parts
>>> to 230400 and 460800 bps.
>> Yes, I know about some of that.  I've been working on a Solaris driver
>> for 16950s, that uses a 128-byte fifo to help out somewhat.  I've seen
>> other chips that use DMA to minimize the time spent doing PIO, as well. 
>> (Alchemy Au15xx cpus can use DMA to get to 4Mbps.)
>> Anyway, I don't think anything I've done fundamentally changes the
>> paths, other than possibly requiring an extra indirect memory
>> reference.  In theory, a good optimizer could even remove that, though
>> we could need to add some hints about the fact that the bus handles and
>> tags are not changing so can be safely cached.  (Though, again, a good
>> optimizer should be able to figure this out since the routines at issue
>> are leaf routines.)
>> I'm not sure how good gcc's optimizer is at detecting that:
>>    struct {
>>       bus_space_handle_t h;
>>       bus_space_tag_t   t;
>>    } s;
>>    bus_space_write_1(s->t, s->h, OFFSET1, VAL1);
>>    /* possibly insert code that doesn't modify s */
>>    bus_space_write_1(s->t, s->h, OFFSET2, VAL2);
>> both values of s->t and s->h are really the same and could be cached in
>> registers without having to dereference thru s for each
>> bus_space_write_1 call.
>> whether bus_space_xxx are macros or functions probably also plays a role
>> in this.
> Would "const" help here?
Honestly  I don't know.  Part of the problem, I think, is that each
platform has a different idea of what these types (bus_space_handle_t
and bus_space_tag_t) are, and I'm not even sure it makes sense to put
const in front of a structural type.  (Admittedly, this exposes my own
ignorance about the meaning of const in certain C constructs.)

I would imagine that there are also pragmas we could give to the
compiler to give it hints about this, which would help.

Right now I kinda doubt that any of this is necessary.  I doubt anyone
will notice a performance difference at all. :-)

    -- Garrett
> christos

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