Christos Zoulas wrote:
> In article <4491D350.6000605@tadpole.com>,
> Garrett D'Amore  <garrett_damore@tadpole.com> 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
http://www.tadpolecomputer.com/
Phone: 951 325-2134  Fax: 951 325-2191