Fix disassembly highlighting for complex DSP instructions

[XVilka]

For instructions like:

mov *(ar1+t0b) << t3, ac2 || mov ac1.l , *ar4

currently determined "mov ac1.l, *ar4" instruction as part of "ac2" operand

rptblocal #0x000011 || sfts ac0,  #-1

currently determined "sfts" as part of 0x000011 number

cmp t2 == t3, tc1

currently determined "t2 ==" as part of instruction keyword "cmp"

xccpart ac0 <=  #0 || mov #0x0, t0

currently determined "ac0" as part of "xccpart" instruction keyword, "|| mov #0x0, t0" as part of number #0

Proof:

[XVilka]

@milabs - thats for you :)

[milabs]

@XVilka Perfect! Didn't understand nothing :)

[XVilka]

@milabs - can you please try to fix this before 0.9.8 release (two weeks from now)?

[radare]

There are some warnings that should be addressed too. The 'colors' depend on the op->type. Also, adding support for ESIL would be great

[milabs]

@XVilka I'll try to do it tomorrow

[XVilka]

@milabs it is in https://github.com/radare/radare2/blob/master/libr/core/disasm.c function
handle_build_op_str (RCore *core, RDisasmState *ds)

[radare]

Thanks @milabs

[XVilka]

@milabs
Fixed, but still not completely - check the new screen:

[jvoisin]

This is related to #1195

[radare]

ping

[XVilka]

@radare postpone this for 1.0.0 - it will require a huge refactoring of the highlighting code

[radare]

ping ? 1.0 is close, is anyone up for this? because imho its quite low prio and i'll put it for 9999

[radare]

i assume nobody is gonna do anything related to this in two weeks after waiting 3 years

[XVilka]

Applies also on Hexagon (note that in lines R2 = 0x21 ; R1:R0 = combine (#0, R23) and R2 = 0x21 ; memw (Sp + 0x24) = R4 highlighting is wrong)

[ret2libc]

@XVilka still relevant?