How BlueSpec's Guarded Atomic Actions could be translated to SUS

[VonTum]

It's becoming a convention for SUS code to use try_ and may_ prefixes for "guarding" actions and triggers. For instance, look at the FIFO interface: output bool may_push and action push: T data_in. Likewise the other side of the FIFO might see input bool try_pop and trigger pop : T data_out

We could have language constructs for try_ and may_ variants of actions & triggers

Implicitly, when seeing something like

when x == 4 {
  action receive_data : int a, bool b {}
}

The compiler could insert a new output port output bool may_receive_data = x == 4.

Sadly, this doesn't translate too well to triggers. A naked trigger my_trigger takes no condition. Unless we add some kind of guard {} block?

Something like

FIFO fifo
guard { // Implicitly converts to "when fifo.may_pop & try_data_valid"
  float data = fifo.pop()
  
  trigger data_valid : data // Implicitly spawns an action try_data_valid
}