@@НикитаДоронин-э3ъ Желательно общаться на английском (намного лучше рус), и когда не понимаешь что-то, напоминай ей что ты нуб (новичок), тогда она упростит объяснение. Можешь еще попросить объяснить как ребёнку.
9:40 тут неоднозначная неоднозначность, т.к. при дизассемблировании формируются метки переходов je jne и т.п. из адресов и смещений в бинарнике (даже макросы можно восстановить по косвенным признакам повторения кода). поэтому при сборке все переходы будут верны, даже при изменении размера. другое дело, если сам бинарник котролирует размер или высчитывает переходы (например, прыжок на +100 байт вперед) - как вариант защиты или особенность работы.
Вобщем и целом, автор ролика прав, и именно поэтому существуют пакеты разработчика на ЯА с различным уровнем детализации, для случаев когда нужно чтобы в код вошла нужная последовательность байт ее вбивают макросом с определением инструкции побайтно
спасибо за видео, есть оффтопный вопрос, сделайте обзор на ваши гарнитуры, рабочее место и освещение на заднем фоне, особо последнее я бы mov tomy, home
7:49 Да, пожалуй лучшее объяснение, состедоточиться строго на одной архитектуре. Безо всяких pdp-11 и z80, как у комментаторов. Выбросить из головы это старьё. В одном x86/amd64 уже можно закопаться. Да еще неточности в объяснении, человеческий фактор... В одном случае add который 66 05 ждет 4 байта на вход, в другом, где 66 83 -- 2 байта. Вот и вся разница. Дизассеблер длин. У команд перемнная длина для разных случаев. И получается, что запись 66 05 01 00 неверна, она не полная. Процессор сожрет еще два байта после. А значит, взаимная однозначность очень даже имеет место. Надо 66 05 01 00 00 00 Самое главное, естественно по памяти я этого не знал. Тупо взял двоичный дизассемблерный редактор hiew, позволяющий писать файлы вручную прямо в машинных кодах, и тут же видеть ассемблерный вид.
Да, насчет 4-х байт вы правы, там не дописал нулей. Взаимной однозначности нет: было: 66 05 01 00 00 00 - дизассемблер выдал: add ax, 0x1 повторное ассемблирование: 66 83 с0 01 (и тут у нас поехала адресация) взаимная однозначность это когда add ax, 0x1 - это всегда 66 05 01 00 00 00.
@@S0ERDEVS Адресация не поехала. Тут всё правильно. add ax, 0x01 это 66 83 с0 01 add eax, 0x01 это 66 05 01 00 00 00 Чем ax отличается от eax пусть читатель сам выяснит. Но оба кода будут работать корректно на 32- и 64- битных системах.
Ассемблер должен давать возможность полного контроля генерируемого кода. Если дизассемблированный код не ассемблируется в такой же код, то это проблема дизасма. Конечно если не говорим про грязные хаки типа когда смещение является ещё и опкодом.
В случае с записью в регисты, получается на самом деле в процессоре есть разные команды для записи в разные регистры (для записи в каждый регист - своя команда, сколько регистров - столько и реально команд, а не один "muv"), при том что мнемоника одна. Это грубо говоря упрощение для программиста - нужно знать только одну мнемонику для записи и указывать регистр. Короче так была придумана первая обстракция в программировании😄 На самом деле команд в процессоре больше (реальных бинарных кодов операций), чем команд в асемблере для конкретного кристала описанных в даташите, все зависит от архитектуры.
Команда mov она одна, но она многобайтная. Команда одна, но состоит из трёх частей: 1) переложи байт 2) откуда 3) куда. Первая часть команды всегда одинаковая, а другие две могут быть разные.
Мой дисассемблер генерил ассемблер код который после ассемблирование в двоичный код полностью совпадал с исходным машинным кодом. Иначе это не дисассемблер, а хз что!
когда-то в уме простенькие задачки интерпритировали в машинный код. Конечно они отличаются в записи, но принципиально не отличаются. Команда за командой как в одном случае так и в другом.
Мы в институте для микроконтроллеров писали на ассемблере и каждую команду дублировали машинным кодом. Там ясно было видно что мнемоника просто удобное восприятие машинного кода. Короче одно и тоже. А вот компьютерщики, которые не очень понимают что такое регистр считают что это не одно и тоже.
2:51 Не согласен по поводу меток. Теряются не метки, а всего лишь их имена (как и имена переменных). Если метка в программе была использована (на нее есть jmp, call... etc), ее можно восстановить. 4:26 Лучшим примером разного синтаксиса будет наличие мнемонического ассемблера и алгебраического у некоторых производителей микроконтроллеров/цифровых сигнальных процессоров. Два ассемблера в видео: Intel и AT&T - это все примеры мнемонического ассемблера. Алгебраический, он больше похож на запись в стиле языка С. Например, мнемонический код: MOV ADDRA,AC0 ADD ADDRB,AC0,AC0 MOV AC0,ADDRB эквивалентен алгебраической записи: AC0 = @(ADDRA) AC0 = AC0 + @(ADDRB) @(ADDRB) = AC0 7:47 Тут стоит понимать, что ассемблер неотделим от архитектуры процессора (в том числе его разрядности). Некорректно сравнивать машинный код похожих инструкций у фактически разных архитектур, заявляя, что они скомпилировались в разные последовательности байтов, а значит, имеется неоднозначность. Не существует какого-то сферического ассемблера в вакууме. Есть ассемблеры 8088, 8086, 80286, 80386, и много еще каких для АРМов, DSP и прочего. 10:22 Снова мимо. Кто вам сказал, что мнемоники обязательно должны быть однобайтовыми? Они вообще кодируются по принципу бинарного дерева. Более часто употребимые могут иметь меньшую длину (меньше одного байта, например, 4 бита). Более редкие - более длинные.
1. Метка теряется, вместо нее подставляется адрес 2. не понял, вы опровергаете, дополняете или соглашаетесь? 3. архитектура одна и та же, разные варианты появляются на уровне архитектуры за счет обратной совместимости и избыточности, например на уровне АЛУ, когда есть машинные коды для двухбайтовых и четырехбайтовых значений. 4. мнемоники вообще не имеют фиксированной длины, поэтому и нет соответствия. Более того нет правила, что одной и той же мнемонике соответствует одно и то же количество совпадающих бит, они могут быть разными и определяться исходя из семантики всей команды, а не самой мнемоники.
@@S0ERDEVS 1. Метка в асме - это адрес в машинном коде. А поскольку асм с машинным кодом взаимнооднозначны, то по адресу восстанавливается метка (только с дефолтным именем). Например на асме intel 8051, mov A, my_fancy_variable cjne A, #0x12, not_equal movx A, @R0 not_equal: swap A После получения машинного кода из этого листинга, а потом дизассемблирования его, получим листинг типа такого: mov A, var_1 cjne A, #0x12, label_1 movx A, @R0 label_1: swap A По мне так слово "теряется" означает утрату без возможности ее восстановить. Что в данном случае потерялось кроме имен меток? Или что означает в вашем случае слово "теряется"? 2. Я к тому, что ассемблеры для одного и того же процессора могут принимать гораздо более причудливые формы, но это не значит, что между ними нет взаимной однозначности. Вы же не станете утверждать, что 18, 0x12, 022 и 0b00010010 - это разные числа? При любой из этих записей в памяти будет лежать одно и то же число. С листингами та же ситуация. 3. В любом случае по имени команды (или ее суффиксу в некоторых случаях), специальному байту-префиксу можно понять разрядность или вывести из разрядности ее аргументов (как транслятор и поступает). Взаимная однозначность и тут никуда не девается. Или я чего-то не догоняю? 4. Я об этом же и говорю. Конечно мнемоники транслируются в маш.код с учетом типов аргументов и их размеров. Но почему вы говорите, что нет однозначности между командами ассемблера и маш.кодом, мне не понятно. Ваш пример с mov ax, 1 / mov cx, 1 мог бы быть объяснен следующим образом. Т.к. это операция mov между регистром и константой, то mov кодируется 5-битовой последовательностью 10110 для 1-байтовой операции и 10111 для 2-байтовой (и 4-байтовой, кстати, так же). Следующие 3 бита - это номер регистра: AL - 000, CL - 001 и т.д. (для 8-битовых операндов), AX - 000, CX - 001, DX - 010 и т.д. (для 16-битовых операндов). Первый байт разобрали. Поскольку у вас 16-битные аргументы, далее должны идти 2 байта, задающие константу (у вас, кстати, 1 байт - это ошибка, но это в данном случае несущественно). И, если мне память не изменяет, для 16-битовых операндов будет нужен байт-префикс 0x66 для данной команды mov (но могу ошибаться - может, для 32-битовых операндов, т.к. на асме для x86 уже лет 20 не писал).
@@funfunfun536 20 лет не писал и такие вещи говоришь, и правда, ты гений на каком языке сейчас пишешь? Чтобы сразу учится этому языку а не другим, которые хуже. Ведь такой гений не будет писать на плохом языке
Да, это всё понятно, конечно, про ассемблер, маш. коды и как их переваривает процессор (на уровне комбинационно-последовательностной логики). Непонятно только вот что - если вдруг происходит такое, что в процессор из памяти поступает инструкция с искаженными бит/набором бит, которые у него в таблице отсутствуют, как в этом случае он работает? Вешает всю систему намертво или продолжает работу как ни в чем небывало? Или такого не бывает, что в линиях данных может оказаться неинтерпретируемая команда, т.е. размер списка команд у процессоров всегда соответствует степени двойки?
По аналогии если принять что русский язык - это "яз. высокого уровня" (одни матерных выражений (не документированные команды?) немыслимо больше...), а английский - "низкоуровневый", то после машинного перевода с русского на английский и обратно, тексты могут быть разные.
Думаю достаточно уже того что если бы это было одно и то же никто бы не создавал ассемблер, ассемблер это просто следующий этам абстракции для убодности и писания более широкими мазками, но уже менее управляемыми и кастомизируемыми. Чем выше подымаемся по уровням абстракции, там например с++, пайтон, фреймворк так называемый и так далее тем более широкий мазок и менее управляемость детальная. Вот и все. Просто те кто говорят что одно и тоже люто безграмотны и у них напрочь вообще отстуствует даже эллементарная логика инфузории. Так как если бы так то люди бы просто писали на машином как и писали и все. Они зачемто и ясно зачем создали ассемблер потом С и так далее.
Мы в институте для микроконтроллеров писали на ассемблере и каждую команду дублировали машинным кодом. Там ясно было видно что мнемоника просто удобное восприятие машинного кода. Короче одно и тоже. А вот компьютерщики, которые не очень понимают что такое регистр считают что это не одно и тоже.
Мне кажется язык ассемблера и машинный код проще объяснить так: машинный код это набор команд в виде ноликов и единичек, чтобы процессор понимал что ему делать, а язык ассемблера это уже слова которые соответствуют наборам ноликов и единичек. То есть совсем не одно и то же. На языке ассемблера писать проще, там хотя бы слова, а не нолики и единички. Остальное объяснение это уже углубленная инфа. Возможно лишняя.
Александр, саша, alex, санёк, сашка, aleksander, алексашка, шура, санька. Это всё одно и тоже или совершенно разное? Так же и ассемблер с машинными кодами это одно и тоже, только пишется по разному.
Поясните чайнику: с тем, что взаимно однозначного соответствия кода на асм и машинным нет - согласен, это понятно но на 9:24 утверждается, будто после операции дизассемблировании и затем ассемблирования программа перестанет работать??!! это ж кто ж так косячит? давайте по простому, в понятиях "рабочий/нерабочий код" положим есть машинный код М_исх - он рабочий, мы его дизассемблируем, получаем ассемблерный код АСМ - он рабочий, ведь дизассемблер работает нормально теперь мы ассемблируем код АСМ и получаем машинный код М_новый - почему он вдруг оказался нерабочим, если код АСМ - рабочий? Выходит, существует такой код на ассемблере, который верный, но после ассемблирования программа вдруг не работает? Или дизассемблер не справился и код АСМ - уже нерабочий? Есть ещё предположение. Рассматривается ситуация, когда машинный код, написанный для одного процессора подсовывается дизассемблеру под видом кода другого процессора. То есть, берём набор байт - машинный код для суперсовременного процессора, и скармливаем его дизассемблеру, которому говорим, что это код для процессора Z80 (компьютер из прошлого века ZX Spectrum). И удивляемся, почему дизассемблер пишет фигню. Так?
то чувство года начал изучать ЯП в 90х и тут пахнуло ностальгией. спасибо. ассемблер не машинный код от слова совсем. просто запустите на екзешник дизассемблер и сравните.
Хмм, а разве настолько ли сложно дизассемблеру адреса преобразовать в метки? (Конечно имена меток потеряются, но что-то типа "метка1", "метка2" и т. п. думаю во многих случаях подставить можно) P.S.: за другие архитектуры без понятия, а сам копался лишь в 64-битном интеловском (в 32-битном мне не нравились соглашения вызовов, да и все мои пк в то время уже были 64-битными)
Восстановить метку нельзя, можно создать новые из констант адресов, которые есть в коде. В один проход такие штуки не сделать, нужен многопроходный дизассемблер, который поймет где метки могли быть изначально. Т.е. это не преобразование, а логический анализ кода и создание новых меток.
@@S0ERDEVS Т.е. как та же IDA делает? Насколько я понимаю, она по файлу несколько раз пробегает, чтоб потом показывать, где метки, откуда идет запрос к константам, и т.д.
Фривольное обращение с терминами приводит к подмене понятий и подмене смысла, а это приводит к недопониманию и путаницам. Так поступают оккупанты перед агрессией. Со школы приучают употреблять слова, смысл которых НЕ ПОНЯТЕН, всё на уровне догадок и домыслов. Обзывать машинный код ассемблерным кодом, это как гвозди обзывать рукопальцами. Так, понятие "разряд числа" похерили тупыми непонятными "битами". Это не одно и то же. Они из разных контекстов. Где-то конечно можно так говорить, но только потому, что это уместно, но не потому что так удобно в произношении, может оно и удобней, но совершенно искажает смысл. Договариваются до того, что телеграфный код Бодо называют пятибитным.. Вообще-то бит это "двоичное число" (в переводе с латыни - 2 пальца) у которого 2 состояния, но не разряда! разряд то один!!! Поэтому код Бодо скорее пятиразрядный. А в разряде 2 состояния - есть контакт, нет контакта. И 150 лет назад никаких битов в помине не могло быть, было понятие разряда числа. А разряд это МЕСТО в форме записи числа. А одно место в десятичной системе содержит одно из 10 значений! Мы же не говорим что 1000 это тысячецифирное число, мы выражаем его количественным значением - тысяча. Аналогично и двоичные числа выражаются количественным значением. Но для двоичного числа нет названия, поэтому оно выражается как десятичное, потому что оно нам понятно. Когда хотим показать не числовую величину, а количество знаков, то в этом случае справедливо можем сказать, что длина двоичного числа состоит ИЗ N разрядов. И это академически ПРАВИЛЬНО. Правильным будет сказать: трёхразрядное, пятиразрядное, семиразрядное, восьмиразрядное число, шестнадцатиразрядное и т.д. Если называть это битовостью, то это академически неправильно. Тем более, обзывать разрядность аппаратной части битовостью, это неграмотно. Ну давайте назовём не "битом", а "монетой" -- восьми монетный, 32-х монетный. Может так понятнее будет? Разряд он и в Африке разряд - "размерный ряд". ( или монетный ряд?)
7:49 вот здесь, можно было-бы подробнее разжевать, полагаю. Первую команду из примера: add cx,0x1 Думаю, здесь многим осталось непонятно. А так - как обычно превосходно!
В кучу завалил. Лучше опишите как это работает по подробнее, тогда и понятнее будет. Ассемблер - по моему, это очеловечивание машинного кода. Т. Е. Бинарный код процессора описывается на человеческом языке(не битами) - словами(буквами). У разных процессоров биты одной и той же команды разные. Вот из этого и следует разница при дисассеблировании. Нам не важно знать битовые команды сложения разных процессоров. Это дело интерпретатора языка. Вот откуда идет проблема.
Add значит умножение. И нам не надо знать как это будет в двоичном коде выглядеть для интел или для амд процессора. При дисассемблировании наоборот. Надо выделить откакого проца код надо дисассемблировать. Ведь код то разный у всех. Ассемблер один для всех, а коды разные. Вот где собака ...
Насколько интересно, изучаю сейчас ассемблер и каждый раз узнаю что то новое
Ну что, как успехи?:)
Под 40 лет интерес к информатике когда в школе её ненавидел.Сколько времени упущено... Автору спасибо за толковое объяснение.
Лучше поздно чем никогда! Тем более с ChatGPT изучать это все намного проще.
@@sudo-apt-upgrade-brainА как подскажи правильно вести диалог с нейронкой, дабы изучение было более лëгким?
@@НикитаДоронин-э3ъ Желательно общаться на английском (намного лучше рус), и когда не понимаешь что-то, напоминай ей что ты нуб (новичок), тогда она упростит объяснение. Можешь еще попросить объяснить как ребёнку.
@@НикитаДоронин-э3ъна гуглите порядок изучения интересующего вас языка и следуйте плану
@@НикитаДоронин-э3ъможете у неё спросить. Она подскажет
Превьюха запутала
Машинный код не это assembler😆
Спасибо за видос.
Большое спасибо. Решил подписаться.
Хор :D весело. Видать тоде нравиться коверкать слова)
9:40 тут неоднозначная неоднозначность, т.к. при дизассемблировании формируются метки переходов je jne и т.п. из адресов и смещений в бинарнике (даже макросы можно восстановить по косвенным признакам повторения кода).
поэтому при сборке все переходы будут верны, даже при изменении размера.
другое дело, если сам бинарник котролирует размер или высчитывает переходы (например, прыжок на +100 байт вперед) - как вариант защиты или особенность работы.
О, класс! Всегда интересовал этот вопрос, но не находил толковый ответ .
Гениальный видео ролик. Как прочитал название и сразу сюда, не удержался😂😂😂
продолжай, очень интересно!
Заумно объясняешь дружище.
Вобщем и целом, автор ролика прав, и именно поэтому существуют пакеты разработчика на ЯА с различным уровнем детализации, для случаев когда нужно чтобы в код вошла нужная последовательность байт ее вбивают макросом с определением инструкции побайтно
Большое спасибо за понятное объяснение Соер !
Соер, как написали первую операционную систему, когда не было ни одной операционной системы?
@@mimocrocodil210 корневой станок от которого произошли все остальные был дарован инопланетянами в 408 году до нэ
Спасибо, интересная тема.
Соер - ты лучший по компам на рутубе !!!
спасибо за видео, есть оффтопный вопрос, сделайте обзор на ваши гарнитуры, рабочее место и освещение на заднем фоне, особо последнее я бы mov tomy, home
7:49 Да, пожалуй лучшее объяснение, состедоточиться строго на одной архитектуре. Безо всяких pdp-11 и z80, как у комментаторов. Выбросить из головы это старьё. В одном x86/amd64 уже можно закопаться. Да еще неточности в объяснении, человеческий фактор...
В одном случае add который 66 05 ждет 4 байта на вход, в другом, где 66 83 -- 2 байта.
Вот и вся разница. Дизассеблер длин. У команд перемнная длина для разных случаев.
И получается, что запись 66 05 01 00 неверна, она не полная. Процессор сожрет еще два байта после. А значит, взаимная однозначность очень даже имеет место.
Надо 66 05 01 00 00 00
Самое главное, естественно по памяти я этого не знал. Тупо взял двоичный дизассемблерный редактор hiew, позволяющий писать файлы вручную прямо в машинных кодах, и тут же видеть ассемблерный вид.
Да, насчет 4-х байт вы правы, там не дописал нулей.
Взаимной однозначности нет:
было: 66 05 01 00 00 00 -
дизассемблер выдал: add ax, 0x1
повторное ассемблирование: 66 83 с0 01 (и тут у нас поехала адресация)
взаимная однозначность это когда add ax, 0x1 - это всегда 66 05 01 00 00 00.
@@S0ERDEVS Адресация не поехала. Тут всё правильно.
add ax, 0x01 это 66 83 с0 01
add eax, 0x01 это 66 05 01 00 00 00
Чем ax отличается от eax пусть читатель сам выяснит.
Но оба кода будут работать корректно на 32- и 64- битных системах.
Офигенно! Даёшь больше таких видосов!!!
Некоторые вещи не знал )
Спасибо за видео.Коммент в поддержку!
Благодарю за видео, очень качественно и информативно
Спасибо, было интересно!
Блин это так интересно, спасибо соер за объяснение
Ассемблер должен давать возможность полного контроля генерируемого кода. Если дизассемблированный код не ассемблируется в такой же код, то это проблема дизасма. Конечно если не говорим про грязные хаки типа когда смещение является ещё и опкодом.
Ассемблер мнемоническое представление машинных кодов. Есть еще макрорасширения, для компоновки и компиляции кода. На этом все.
Спасибо. Было интересно
хор )
После хора закрыл это бессмысленное видео.
В случае с записью в регисты, получается на самом деле в процессоре есть разные команды для записи в разные регистры (для записи в каждый регист - своя команда, сколько регистров - столько и реально команд, а не один "muv"), при том что мнемоника одна. Это грубо говоря упрощение для программиста - нужно знать только одну мнемонику для записи и указывать регистр. Короче так была придумана первая обстракция в программировании😄
На самом деле команд в процессоре больше (реальных бинарных кодов операций), чем команд в асемблере для конкретного кристала описанных в даташите, все зависит от архитектуры.
Что такое команда «muv»?😅
Команда mov она одна, но она многобайтная. Команда одна, но состоит из трёх частей:
1) переложи байт
2) откуда
3) куда.
Первая часть команды всегда одинаковая, а другие две могут быть разные.
Ни разу не слышал утверждения, что ассамблер и машинный код это одно и то же
Тоже первый раз про такое слышу. Если это одно и тоже, то все ассемблеры = машинный код или какой-то конкретный ассемблер? )))
Мне говорили что ассемблер максимально приближен к машинному коду
А я ранее слышал... от самого себя)
Ну приблизительно так и есть. Асм же машинно-ориентированный яп.
🫡
Мой дисассемблер генерил ассемблер код который после ассемблирование в двоичный код полностью совпадал с исходным машинным кодом. Иначе это не дисассемблер, а хз что!
Мне обзор понравился, тема интересная
Крайне познавательно, структурированно и локанично! Один из лучших каналов на тему программирования…, спасибо за труд! :)
когда-то в уме простенькие задачки интерпритировали в машинный код. Конечно они отличаются в записи, но принципиально не отличаются. Команда за командой как в одном случае так и в другом.
Мы в институте для микроконтроллеров писали на ассемблере и каждую команду дублировали машинным кодом. Там ясно было видно что мнемоника просто удобное восприятие машинного кода. Короче одно и тоже.
А вот компьютерщики, которые не очень понимают что такое регистр считают что это не одно и тоже.
Ассемблер это компилятор языка ассемблера
2:51 Не согласен по поводу меток. Теряются не метки, а всего лишь их имена (как и имена переменных). Если метка в программе была использована (на нее есть jmp, call... etc), ее можно восстановить.
4:26 Лучшим примером разного синтаксиса будет наличие мнемонического ассемблера и алгебраического у некоторых производителей микроконтроллеров/цифровых сигнальных процессоров. Два ассемблера в видео: Intel и AT&T - это все примеры мнемонического ассемблера. Алгебраический, он больше похож на запись в стиле языка С. Например,
мнемонический код:
MOV ADDRA,AC0
ADD ADDRB,AC0,AC0
MOV AC0,ADDRB
эквивалентен алгебраической записи:
AC0 = @(ADDRA)
AC0 = AC0 + @(ADDRB)
@(ADDRB) = AC0
7:47 Тут стоит понимать, что ассемблер неотделим от архитектуры процессора (в том числе его разрядности). Некорректно сравнивать машинный код похожих инструкций у фактически разных архитектур, заявляя, что они скомпилировались в разные последовательности байтов, а значит, имеется неоднозначность. Не существует какого-то сферического ассемблера в вакууме. Есть ассемблеры 8088, 8086, 80286, 80386, и много еще каких для АРМов, DSP и прочего.
10:22 Снова мимо. Кто вам сказал, что мнемоники обязательно должны быть однобайтовыми? Они вообще кодируются по принципу бинарного дерева. Более часто употребимые могут иметь меньшую длину (меньше одного байта, например, 4 бита). Более редкие - более длинные.
1. Метка теряется, вместо нее подставляется адрес
2. не понял, вы опровергаете, дополняете или соглашаетесь?
3. архитектура одна и та же, разные варианты появляются на уровне архитектуры за счет обратной совместимости и избыточности, например на уровне АЛУ, когда есть машинные коды для двухбайтовых и четырехбайтовых значений.
4. мнемоники вообще не имеют фиксированной длины, поэтому и нет соответствия. Более того нет правила, что одной и той же мнемонике соответствует одно и то же количество совпадающих бит, они могут быть разными и определяться исходя из семантики всей команды, а не самой мнемоники.
@@S0ERDEVS 1. Метка в асме - это адрес в машинном коде. А поскольку асм с машинным кодом взаимнооднозначны, то по адресу восстанавливается метка (только с дефолтным именем). Например на асме intel 8051,
mov A, my_fancy_variable
cjne A, #0x12, not_equal
movx A, @R0
not_equal:
swap A
После получения машинного кода из этого листинга, а потом дизассемблирования его, получим листинг типа такого:
mov A, var_1
cjne A, #0x12, label_1
movx A, @R0
label_1:
swap A
По мне так слово "теряется" означает утрату без возможности ее восстановить. Что в данном случае потерялось кроме имен меток? Или что означает в вашем случае слово "теряется"?
2. Я к тому, что ассемблеры для одного и того же процессора могут принимать гораздо более причудливые формы, но это не значит, что между ними нет взаимной однозначности. Вы же не станете утверждать, что 18, 0x12, 022 и 0b00010010 - это разные числа? При любой из этих записей в памяти будет лежать одно и то же число. С листингами та же ситуация.
3. В любом случае по имени команды (или ее суффиксу в некоторых случаях), специальному байту-префиксу можно понять разрядность или вывести из разрядности ее аргументов (как транслятор и поступает). Взаимная однозначность и тут никуда не девается. Или я чего-то не догоняю?
4. Я об этом же и говорю. Конечно мнемоники транслируются в маш.код с учетом типов аргументов и их размеров. Но почему вы говорите, что нет однозначности между командами ассемблера и маш.кодом, мне не понятно. Ваш пример с mov ax, 1 / mov cx, 1 мог бы быть объяснен следующим образом. Т.к. это операция mov между регистром и константой, то mov кодируется 5-битовой последовательностью 10110 для 1-байтовой операции и 10111 для 2-байтовой (и 4-байтовой, кстати, так же). Следующие 3 бита - это номер регистра: AL - 000, CL - 001 и т.д. (для 8-битовых операндов), AX - 000, CX - 001, DX - 010 и т.д. (для 16-битовых операндов). Первый байт разобрали. Поскольку у вас 16-битные аргументы, далее должны идти 2 байта, задающие константу (у вас, кстати, 1 байт - это ошибка, но это в данном случае несущественно). И, если мне память не изменяет, для 16-битовых операндов будет нужен байт-префикс 0x66 для данной команды mov (но могу ошибаться - может, для 32-битовых операндов, т.к. на асме для x86 уже лет 20 не писал).
@@funfunfun536 Бро, тормозни, хочешь чтобы Соера от кишонок отвернуло?
@@funfunfun536 20 лет не писал и такие вещи говоришь, и правда, ты гений
на каком языке сейчас пишешь? Чтобы сразу учится этому языку а не другим, которые хуже. Ведь такой гений не будет писать на плохом языке
Благодарю! Очень интересно!! 👍🔥💯подписка+1
Да, это всё понятно, конечно, про ассемблер, маш. коды и как их переваривает процессор (на уровне комбинационно-последовательностной логики). Непонятно только вот что - если вдруг происходит такое, что в процессор из памяти поступает инструкция с искаженными бит/набором бит, которые у него в таблице отсутствуют, как в этом случае он работает? Вешает всю систему намертво или продолжает работу как ни в чем небывало? Или такого не бывает, что в линиях данных может оказаться неинтерпретируемая команда, т.е. размер списка команд у процессоров всегда соответствует степени двойки?
эксепшен выкидывает
По аналогии если принять что русский язык - это "яз. высокого уровня" (одни матерных выражений (не документированные команды?) немыслимо больше...), а английский - "низкоуровневый", то после машинного перевода с русского на английский и обратно, тексты могут быть разные.
Все же у разговорных языков это работает в обе стороны, но аналогия неплохая
4:00 - А что из себя представляют соглашения?
Думаю достаточно уже того что если бы это было одно и то же никто бы не создавал ассемблер, ассемблер это просто следующий этам абстракции для убодности и писания более широкими мазками, но уже менее управляемыми и кастомизируемыми. Чем выше подымаемся по уровням абстракции, там например с++, пайтон, фреймворк так называемый и так далее тем более широкий мазок и менее управляемость детальная. Вот и все. Просто те кто говорят что одно и тоже люто безграмотны и у них напрочь вообще отстуствует даже эллементарная логика инфузории. Так как если бы так то люди бы просто писали на машином как и писали и все. Они зачемто и ясно зачем создали ассемблер потом С и так далее.
Мы в институте для микроконтроллеров писали на ассемблере и каждую команду дублировали машинным кодом. Там ясно было видно что мнемоника просто удобное восприятие машинного кода. Короче одно и тоже.
А вот компьютерщики, которые не очень понимают что такое регистр считают что это не одно и тоже.
Мне кажется язык ассемблера и машинный код проще объяснить так: машинный код это набор команд в виде ноликов и единичек, чтобы процессор понимал что ему делать, а язык ассемблера это уже слова которые соответствуют наборам ноликов и единичек. То есть совсем не одно и то же. На языке ассемблера писать проще, там хотя бы слова, а не нолики и единички. Остальное объяснение это уже углубленная инфа. Возможно лишняя.
Согласен
Александр, саша, alex, санёк, сашка, aleksander, алексашка, шура, санька. Это всё одно и тоже или совершенно разное?
Так же и ассемблер с машинными кодами это одно и тоже, только пишется по разному.
Поясните чайнику:
с тем, что взаимно однозначного соответствия кода на асм и машинным нет - согласен, это понятно
но на 9:24 утверждается, будто после операции дизассемблировании и затем ассемблирования программа перестанет работать??!!
это ж кто ж так косячит?
давайте по простому, в понятиях "рабочий/нерабочий код"
положим есть машинный код М_исх - он рабочий,
мы его дизассемблируем, получаем ассемблерный код АСМ - он рабочий, ведь дизассемблер работает нормально
теперь мы ассемблируем код АСМ и получаем машинный код М_новый - почему он вдруг оказался нерабочим, если код АСМ - рабочий?
Выходит, существует такой код на ассемблере, который верный, но после ассемблирования программа вдруг не работает?
Или дизассемблер не справился и код АСМ - уже нерабочий?
Есть ещё предположение. Рассматривается ситуация, когда машинный код, написанный для одного процессора подсовывается дизассемблеру под видом кода другого процессора. То есть, берём набор байт - машинный код для суперсовременного процессора, и скармливаем его дизассемблеру, которому говорим, что это код для процессора Z80 (компьютер из прошлого века ZX Spectrum). И удивляемся, почему дизассемблер пишет фигню. Так?
Тем что ассемблер компилируется в машинный код. Все. О чем тут 13 минут рассуждать
S0ER - Луч света в темном царстве интернета... Удачи!!!
Кто пишет в машинных кодах, в ассемблере не смеётся 😇
ЗЫЖ Программирование на листочке рулит. 😂 25лет уж минуло...
то чувство года начал изучать ЯП в 90х и тут пахнуло ностальгией. спасибо. ассемблер не машинный код от слова совсем. просто запустите на екзешник дизассемблер и сравните.
с чем сравнить ?
@@AntiBandera с исходником написанным вами же.
Хмм, а разве настолько ли сложно дизассемблеру адреса преобразовать в метки? (Конечно имена меток потеряются, но что-то типа "метка1", "метка2" и т. п. думаю во многих случаях подставить можно)
P.S.: за другие архитектуры без понятия, а сам копался лишь в 64-битном интеловском (в 32-битном мне не нравились соглашения вызовов, да и все мои пк в то время уже были 64-битными)
Восстановить метку нельзя, можно создать новые из констант адресов, которые есть в коде. В один проход такие штуки не сделать, нужен многопроходный дизассемблер, который поймет где метки могли быть изначально. Т.е. это не преобразование, а логический анализ кода и создание новых меток.
@@S0ERDEVS Т.е. как та же IDA делает? Насколько я понимаю, она по файлу несколько раз пробегает, чтоб потом показывать, где метки, откуда идет запрос к константам, и т.д.
Кто в теме, ответьте максимально подробно в чем отличие байт кода от опкодов?
Если не глядя быстро прочитать S0ER то вижу SBER...
Фривольное обращение с терминами приводит к подмене понятий и подмене смысла, а это приводит к недопониманию и путаницам. Так поступают оккупанты перед агрессией.
Со школы приучают употреблять слова, смысл которых НЕ ПОНЯТЕН, всё на уровне догадок и домыслов.
Обзывать машинный код ассемблерным кодом, это как гвозди обзывать рукопальцами.
Так, понятие "разряд числа" похерили тупыми непонятными "битами". Это не одно и то же. Они из разных контекстов. Где-то конечно можно так говорить, но только потому, что это уместно, но не потому что так удобно в произношении, может оно и удобней, но совершенно искажает смысл. Договариваются до того, что телеграфный код Бодо называют пятибитным.. Вообще-то бит это "двоичное число" (в переводе с латыни - 2 пальца) у которого 2 состояния, но не разряда! разряд то один!!! Поэтому код Бодо скорее пятиразрядный. А в разряде 2 состояния - есть контакт, нет контакта. И 150 лет назад никаких битов в помине не могло быть, было понятие разряда числа. А разряд это МЕСТО в форме записи числа. А одно место в десятичной системе содержит одно из 10 значений! Мы же не говорим что 1000 это тысячецифирное число, мы выражаем его количественным значением - тысяча. Аналогично и двоичные числа выражаются количественным значением. Но для двоичного числа нет названия, поэтому оно выражается как десятичное, потому что оно нам понятно. Когда хотим показать не числовую величину, а количество знаков, то в этом случае справедливо можем сказать, что длина двоичного числа состоит ИЗ N разрядов. И это академически ПРАВИЛЬНО. Правильным будет сказать: трёхразрядное, пятиразрядное, семиразрядное, восьмиразрядное число, шестнадцатиразрядное и т.д. Если называть это битовостью, то это академически неправильно. Тем более, обзывать разрядность аппаратной части битовостью, это неграмотно. Ну давайте назовём не "битом", а "монетой" -- восьми монетный, 32-х монетный. Может так понятнее будет? Разряд он и в Африке разряд - "размерный ряд". ( или монетный ряд?)
Вы очень много сидите за компом?
7:49 вот здесь, можно было-бы подробнее разжевать, полагаю. Первую команду из примера: add cx,0x1
Думаю, здесь многим осталось непонятно.
А так - как обычно превосходно!
Написал выше объяснение.
Видео о том, чем машинный код отличается от ассемблера. А не о том, как работает компилятор ассемблера.
На кого видео рассчитано?
Кто пишет на ассемблере те и так в курсе.
Кто не пишет, .....
Сны и сновидения - в чем отличие?
Hydra, хм, так вот в чем секрет успеха
спасибо.
high skill
првиет всем кул хацкерам
Вообще слабо понимаю о чем здесь дискусс. Ассемблер не является машинным кодом и это аксиома.
Вот почему Ремастеры так с нами поступили. А я пинял на "руко.....".
Вопрос: Кто нибуть что-то делает чтобы это вылечить?
охеренно, лайк
Тебя с работы что ли выгнали? Ролики каждый день. Ты уж наверное забыл, как код писать. На тик-ток скоро планируешь?
CD 19 всем.
это все проблема компилятора но это максимально близкий код ибо надо следить за памятью, потоками и тд..
Значит ты машинник?
Нет, я - соер
Словоблудие, поддерживаемое эклектикой архитектур IA-32/64.
В кучу завалил. Лучше опишите как это работает по подробнее, тогда и понятнее будет. Ассемблер - по моему, это очеловечивание машинного кода. Т. Е. Бинарный код процессора описывается на человеческом языке(не битами) - словами(буквами). У разных процессоров биты одной и той же команды разные. Вот из этого и следует разница при дисассеблировании. Нам не важно знать битовые команды сложения разных процессоров. Это дело интерпретатора языка. Вот откуда идет проблема.
Add значит умножение. И нам не надо знать как это будет в двоичном коде выглядеть для интел или для амд процессора. При дисассемблировании наоборот. Надо выделить откакого проца код надо дисассемблировать. Ведь код то разный у всех. Ассемблер один для всех, а коды разные. Вот где собака ...
Кликбейт.
Сойер, а ты можешь снизойти к украинскому деду??
И поговорить...
Если 1 такт процесса соответствует 1 команде ASM, то это машинный код, иначе это комбинация нескольких машинных команд под одной командой ASM
извините но это бред
много пустой болтовни
Ассемблер это самый обычный язык программирования!!!! Машинный код совсем другая вещь!!!