inconsistent naming of implicit x86 operands, e.g. <eax> and "eax"

[robertmuth]

I would be nice to standardize on one, e.g. the one without angle brackets.

[kobalicek]

Can you show an example of the place of inconsistency?

Implicit here means mostly for assemblers implementing X86/X86_64 backends. When eax is used in instruction like ADD, it's implicit in the encoding, but not for assemblers - assemblers use regular encoding and decide which encoding to use based on the use of eax, for example.

This is why you see aaa x:<ax> and add X:eax, id/ud - in the former case ax is implicit, in the latter case eax is not implicit.

[robertmuth]

Here are a few

"out"              , "ub, eax"                                         , "I"       , "E7 ib" 

"xsaves"           , "W:mem, <edx>, <eax>"

"adc"              , "X:eax, id/ud"                                    , "I"       , "15 id" 

"mul"              , "W:<edx>, X:<eax>, r32/m32"   

[kobalicek]

Ok, so:

• out - hah, I think this actually could be implicit, I would have to check the manuals
• xsaves - this one has all registers implicit
• adc - cannot be implicit as that is just an alternative encoding of a regular adc r32, id/ud
• mul - first two registers are implicit - in AsmJit the preferred is to have them explicit instead of implicit

BTW mul has many variations - in general mul with implicit operands performs extended multiplication - like 32-bit to 64-bit or 64-bit to 128-bit.

[robertmuth]

Just to be clear, I just did a grep for eax over x86data.js and copied a few examples. there are many more.

I also just realized that the encoding byte sequence for xsave and mul was missing in my examples but you
can quickly verify that there is now place holder for eax in those bytes so it must be implicit.

To reiterate my point: I believe the information is in the tables is correct but I do not understand why two notations
(<eax> and eax) are used for what seems to be same thing.