RTEMS | cpukit: Create DHRL Library for DRAM Latency Mitigation (!1193)

[Wayne Thornton (@wmthornton-dev)]

Wayne Thornton commented on a discussion on cpukit/dhrl/dhrl.c: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150613

 > +      atomic_store_explicit(
 > +        &ctx->winning_data_ptr,
 > +        (uintptr_t) target_addr,
 > +        memory_order_release
 > +      );
 > +    }
 > +
 > +    rtems_barrier_wait( ctx->tail_barrier, RTEMS_NO_TIMEOUT );
 > +  }
 > +}
 > +
 > +/* Internal Hybrid Barrier Execution */
 > +static volatile void *dhrl_fetch_data(
 > +  struct dhrl_control *ctx,
 > +  volatile void       *addr_a,
 > +  volatile void       *addr_b

@gedare I'm sure it does look out of place without context. The volatile qualifiers here are strictly to prevent the compiler from performing dead-code elimination.

Because the DHRL worker threads are executing a dead load `(void) *(volatile uint32_t *) target_addr;` just to trigger the physical bus transaction, my understanding of compiler mechanics is that the compiler will silently strip the actual load instruction out at `-O2` if it isn't marked volatile. I kept the signature as `volatile void *` throughout the function chain so the qualification wouldn't be dropped before it reached the worker loop.

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_150613
You're receiving this email because of your account on gitlab.rtems.org.


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