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

asmjit / asmdb

Instructions database and utilities for X86/X64 and ARM (THUMB/A32/A64) architectures.

The Unlicense

328 stars 46 forks source link

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

Open robertmuth opened 2 years ago

robertmuth commented 2 years ago

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

kobalicek commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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.