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.sherr...@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.hu...@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.hu...@embedded-brains.de >>>> PGP : Public key available on request. >>>> >>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >>>> >>>> _______________________________________________ >>>> devel mailing list >>>> devel@rtems.org >>>> http://lists.rtems.org/mailman/listinfo/devel >>> _______________________________________________ >>> devel mailing list >>> devel@rtems.org >>> http://lists.rtems.org/mailman/listinfo/devel >> >> >> -- >> Joel Sherrill, Ph.D. Director of Research & Development >> joel.sherr...@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.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985 _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
