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

[Wayne Thornton (@wmthornton-dev)]

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

 > +        break;
 > +      }
 > +      case 4: {
 > +        volatile uint32_t hardware_fetch = *(volatile uint32_t *) target_addr;
 > +        (void) hardware_fetch;
 > +        break;
 > +      }
 > +      case 8: {
 > +        volatile uint64_t hardware_fetch = *(volatile uint64_t *) target_addr;
 > +        (void) hardware_fetch;
 > +        break;
 > +      }
 > +      default:
 > +        // Invalid hardware transaction width. Abort.
 > +        continue;
 > +    }

In going thru my code, I wanted to refactor this to avoid casting the hardware_fetch to (void), which works fine to avoid compiler warnings but has the potential to pollute the stack. I am going to push an update to the commit with a more idiomatic, embedded way of doing things. That will look like this:

// THE HEDGED READ: Force the fetch across the memory bus with exact width
    switch ( dhrl_data_size ) {
      case 1: (void)*(volatile uint8_t  *) target_addr; break;
      case 2: (void)*(volatile uint16_t *) target_addr; break;
      case 4: (void)*(volatile uint32_t *) target_addr; break;
      case 8: (void)*(volatile uint64_t *) target_addr; break;
      default: 
        // Invalid hardware transaction width. Abort.
        continue;
    }

-- 
View it on GitLab: https://gitlab.rtems.org/rtems/rtos/rtems/-/merge_requests/1193#note_148404
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/20260410/03bc5db2/attachment-0001.htm>