In the first PAC shootout, I confirmed that the RAL design produces a PAC that builds quickly in the places I care about. However, there’s a problem with this PAC design: it forms references to MMIO registers.

I’m working on ral-registers 0.2, a breaking API change that avoids MMIO references. Once I clean up the prototype, I’ll describe how it works.

But before I finish ral-registers 0.2, I want to make sure its new API doesn’t drastically slow down build times. Does imxrt-ral build just as fast with ral-registers 0.2 as it does with 0.1?

In an imxrt-ral fork, I updated raltool to generate the RAL expected by ral-registers 0.2. I integrated that branch into the PAC shootout repo. The main branch of the shootout repo benchmarks imxrt-ral with ral-registers 0.1, so it’s easy to compare the two imxrt-ral packages. I udated my stable Rust compiler to 1.89, but I still have my old laptop.

The table below reveals the build time for each imxrt-ral package. These build times are close enough for my needs! I couldn’t find a win, but the new RAL API is no worse than the old.

Chip / Codegen ral-registers 0.1 ral-registers 0.2
imxrt1011 3.33s 3.44s
imxrt1062 5.70s 5.69s
imxrt1176_cm7 11.49s 11.62s
imxrt1189_cm33 34.42s 34.14s
  • Rust version 1.89.0.
  • MacBook Pro, 16-inch, 2019.
    • 2.3 GHz 8-Core Intel i9.
    • 16 GB 2667MHz DDR4 RAM.

Build times aren’t the only thing that matters. I separately made sure that generated machine code optimizes well, just like it did with ral-registers 0.1 (assuming minimal compiler optimizations are enabled).

I’m curious to know if the new ral-registers API increases build times for imxrt-ral users, since the revised ral-register macros emit slightly more Rust code. I should be able to benchmark that later, once imxrt-hal adopts the revised RAL.