Speed of software and hardware

As the CPU becomes faster and faster, and the architecture design of multi-level pipelines, some new attention needs to be paid to software programming.
I have encountered this issue recently, which has aroused some discussions and thoughts. I would like to share with you some ideas.
First, the CPU and peripherals. Because of some delay on the bus, when we set the peripheral registers, the peripherals need to perform some actions and changes according to the latest settings. These actions and changes take some time, but the software is already fast enough. Before these actions start, the software will access them again.
Now, let's see how the hardware works.
1 hardware is smart enough. I found that I have not taken effect yet. I hold the software request and wait until it takes effect. Then I will give it a new value after it takes effect.
2. The hardware is silly. The software request took away the settings before they took effect.
3 hardware provides some means for SW to use. For example, a bit of a Status Register is provided to indicate whether the status register takes effect.

Take the problem I encountered as an example:
The following is an automatic test function for a peripheral. Both write and read operations are verified as OK. The result shows that there is a read operation problem here.
Test function ()
{
HW write operation;
HW read operation;
Compare read/write data;
}
After analysis, we found that as long as there is a little delay in the middle, the read operation is OK. Check the HW manual and find that the write operation takes some time. Fortunately, this HW belongs to the above Type 3, and I still have the means to know if HW is ready. The new process is as follows:
==>
Test function ()
{
HW write operation;
Waiting for HW write operation ready
HW read operation;
Compare read/write data;
}
Of course, this is not enough. Here, the write operation function is not actually done, so we need to put this action behind the write function.
==>
HW write operation ()
{
....
Waiting for HW write operation ready
Return;
}

What if it is HW type 2? I think SW can continue to polling whether the register is changed.
----------------------------------------------------------------------------------
In addition, the current CPU uses the X-level pipeline architecture. As soon as the code above is finished, the next step is to start running. If you operate on Ram, there is no problem. However, for HW, due to the different inherent responsiveness of HW, the running sequence may be different from the code sequence. So in order to ensure that our HW can run in the order of our code, we still need to make some small changes.
The common way to ensure that the data in the internal registers of the CPU is read and written is,After writing this register, you need to read it again.. As shown in the following macro:
# Define it_must_be_completed (REG )\
{\
Volatile unsigned u32 TMP ;\
TMP = * (unsigned u32 *) (REG ));\
TMP> 1? 1:0 ;\
}
Use:
Reg_xxx = 0 xFFFF;
It_must_be_completed (reg_xxx );

If it is in the Assembly, it is after STR, and LDR is required.
STR R1, [R0]
LDR R1, [R0]