Why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC?

[Joel Sherrill]

On 3/4/2015 1:01 PM, Gedare Bloom wrote:
> Joel, I think we're talking about removing inlining here for SPARC. -Gedare
Agreed. And I thought the first paragraph said it was OK on the SPARC.
The SPARC does have fast calls and we should not trigger a register
window overflow since we likely called a method in the super core
just before the enable dispatch.

--joel
> On Wed, Mar 4, 2015 at 11:07 AM, Joel Sherrill
> <joel.sherrill at oarcorp.com> wrote:
>> On 3/4/2015 9:52 AM, Gedare Bloom wrote:
>>> Because it has been that way since 1999?
>>>
>>> The only reason I can think would be to curtail register window
>>> side-effects if there are any. I doubt there would be.
>> I doubt there would be any side-effects either. It can't add to the
>> maximum stack depth and it is unlikely to trigger a window overflow
>> since we probably just returned from another subroutine call.
>>
>> One issue issue is coverage. When building for coverage,
>> _Thread_Enable_dispatch
>> should not be inlined. My quick grep shows 85 calls in cpukit. When not
>> inlined,
>> it is one branch to test. When inlined, we get 170 paths and our current
>> tests
>> don't test but 85 of those. We have no tests which make any API calls with
>> a lock held.
>>
>> This may change with the lock work but it probably just moves branches
>> around
>> and we will end up with new issues for branch explosion due to inlining.
>>
>> --joel
>>
>>> Gedare
>>>
>>> On Wed, Mar 4, 2015 at 10:10 AM, Sebastian Huber
>>> <sebastian.huber at embedded-brains.de> wrote:
>>>> Hello,
>>>>
>>>> why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC? You can say a
>>>> lot about SPARC, but not that function calls are slow.  Is it not better
>>>> to
>>>> reduce the code size and don't inline the _Thread_Enable_dispatch()?
>>>>
>>>> --
>>>> Sebastian Huber, embedded brains GmbH
>>>>
>>>> Address : Dornierstr. 4, D-82178 Puchheim, Germany
>>>> Phone   : +49 89 189 47 41-16
>>>> Fax     : +49 89 189 47 41-09
>>>> E-Mail  : sebastian.huber at embedded-brains.de
>>>> PGP     : Public key available on request.
>>>>
>>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>>>>
>>>> _______________________________________________
>>>> devel mailing list
>>>> devel at rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>> _______________________________________________
>>> devel mailing list
>>> devel at rtems.org
>>> http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>> --
>> Joel Sherrill, Ph.D.             Director of Research & Development
>> joel.sherrill at OARcorp.com        On-Line Applications Research
>> Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>> Support Available                (256) 722-9985
>>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985