Conversation
|
|
||
| IT_SETO, IT_SETNO, IT_SETC, IT_SETNC, IT_SETZ, IT_SETNZ, IT_SETBE, IT_SETA, | ||
| IT_SETS, IT_SETNS, IT_SETP, IT_SETNP, IT_SETL, IT_SETGE, IT_SETLE, IT_SETG, | ||
| IT_SETA, IT_SETAE, IT_SETB, IT_SETBE, IT_SETE, IT_SETG, IT_SETGE, IT_SETL, |
There was a problem hiding this comment.
Please do not change the ordering in the enum; the conditional instructions are ordered by condition code.
There was a problem hiding this comment.
Do we make use of this order? Then a comment should be added.
There was a problem hiding this comment.
Not in DBrew directly, but in the LLVM back-end (see llvm/src/llflags.c:60). This system could also be used in DBrew to avoid redundant condition computation for setcc, cmovcc and jcc. I agree that a comment would be good.
There was a problem hiding this comment.
It seems like a bad idea to give meaning to the numeric values of enum symbols that aren't explicitly assigned. I would either a) accept some additional boilerplate for matching the conditional instructions or b) explicitly assign instruction opcodes as enum symbol values, e.g. IT_SETA = 0x0f97.
| setOpcH(0x0F8F, decode0F_80); | ||
|
|
||
| // 0x0F91-0F9F setcc r/m8 | ||
| setOpcG(0x0f97, 0, IT_SETA, VT_8, parseM1, addUInstr, 0); |
There was a problem hiding this comment.
Ordering. Also, setcc opcodes start at 0x0f90 not 0x0f91.
| static void parseM1(DContext* c) { parseModRM(c, c->vt, RTS_G, &c->o1, 0, 0); } | ||
|
|
||
| // put R of RM encoding in op 1 | ||
| static void parseR1(DContext* c) |
There was a problem hiding this comment.
Unused? (CI complains about this.)
3 participants
No description provided.