Хранение данных в двоичном коде.

[Loengreen]

Сообщение от min@y™

Вложение 89802

К сожалению на черном фоне синий текст на этой картинке почти не видно((
Но кажется я немного понял, особенно опираясь на блокнот с адресами и цифрами, а это как раз те самые нули и единицы. Т.е. процессору не важно, что именно стоит перед ним, просто исходя из данных в строке он делает то, что, что записано в памяти. Тут не очень понятно, что число 199 на скрине записано в одной строке, а число 555 записано в двух разных строках причем не последовательно, а сначала его вторая половина 2B, а в следующей строке - первая половина - 02. Если я правильно понял, получается, что процессор как бы разделяет последовательность цифр на "блоки", что-то типа первый блок - адрес, второй блок информация, третий блок команда. И исходя из своей архитектуры просто оперирует этими блоками. И если ему поступила информация, то исходя из этой последовательности и будет выполнено то или иное действие. И получается что все что в первом блоке - адрес, во втором - то с чем надо проводить операцию, в третьем - операция. Но по такой логике каждый идентичный "блок" должен быть одинаковым по размеру. В блокноте этого вроде бы не наблюдается. В общем какое-то осознание начинает потихоньку приходить, но пока немного каша в голове.

Спасибо за ответы!

[min@y™]

Сообщение от Loengreen

Спасибо за ответы!

[R71MT]

Loengreen, программа - это не тупое сборище нулей и единиц. Каждая программа имеет т.н. точку входа - "Entry Point". Исполнение программы начинается именно с этой точки (байта), а не от куда-попало. Там должны располагаться байты, которые 'понимает' процессор, иначе программа рухнет. Точка входа никогда не указывает на секцию-данных, а только на секцию-кода.

Чтобы понять принципы декодирования инструкций процессором, удобно воспользоваться отладчиком. - например виндовым DEBUG.COM. Компиляторы всех уровней переводят код на ассемблер. Команда сложения в ассемблере называется [ADD] = Adding, команда пересылки данных - [MOV] = Move. Теперь запускаешь DEBUG [Win+R-->debug] и вводишь такие команды:

-a
139E:0100  mov  ax,199       ; поместить в регистр(АХ) значение(199h)
139E:0103  add  ax,555       ; прибавить к АХ число(555h)
139E:0106                    ; сумма будет в регистре(АХ) = 06EEh
-r
AX=0000  BX=0000  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=139E  ES=139E  SS=139E  CS=139E  IP=0100   NV UP EI PL NZ NA PO NC
139E:0100   B89901        MOV     AX,0199
-t
AX=0199  BX=0000  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=139E  ES=139E  SS=139E  CS=139E  IP=0103   NV UP EI PL NZ NA PO NC
139E:0103   055505        ADD     AX,0555
-t
AX=06EE  BX=0000  CX=0000  DX=0000  SP=FFEE  BP=0000  SI=0000  DI=0000
DS=139E  ES=139E  SS=139E  CS=139E  IP=0106   NV UP EI PL NZ NA PE NC
139E:0106   0000          ADD     [BX+SI],AL                         DS:0000=CD

Команда(А) в окне отладчика - это "Assembly", т.е. ввести код.
Команда(R) - это "Registers" - показывает состояния регистров процессора.
Команда(T) - это "Trace" - трассировка - исполнение заданного кода.

В режиме трассировки, слева от команды, отладчик показывает опкоды этих команд. Например, данное сложение начинается с инструкции [MOV AX,0199], опкодом которой являются 3-байта со значением B89901h. Это и есть твои нули и единички, только в HEX. Весь исходник в машинном коде процессора будет выглядеть так:

B8 99 01 05 55 05

Процессор берёт первый байт, в данном случае(B8h), и декодирует его по схеме, как показано на рисунке. Он знает, что B8h - это [mov ax], B9h - [mov cx], BAh - [mov dx], и т.д.
Если ЦП не сможет декодировать байт, то остановится с ошибкой - "Неизвестная инструкция!".

Декодирование инструкций - муторное дело, и там не всё так-просто. Взяв в руки первый байт и декодировав его, он узнает, сколько байтов нужно пропустить после первого. - т.е. вычислит длинну этой инструкции. Она может быть до от одного, до 12-байт.

Если интересна эта тема, можешь почитать маны Intel'a (IA32-64 Vol.2), или статью К.Касперски "Техника дизассемблирования в уме". Узнаешь много нового..

[Loengreen]

R71MT
Огромное спасибо! Вот ответ на мой вопрос, который я не мог точно сформулировать! Все дело в первом байте, который и определяет что делать дальше и задает размер команды и, соответсвтенно, чисел, учавствующих в операциях! Это именно то, чего я не мог понять, как именно считаются эти нули и единицы! Грубо говоря первый байт задает правильный счет того, что следует за ним и в итоге нет путаницы что из цифр есть команды, а что есть числа!
Еще раз спасибо, а то всю голову сломал! Теперь стало все на свои места!

[Loengreen]

Kris Kaspersky "ТОНКОСТИ ДИЗАССЕМБЛИРОВАНИЯ" - замечательная статья. В ней есть ответы на некоторые мои другие не заданные вопросы.
Благодарю!

[Loengreen]

R71MT
Если утрировать, то первый байт является не просто командой, а эдаким "указателем", который и говорит что следует за ним и в каком размере до следующего "указателя", который тоже говорит что следует за ним и в каком размере! Т.е. первый байт определяет сколько нулей и единиц, следующих за ним надо считать числами, сколько командами и так далее по цепочке!
Теперь даже не верится, как можно было не понимать этого раньше!
Странно, что в институте такого не объясняли совсем. Вам надо идти работать преподавателем!

[R71MT]

Сообщение от Loengreen

первый байт является не просто командой, а эдаким "указателем", который и говорит что следует за ним и в каком размере до следующего "указателя"

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

Процессору по-барабану, что и в какой последовательности выполнять. Он тупо работает и всё.. Вся ответственность на программисте. Исполнение данных может привести к непредсказуемым последствиям, и хорошо если ОС отреагирует на это обычным исключением, а не бсодом.

Первый байт бывает опкодом только в реальном\16-битном режиме работы процессора (MS-DOS). В защищённом-же (Win.32\64-бит) - это префикс команды, о чём свидетельствует скрин выше. Например, если поместить одно и то-же значение в АХ и ЕАХ, то опкоды будут разные - к 32-битному(ЕАХ) добавиться префикс(66h) и инструкция станет на 3-байта длиннее. Вот окно 32-битного отладчика 'GRDB':

GRDB version 1.7 Copyright (c) LADsoft
History enabled

->a
1700:0100   mov   ax,199
1700:0103   mov  eax,199
1700:0109
->r
1700:0100   B8 99 01              mov   ax,0199
->t
1700:0103   66 B8 99 01 00 00     mov  eax,00000199
->

Здесь видно, что маш\код с ЕАХ в точности совпадает со-схемой декодирования. т.е. сначала идёт префикс, а потом опкод и ModR\M.

А вот пример на ассемблере с потоком 'правильных' данных вместо кода..

; fasm-code 
; сначала типичиный код
;-----------------------
org 100h
jmp start                 ; переход на точку входа..

a   dw  199h              ; данные (переменные "а,b" со-значением 199h, 1F3h)
b   dw  1F3h              ; ^^^ если убрать [jmp start] то программа рухнет.

start: mov  ax,[b]        ; переменные в регистры АХ\ВХ
       mov  bx,[a]        ; ^^^

       add  ax,555h       ; прибавить к АХ 555h
       sub  ax,bx         ; отнять ВХ от АХ
       ret                ; выход из программы!

..а теперь это-же в маш\кодах процессора (с метки старт),
и проц выполнит этот поток чисел без всяких возражений:

org 100h
jmp start

a   dw  199h
b   dw  1F3h

start:  db  0A1h,04h,01h,8Bh,1Eh,02h
        db  01h,05h,55h,05h,29h,0D8h
        ret

Программирование в маш\кодах таит в себе столько секретов, что можно говорить об этом бесконечно. Главное понять, что программа имеет определённую структуру, и если поменять в ней хоть пару байт местами, то вся конструкция может превратиться в кучу никчёмных байт (а может и нет - смотря на какое ухо сядет муха).

..а К.Касперски дело глаголил (земля ему пухом!)..
у него около 500-статей и все толковые: https://www.evilfingers.com/publicat...esearch_RU.php

[Loengreen]

Сообщение от R71MT

проц нарвётся на поток данных (не кода), где первый байт совпадёт с каким-нить опкодом. ЦП может выполнить его.

Вот тут и была суть, как он понимает что инструкции, а что просто данные

Сообщение от R71MT

Первый байт бывает опкодом только в реальном\16-битном режиме работы процессора (MS-DOS). В защищённом-же (Win.32\64-бит) - это префикс команды, о чём свидетельствует скрин выше. Например, если поместить одно и то-же значение в АХ и ЕАХ, то опкоды будут разные - к 32-битному(ЕАХ) добавиться префикс(66h) и инструкция станет на 3-байта длиннее.

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

R71MT, Вы, можно сказать, спасли меня, все встало на свои места