Optimization issue in RISC-V BSP

[Denis Obrezkov]

2017-07-28 15:19 GMT+02:00 Sebastian Huber <
sebastian.huber at embedded-brains.de>:

> On 28/07/17 15:15, Denis Obrezkov wrote:
>
> 2017-07-28 14:56 GMT+02:00 Joel Sherrill <joel at rtems.org <mailto:
>> joel at rtems.org>>:
>>
>>     There is a debug option near the bottom of confdefs.h which you
>>     can enable to generate a data structure filled in with various
>>     values computed by confdefs. You can look at that in gdb without
>>     loading it on the target.
>>
>>     It is probably worth it to look at that now and see what you spot.
>>
>> Okay, I'll try.
>>
>>
>>     And a random thought.. what's the interrupt stack size and how is
>>     it allocated? What are the port specific related macros set to?
>>
>> I don't completely understand what is the interrupt stack. Because, when
>> an interrupt occurs,
>> I save all registers and move the stack pointer, handle interrupt,
>>
>
> Now you handle the interrupt on the stack of the interrupted context
> (usually a thread). So, you must take this overhead into account for every
> thread. If you switch to an interrupt stack, then you only have to account
> for one interrupt frame per thread. If you support nested interrupts, you
> need even more space per thread without an interrupt stack.
>

Am I understand right that RTEMS has a wrapper for interrupt handlers that
creates a dedicated 'interrupt handler' task?
I think it is not, since we call ISR directly from assembler code, thus
should we save registers in a dedicated interrupt stack
by ourselves in the ISR?

Also, I don't understand what do you mean by: " you only have to account
for one interrupt frame per thread".
And what is an 'interrupt frame'? I have found something in a relatively
old guide:
https://docs.rtems.org/releases/rtemsdocs-4.9.6/share/rtems/html/porting/porting00033.html
but it doesn't make it clear.
-- 
Regards, Denis Obrezkov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170728/0cd54ef3/attachment-0002.html>