This is the mail archive of the crossgcc@cygnus.com mailing list for the crossgcc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Code Gen problem calling functions through pointers.


>     David> Yes, it is fully pre-emptive, with a sub-100 usec interrupt
>     David> latency on reasonable (16 and 32-bit) micros.
> 
> This seems rather slow to me, but it all depends on the cpu you are
> using.  With a modern 32 bit cpu running what I would call reasonable
> speeds, I would expect considerably better than this.  Or did you mean 
> 100 ns instead of 100 us?

Actually, I haven't measured it lately, thus I didn't want to over-claim. 

As a specific example, one 16-bit micro we use has a 125 ns bus cycle and
when configured with an 8-bit data bus, I'd estimate its throughput at maybe
2 MIPS.  With this configurations, we built a 9600 bps bit-bang UART using
interrupt-driven counter-timers.  This required handling about 10000
interrupts per second.  Keep in mind that the interrupt handlers were in
C++, too.

So, scaling this up to 54 MHz (27 MIPS?), should allow handling 135,000
interrupts per second, or one every 7.5 usec.  400 MHz (200 MIPS?) would give
1,000,000 interrupts per second, or 1 usec per interrupt.

The processors we use are generally in the range of 1 MIPS to 15 MIPS, so
maybe my idea of "reasonable speed" is a bit conservative.  The actual cpu
throughput is often less important to us than the ease of development.  When
we need more speed, we drop into assembler on inner loops.
 
> This cpu was optimized to run threaded interpretive languages, such as
> Forth.  The exec was written in ANSI Forth with the assembler routines
> SLEEP and WAKE to save and restore context.  

Reminds me of the old Harris micro (the RTX2000?) from about 10 years ago. 
It had multiple data busses so it could execute one FORTH primitive per
cycle.  I don't know what became of it.

> It looks like you are using a linked list to maintain the handlers.
> Perhaps the lookup time to find the proper handler is a major time
> eater? 

No, it's a simple array of Isr objects, indexed by the Isr::Name
enumeration.  The Isr::prev field is only there to allow restoring an old
previous handler when the current one is destroyed.  The biggest part of the
interrupt latency comes in removing a Task object from the head of a
singly-linked wait queue and inserting into the ready queue in order of
its priority.

Regards,

David Querbach
Real-Time Systems Inc.

_______________________________________________
New CrossGCC FAQ: http://www.objsw.com/CrossGCC
_______________________________________________
To remove yourself from the crossgcc list, send
mail to crossgcc-request@cygnus.com with the
text 'unsubscribe' (without the quotes) in the
body of the message.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]