RTEMS | [powerpc] cpukit/score/.../cpu.h: Add _CPU_Spin_wait to powerpc (!1367)

[Vijay Banerjee (@vijay)]

Vijay Banerjee commented on a discussion on cpukit/score/cpu/powerpc/include/rtems/score/cpu.h: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1367#note_155559

 >  /** Type that can store a 32-bit integer or a pointer. */
 >  typedef uintptr_t CPU_Uint32ptr;
 >  
 > +/**
 > + * Pauses the CPU pipeline to prevent aggressive speculative execution
 > + * and reduce thermal load during spin-wait loops.
 > + *
 > + * For PowerPC SMP targets (QorIQ e500mc, e5500, e6500), this issues a Power
 > + * ISA yield instruction ('or 27,27,27'). On e6500 cores with hardware
 > + * multithreading enabled, this temporarily deprioritizes the executing
 > + * thread. On single-threaded or legacy cores, this executes safely as a
 > + * no-operation (nop).
 > + */
 > +static inline void _CPU_Spin_wait( void )
 > +{
 > +  __asm__ volatile ( "or 27, 27, 27" : : : "memory" );

Thanks for the links. Those are good discussions!

The right `or` depends on the use case here, but I believe for this use case the non-sticky `or` that sets it to the "low" priority would be `or 29,29,29` (I'm taking ref from PowerPC ISA 2.06 Book II). This one might also be the closes to the `pause` instruction.

It is also possible to do `30,30,30`, but that will set the priority to medium-low. The stack overflow's accepted answer suggests `31`, but that one is also sticky.

If we just want a nop, `ori 0,0,0` should also do the job without any persistence issue.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1367#note_155559
You're receiving this email because of your account on gitlab.rtems.org. Unsubscribe from this thread: https://gitlab.rtems.org/-/sent_notifications/4-1gbwze6j668t4clhy0tnz5xkh-1d/unsubscribe | Manage all notifications: https://gitlab.rtems.org/-/profile/notifications | Help: https://gitlab.rtems.org/help


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/bugs/attachments/20260727/b2589bec/attachment-0001.htm>