В описании от Intel фигурирует т.н. Immediate Grp 1, в которую входят опкоды 80 - 83... Так вот и в описании и на проверку оказывается, что 80 и 82 выполняют одинаковые функции.
Пример (32bit):

800703 add b,[edi],03h
820703 add b,[edi],03h

Так в чем же разница, или ее вообще нет?

Лучшее всему объяснение - слить Detours и посмотреть там.

Peshuha
Честно сказать, не совсем понимаю, чем MS Detours сможет помочь в этом вопросе :)

Об опкоде говорить представляя его в шестнадцатиричном виде практически бессмыслено.
Опкод состоит из блоков, которые в свою очередь состоят из битовых полей. И размеры (в битах) этих полей очень часто не кратны четырём. Т.е. часть бит одного и того же поля может входить в часть бит одной HEX цифры, а часть - в часть бит другой.
В данном случае разница в однобитовом поле S.
Который при работе с операндом в размер с байт использовать вообще бессмыслено, он ничего не меняет.
Однако наличие его в команде, работающей с байтом, нарушением не считается и таким образом получаем для
байта возможность закодировать блок кода двумя различными способами - с битом w=1 и w=0

Но сначала давай посмотрим бинарный формат для
add rem/mem,imm
(буквами я обозначаю битовые поля и сколько букв, столько
и бит занимает поле)
code modrm
100000 s w md 000 m/r и дальше imm.

В случае 80 07 03
первый блок 80 - code: 100000 0 0
100000 - уникальная часть определяющая какая инструкция.
0 - бит S = 0
0 - бит w = 0
Бит w отвечает за определение размера операнда.
если он
0 - размер байт
1 - размер полный (слово или двойное слово, что имено из двух определяется наличием перед командой префикса 66)
Бит S - от слово signed. Он указывает включён ли непосредственный операнд полностью (полным размером)
в состав инструкции или в виде signed byte.
Т.е. в виде знакового байта, который расширяется до размера полного заполнением недостающих бит значением старшего бита.
В случае с байтом - недостающих бит нет и быть не может.
Ну просто не может быть тут никаких "недостающих бит" - некуда уже ужимать непосредственный операнд - приемник и так байт, а закодировать непосредсвенный операнд меньше чем в байт невозможно, это наименьшая адресуемая единица.
Но формат остаётся а значит и бит S остаётся, при этом
он просто игнорируется.
Далее идёт блок modr/m (07) 00 000 111
00 - поле mode - операнд в памяти, смещения нет.
000 - поле code\r в случае, когда в команде 1 операнд
либо не используется (равно 000) либо используется для
битов блока code. При формате 100000sw - просто не использутся
Ну и последнее поле m\r
111 - содержит код операнда, 111 это код для edi
в сочетании с mod <> 11 означает [edi] т.е. не
регистр а регистр-указатель на память.
Потом идёт байт 03 - это сам непосредственный операнд,
который помещается в ту же память какую занимает инструкция.
Т.е. разница в двух опкодах
800703 add b,[edi],03h
820703 add b,[edi],03h
это разница в бите S, который ни на что не влияет если
бит w = 0.
Вот если w = 1 тут разница будет сразу и повлияет на то как будет декодироваться непосредственный операнд и сколько байт будут восприняты как байты непосредственного операнда. Это будут как раз коды 81, 83:

100000 0 1: s = 0 w = 1
100000 1 1: s = 1 w = 1

Особенно нагляден пример с 0. Закодируем то что и в твоём
вопросе но указав, что w=1 т.е. что приемник DWORD.

add dword ptr [edi],0

с битом S= 0:
81 07 00 00 00 00
т.е. 4е байта на непосредственный операнд!
с битом S = 1:
83 07 00
всего один байт на непосредсвенный операнд - недостающие
24 бит будут заполнены 0.
Для add dword ptr [edi],3 как в твоём примере будет
либо с S= 0
81 07 03 00 00 00
либо с S= 1
83 07 03

Система представления кодов в доках Intel одна из самых неудобных, создаётся ощущение что кодировку писали одни люди а документацию - другие.

Спасибо The Svin за подробный (даже слишком) ответ :)))