SLEIGH: Ternary conditional operator

[mumbel]

https://en.wikipedia.org/wiki/Ternary_conditional_operator

Currently SLEIGH, to avoid a goto, uses a choosing operation with boolean expression multiplication where only once boolean expression is true. Complicated verbose SLEIGH implementations using the boolean multiplication vs a goto which would more likely insert if/else logic where, depending, the if may be hardcoded to be false.

Various implementations of this setup exist, with some modules consistent with others, across all instructions, mixed goto/boolean multiplication, and some choose to use the goto approach entirely.

Could SLEIGH get an official ternary operator added to the language.. PCODE could possibly be tailored better to this setup in the compiler and would be consistent allowing analysis tooling to provide improved results.

variable = <condition> ? <expression_true> : <expression_false>

[esaulenka]

Honestly, your 'mul' approach in the Tricore module makes code unreadable in a many cases. It's a good fit, if condition can be evaluted as a constant, otherwise Ghidra often uses long expression for it, making a lot of mess.
For example, simple shift val = (shift>0)*(val<<shift) + (shift<0)*(val>>shift) became a nightmare, when decompiler combine it with shift = A + B, val = C * D in the single line.

Back to the topic. I agree, it will make life easier, especially if such operator can be used both with const and non-const conditions.

[mumbel]

Yeah, ideally this new ternary feature would handle the static and dynamic cases better. Having to choose goto logic vs conditional is just another layer of logic to work through to find the ideal setup (and is it is only optimal a percentage of the time, which one to choose then?).

In the conditional setup I'm guessing (never tested this) it could also be effected by:

• (<true_condition>==0) + (<true_condition>!=0)
• (<false_condition>==0) + (<false_condition>!=0)
• (<true_condition>!=0) + (<false_condition>!=0)
• (<true_condition>==0) + (<false_condition>==0)

Also if the check is written so the condition is read twice, would additional PCODE get introduced that is harder to optimize out.