Ассемблер. Язык и программирование для IBM PC. Питер Абель.

Питер Абель
Ассемблер, Язык и программирование для IBM PC.

5-ое русское издание.

Много различных опечаток, и если некоторые безобидны и легко отлавливаются даже неофитом, то есть и такие, которые могут ввести в серьезное заблуждение в дальнейшем, заставив переучиваться чуть ли не заново.

Один монах сказал: "Учение Дзэн, неверно понятое,
наносит душам большие увечья". Я согласился с ним

===

страница 103, рис. 4.5 "определение символьных и числовых констант"

Как я понимаю, расположение данных в памяти приведено неверно во всех примерах, поскольку "младший байт по меньшему адресу" и "данные хранятся в обратной последовательности".

правильно должно быть так:

пожалуйста поправьте если я не прав.

 

Это верно для систем с little-endian архитектур, коей и являются x86 и x64. Видимо, примеры были для big-endian архитектур, примером которой являются RISC или SPARC, либо, как Вы могли заметить, примеры приведены с ошибками.

 

Guru_of_Zen
В данном случае в книге верно, а у Вас нет. Согласно Вашей цитате там числовые шестнадцатиричные представления в памяти чётко отделены пробелами.
Например, следующая строка верна:
0030 0002 0004 0006 0007 WORD4 DW 2, 4, 6, 7;
При этом если бы мы хотели разбить память по адресу 30 на двойные слова, то эта же память была бы представлена так:
0030 00040002 00070006
Если же нам нужно побайтовое представление содежимого этой же области памяти, то оно будет представлено уже в таком виде:
0030 02 00 04 00 06 00 07 00

 

Ну если учитывать пробелы то да... Но это, IMHO, только вводит в заблуждение. Если уж приводить дамп памяти, то в байтах.

 

KeSqueer

Зависит от целей и обстоятельств. Зачем мне, например, дамп в байтовом представлении, если я работаю с массивом двойных слов?
В данном случае в книге, очевидно, для каждой директивы был выбран соответствующий (наиболее удобный) способ представления данных.

 

KeSqueer

я малость ступил - привел пример не понлостью.
но например оттуда же:

Код (Text):

1. 0066       395E000000000000      QWORD2     DQ        05E39H
2. 006E       5AA2000000000000      QWORD3     DQ        41562    ;      41562 = A25AH

Видно что данные хранятся в перевернутом виде, т.е. младший по меньшему.
Значит, примеры в книге приведены неверно ?

 

l_inc

а собственно причем тут пробелы ? в книге имхо пробелы (не) поставлены для наглядности просто, да и все равно - хоть с пробелом хоть без него - а байт он и есть байт (и его адрес тоже никуда не делся, хоть и без пробела).

наконец, почему строка приведенная выше верна ?

если определяется слово (2 байта), то под числовые константы 2,4,6,7,9 в памяти будут резервироваться 10 байт (00,02,00,04,00,06,00,07,00,09)
и хранится все это будет в перевернутом виде, т.е.
0200, 0400, 0600, 0700, 0900.
(или 02 00 04 00 06 00 07 00 09 00 , если на то пошло )

путаница возникла из-за пробелов и их отсутствия имхо.

Ага, наиболее наглядный и сбивающий с толку. Неофит так и будет думать, что определенное слово/двойное слово/учетверенное хранится в памяти в неперевернутом виде, т.е. как определили - так и хранится.

Или выходит что у самого Абеля в одном случае без пробелов и не переставлены байты (первый пост), а в другом случае - без пробелов, но переставлены (предыдущий пост) ?

 

+1.

и ладно бы в книге все было проследовано одному стилю - т.е., или

, или ортодоксально в байтах.

 

l_inc

И все равно позволю себе с Вами не согласится, и вот почему.

Представить данные можно по-разному - можно правильно, а можно и неправильно - как в книге например.

Пример:

Кодер определяет слово

Код (Text):

1. WORD1   DW   34H

.

Потом кодер дампит этот код, и получает

Код (Text):

1. 0F44     ...
2. 0F45     34
3. 0F46     00
4. 0F47     ...

Но поскольку ему удобнее работать с массивом слов, нежели байтов, то он допустим в настройках дампера указывает выдать данные размерностью в слово, и получает:

Код (Text):

1. 0F43 ... ...
2. 0F45 34 00
3. 0F47 ... ...

В обоих случаях 34 хранится в ячейке с адресом 0F45, а 00 - в ячейке с адресом 0F46.

ЗЫ А в книге все-таки неправильные примеры, не переставлены байты.

 

Guru_of_Zen

Так на то и пошло, что в первой строке Вы выписываете байты сгруппированные по два, а Абель выписывает двойные слова, то бишь числа.

Ну вот здесь могу согласиться, что с dq Абель прогнал. Надо было либо пробелы ставить, либо писать в виде нормального 64-битного шестнадцатиричного числа.

Ерунда. Зайдите в OllyDbg и попереключайтесь в окне дампа между представлениями
1) HEX -> HEX/ASCII (16 bytes)
2) Short -> HEX
3) Long -> HEX
И не надо фантазировать, что OllyDbg просто позволяет неправильно представить данные.

 

l_inc

Да, признаю свою ошибку - если значение в байтах, оно перевернутое, а если например слово, то уже не перевернуто.

Свои ошибки понял, пробелы восполнил; неточности в книге выявлены.

l_inc & KeSqueer - большое спасибо за объяснение.

 

И все-таки полного просветления не достигнуто.

раздобыл некое предыдущее издание Абеля (возможно, самое первое), там тот же самый листинг (из первого поста) имеет следующий вид:

Код (Text):

1. __________________________________________________________________________
2.  
3.                                  page    60,132
4.                          TITLE   EXDEF   (EXE) Определение данных
5. 0000                     DATASG  SEGMENT PARA 'Data'
6.  
7.                          ;              Определение байта - DB:
8.                          ;              ----------------------
9. 0000  ??                 FLD1DB  DB     ?         ;Не инициализировано
10. 0001  50 65 72 73 6F 6E  FLD2DB  DB     'Personal Computer' ;Сим. строка
11.       61 6C 20 43 6F 6D
12.       70 75 74 65 72
13. 0012  20                 FLD3DB  DB     32        ;Десятичная константа
14. 0013  20                 FLD4DB  DB     20H       ;Шест. константа
15. 0014  59                 FLD5DB  DB     01011001B ;Двоичная константа
16. 0015  01 4A 41 4E 02 46  FLD6DB  DB     01,'JAN',02,'FEB',03,'MAR' ;Таб-ца
17.       45 42 03 4D 41 52
18. 0021  33 32 36 35 34     FLD7DB  DB     '32654'   ;Символьные числа
19. 0026     0A [ 00 ]       FLD8DB  DB     10 DUP(0) ;Десять нулей
20.  
21.                          ;              Определение слова - DW:
22.                          ;              ----------------------
23. 0030  FFF0               FLD1DW  DW     0FFF0H    ;Шест. константа
24. 0032  0059               FLD2DW  DW     01011001B ;Двоичная константа
25. 0034  0021 R             FLD3DW  DW     FLD7DB    ;Адресная константа
26. 0036  0003 0004 0007     FLD4DW  DW     3,4,7,8,9 ;Пять констант
27.       0008 0009
28. 0040     05 [ 0000 ]     FLD5DW  DW     5 DUP(0)  ;Пять нулей
29.  
30.                          ;              Определение двойного слова - DD:
31.                          ;              -------------------------------
32. 004A  ????????           FLD1DD  DD     ?         ;Не инициализировано
33. 004E  43 50 00 00        FLD2DD  DD     'PC'      ;Символьная строка
34. 0052  3C 7F 00 00        FLD3DD  DD     32572     ;Десятичное значение
35. 0056  11 00 00 00        FLD4DD  DD     FLD3DB - FLD2DB ;Разность адресов
36. 005A  0E 00 00 00 31 00  FLD5DD  DD     14,49     ;Две константы
37.       00 00
38.                          ;              Определ. учетверенного слова - DQ:
39.                          ;              ---------------------------------
40. 0062  ????????????????   FLD1DQ  DQ     ?          ;Не инициализировано
41. 006A  47 4D 00 00 00 00  FLD2DQ  DQ     04D47H     ;Шест. константа
42.       00 00
43. 0072  3C 7F 00 00 00 00  FLD3DQ  DQ     32572      ;Десятич. константа
44.       00 00
45.                          ;              Определение десяти байт - DT:
46.                          ;              ----------------------------
47. 007A  ?????????????????? FLD1DT  DT     ?          ;Не инициализировано
48.       ??
49. 0084  43 50 00 00 00 00  FLD2DT  DT     'PC'       ;Символьная строка
50.       00 00 00 00
51.  
52. 008E                     DATASG  ENDS
53.                                  END
54.  
55. ___________________________________________________________________________

Таким образом, если в листинге из пятого издания (см. первый пост) в обратной последовательности хранятся только DQ, что можно списать на опечатку, то в данном листинге из (предположительно) первого издания в обратной последовательности хранятся, помимо DQ, еще и DD. А в прямой же хранятся только DW (опять же, по нижеследующим цитатам Абеля сие неправильно и слова тоже должны храниться в обратной последовательности).

И казалось бы, чему и кому верить - хз.

Но. У того же Абеля встречаются - и неоднократно! - такие фразы:

... ... ...

... ... ...

... ... ...

... ... ...

... ... ...

В общем запутался окончательно :Р. Имхо - Абель сам хотел сделать как лучше, доступнее и понятнее, а получилось, в общем-то, как и всегда... :Р Бред какой-то...

Собственно WTF, уважаемые самураи ?