search

riscv / riscv-CMOs

https://jira.riscv.org/browse/RVG-59
Creative Commons Attribution 4.0 International
77 stars 12 forks source link

Breakpoint: trigger classification store only #31

Closed ingallsj closed 2 years ago

ingallsj commented 2 years ago

Type of change: Functional relaxation.

Explanation: It seems cleaner and simpler to consider CMOs as Stores for both Fence and Breakpoint matching.

dkruckemyer-ventana commented 2 years ago

Incorporated the intent of this pull request (hopefully...) into the draft spec #34

Though I did modify this somewhat....

ingallsj commented 2 years ago

Ahh, I recognize those old familiar keywords IMPLEMENTATION DEFINED. :) I realize that I myself have asked for IMPLEMENTATION DEFINED allowances to reduce the scope of what hardware supports, so I'll grant this here, because I assume you also have a specific implementation that you're trying to fit this onto. But, I caution that debuggers should not rely on this behavior, and I wonder whether it's worth the additional complexity for them to support this varying hardware specification. It's not a big deal here, but a minor additional option multiplied by a long-lived and widely-used architecture (as we hope RISC-V will be) results in a potentially meaningful software complexity cost. I'm not aware of any ISAs that match cache ops as loads, nor implementations that send them down the load pipe, so I guess... why?

dkruckemyer-ventana commented 2 years ago

I'm open to dropping the load condition for management ops. I had added it at one point, because someone requested it, but why is just a faded memory now.

Let's see if we get any feedback one way or another....

dkruckemyer-ventana commented 2 years ago

Note that I punted final description of the trigger behavior to the debug architecture, but I retained "recommendations" for what the debug spec should define.

I did remove the imp-def statement allowing management ops to be handled as loads.

See PR #35