Why is CPU_INLINE_ENABLE_DISPATCH defined to TRUE on SPARC?

[Joel Sherrill]

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