Thanks Professor! I have watched some of your video lectures on computer organisation and architecture, and they have been really useful to me. Your explanations (along with the visualizations) are very concise and easily understandable!!
Hello professor, thanks for this series I have one question if load is not stored in load buffer due to RAW hazard will it cause subsequent load to stall as previous load op can not be stored in load buffer? Also will stall happen if load and store EA register is itself busy?
I thought thanks to renaming, there would be no WAW or WAR hazards in Tomasulo CPU? Why did you say for Store instructions we have to check for WAW/WAR hazards?
There are no WAW or WAR hazards in registers but there can still be in memory which may be harder to see Say we have R1 = RES3[where it is computing 1100 - 100 and will complete in a few cycles], R2 = 900 and we have the following instructions: LD R3 0(R1) ST R5 100(R2) Superficially they do not have a conflict as indeed they all use separate registers but when R1 returns it will be 1000 and 900 + 100 = 1000 so they are both targeting the same address but the processor does not know it yet. That is why the address translation unit can not issue the loads and stores out of order until the address translator knows the target address (since we might at this point think the store has no conflicts and incorrectly issue it). When R1 is known and the load is issued, we check and see that they both point to address 1000. As a result we can not issue the store until the load is done which is why the store is stuck in the address translation unit until the load is done, otherwise we have a WAR hazard race condition since the store could potentially finish before the load. This is especially evident if we flip the two and have a store first and then a load. The store might be waiting for some compute result and might be delayed allowing a future instruction to the same address to happen first (which is bad) if we do not prevent the second instruction from being issued to the memory buffer. Luckly in well written code this type of hazard is rare so the performance loss of this issue wait is not that terrible.
Thanks Professor! I have watched some of your video lectures on computer organisation and architecture, and they have been really useful to me. Your explanations (along with the visualizations) are very concise and easily understandable!!
Hello professor, thanks for this series
I have one question if load is not stored in load buffer due to RAW hazard will it cause subsequent load to stall as previous load op can not be stored in load buffer?
Also will stall happen if load and store EA register is itself busy?
No, loads and stores to different addresses must be in order otherwise memory mapped peripherals will not work.
I thought thanks to renaming, there would be no WAW or WAR hazards in Tomasulo CPU? Why did you say for Store instructions we have to check for WAW/WAR hazards?
There are no WAW or WAR hazards in registers but there can still be in memory which may be harder to see
Say we have R1 = RES3[where it is computing 1100 - 100 and will complete in a few cycles], R2 = 900 and we have the following instructions:
LD R3 0(R1)
ST R5 100(R2)
Superficially they do not have a conflict as indeed they all use separate registers but when R1 returns it will be 1000 and 900 + 100 = 1000 so they are both targeting the same address but the processor does not know it yet. That is why the address translation unit can not issue the loads and stores out of order until the address translator knows the target address (since we might at this point think the store has no conflicts and incorrectly issue it). When R1 is known and the load is issued, we check and see that they both point to address 1000. As a result we can not issue the store until the load is done which is why the store is stuck in the address translation unit until the load is done, otherwise we have a WAR hazard race condition since the store could potentially finish before the load. This is especially evident if we flip the two and have a store first and then a load. The store might be waiting for some compute result and might be delayed allowing a future instruction to the same address to happen first (which is bad) if we do not prevent the second instruction from being issued to the memory buffer. Luckly in well written code this type of hazard is rare so the performance loss of this issue wait is not that terrible.