Optimization issue in RISC-V BSP

[Joel Sherrill]

On Fri, Jul 28, 2017 at 9:23 AM, Denis Obrezkov <denisobrezkov at gmail.com>
wrote:

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

There can be interrupt server threads but that is a distinct topic.

Interrupts have to execute on a stack. As Gedare said, you are currently
processing each
ISR on the stack of the thread that was interrupted. Most of the other
ports have a dedicated
interrupt stack and switch to it.

There is a worst case stack usage for each thread and the interrupts.
Without a dedicated
interrupt stack, each task must account for its worst usage and the worst
case interrupt
when allocating its stack.


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

An interrupt frame is the set of data that must be saved for each interrupt
occurrence. The
"only have to save one" is because you can switch to a dedicated stack
where interrupts
are processed and possibly nested. Thus you have the usage for the
processing and
possible nested interrupts.

But you need to figure out why the memory allocated changed. Optimization
level should be
independent of that.


> --
> Regards, Denis Obrezkov
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20170728/2be6efde/attachment.html>