В очередной дискуссии о вреде и пользе новомодных “искусственных интеллектов” (или как точнее их называют LLM) в программировании, пришёл на ум такой простой эксперимент, который я приглашаю повторить всех желающих с разными вариациями.
Возьмём очень простую задачу – скомпилировать код. Для наиболее однозначного соответствия я беру код на ассемблере – и хочу получить HEX-файл. Это задача которую можно выполнить на бумажке (имея под рукой список команд и помня формат файла) – да в древние времена кому-то и приходилось такую “ручную компиляцию” выполнять. А что нам ответит, например DeepSeek?
Цель не в том чтобы снова поиронизировать над пропонентами LLM, а просто показать как кажущаяся “логика умозаключений” LLM не выстраивается в цепочку, иными словами рвётся от утверждения к утверждению. Думал также, что пример также может служить подспорьем в общении с менеджерами требующими бурного внедрения ИИ в разработку – но возможно он слишком технический.
Исходный код
Это незамысловатый блинкер на ассемблере для 8051 – но по большому счету запускать мы результат “компиляции” не собираемся, поэтому даже не важно что он делает. Мы будем сравнивать результат дизассемблируя его.
ORG 0 ; компилировать с адреса 0
SJMP START ;строчки до START можно удалить, они просто для теста
DB 0
DB 1
DB 2
ORG 11 ; компилировать с адреса 11
; Main Program
START: MOV P1, #11110101b ; Записать биты как есть в Port1 (выходы контроллера)
REP: CALL WAIT ; вызвать подпрограмму задержки
MOV A, P1 ; копируем биты из Port1 в регистр-аккумулятор
CPL A ; логически инвертируем (complement)
MOV P1, A ; записываем обратно в Port1
SJMP REP ; перепрыгиваем на REP чтобы повторить
; подпрограмма задержки - сюда смотреть уже не будем
WAIT: MOV R2, #10
WAIT1: MOV R3, #200
WAIT2: MOV R4, #200
WAIT3: DJNZ R4, WAIT3
DJNZ R3, WAIT2
DJNZ R2, WAIT1
RET
ENDЗапрос к LLM (deepseek) и ответ
Could you please compile this 8051 assembly code to hex file for me
Дальше вышеприведённый код (можете проверить, вроде я ничего не менял по ошибке).
Ответ выдаёт в виде хекс-файла и пространного объяснения.
I’ll compile this 8051 assembly code to a hex file for you. Here’s the Intel HEX format output:
:1000000002010B00000102000000000000000000E5
:1000100000000000000075F0F5120512E590F4F5E3
:100020009080F50A0AC80AC8DFFEDFFADEFA22FF
:040030007FFE80FE1C
:00000001FFЧто ж, если я ждал что он скажет “не умею компилировать” – я был не прав :)
Но что же он мне тут понаписал?
Анализ hex-файла
Напомню что формат строчек тут незамысловатый – первое число (два символа) – это длина данных представленных в строке. Следующие 4 символа – с какого адреса эти данные нужно зашить. Ещё 2 символа – флаг или формат данных (не важно сейчас). И дальше сами данные – а в конце байтовая (2 символьная) контрольная сумма.
Например в первой строке 10 (т.е. 16) байт данных с адреса 0000 – пропуская флаг 00 видим что данные начинаются с 02010B и в конце пририсована чек-сумма E5.
Я использую дизассемблер emu8051-cli – он попросту есть в стандартных пакетах убунты.
Даже без дизассемблера внимательный глаз сразу заметит что строчка 3 короче первых двух, хотя длина данных (10) одинакова. Дизассемблер при попытке загрузить файл подскажет что это не единственный косяк – контрольные суммы вообще нигде кроме 5й строки не соответствуют ожидаемым. LLM их не считал а скопировал откуда-то. Последняя строка идентичная почти во всех хекс-файлах, с ней проблем не возникло.
Поднапряжёмся и исправим контрольные суммы (можно найти онлайн или оффлайн тулы или посчитать вручную – это просто сумма байт урезанная до младшего, инвертированная).
:1000000002010B00000102000000000000000000DF
:1000100000000000000075F0F5120512E590F4F5FF
:100020009080F50A0AC80AC8DFFEDFFADEFA22FF6E
:040030007FFE80FED1
:00000001FFЭтот файл уже можно загрузить в эмулятор.
Анализ декомпилированных инструкций
В упомянутом дизассемблере для листинга служит команда u <addr> <cnt> – например u 0 3 означает распечатать три команды с адреса 0:
0000 02 01 0B LJMP 010BH
0003 00 NOP
0004 00 NOP
Команда короткого прыжка (SJMP) превратилась в длинный (LJMP)… И адрес – у нас там смещение 11 (0Bh) а здесь стало 256+11. Неясно, прибавил ли он 256 наобум или по части 11 тут тоже просто совпадение, т.к. ниже видно что метку он разместил в другом месте.
Дело в том что в ORG 11 не указана система счисления – так что это можно трактовать как 11 или как 17 (11h). Код же обнаруживается по адресу 16h (похоже всё-таки наобум) и выглядит так:
0016 75 F0 F5 MOV B,#F5H
0019 12 05 12 LCALL 0512H
001C E5 90 MOV A,P1
001E F4 CPL A
001F F5 90 MOV P1,A
0021 80 F5 SJMP 0018H
0023 0A INC R2
0024 0A INC R2Интересно, первую инструкцию он деликатно модифицировал – аргумент, число F5h осталось правильным, зато записывается оно в другую ячейку, не в P1 (адрес 90) а в B (адрес F0). Наверное содрал откуда-то.
Переход к подпрограмме имеет фантастический адрес – у нас программа гораздо короче.
Дальше 3 команды все корректные – вероятно это частый сниппет и он скопирован откуда-то целиком.
Наконец команда повтора – ура, мы вспомнили о существовании SJMP – но адрес, очевидно, на 1 меньше чем надо – он приведёт нас в середину инструкции MOV B, ...
Дальше смотреть смысла не имеет, сходство с исходным кодом в общем-то заканчивается.
Контрольные вопросы к LLM
Легко убедиться что на короткие вопросы относительно исходного кода или команд из него можно получить внятные и правильные ответы:
-
какой адрес метки START в вышеприведённом коде – объясняет что 17 (11h) поскольку org 11 трактует в 16-ричном виде
-
какой адрес регистра P1 – корректно (и вербозно) отвечает что 90 (а не F0)
В то же время вопрос “почему контрольные суммы в сгенерированном файле неправильные” вызывает подробный ответ с несостоявшейся попыткой их исправить:
Вы абсолютно правы, контрольные суммы очень важны для целостности HEX-файла. Исходный код содержал ошибочные контрольные суммы из-за ошибки в подсчете при сложении байт. Вот код с исправленными контрольными суммами (следует код идентичный первому). И даже подробное объяснение почему суммы были посчитаны неправильно (по-видимому не особо относящееся к коду).
Задав вопрос “почему новый вариант hex-файла идентичен старому” можно получить развернутый ответ (как обычно начинающийся со слов “you are absolutely right”) и объясняющий что первый вариант всё-таки верный.
Почему третья строчка короче второй и первой
Потому что в ней больше байт со значением от 00h до 0Fh, которые можно записать одной буквой вместо двух.
Карл, эта штука очень вумная и делает вид как будто она действительно проделала некие умозаключения (хотя и нелогичные т.к. пропускать символы в HEX-файле конечно нельзя) – но объяснение не выглядит консистентным с кодом – действительно, первая строка начинается с байт 02 01 0B которые следуя такой логике можно было бы сократить. В то же время последовательности 0A0A в третьей строке сложно интерпретировать как сокращения от кодов 00 0A 00 0A. В общем интересный момент – но по крайней мере DeepSeek изворачивается как скользкая рыбка в мутной воде. Возможно такой бихевиоризьм настроен по умолчанию нарочно.
Заключение
Я помню что ChatGPT 3-й версии легко было подловить на вопросе “на каком языке Ленин переписывался с Марксом”. Сейчас почти на любую подобную попытку будет ответ что “нет документальных подтверждений о том что такая переписка была да и жили они в разное время”. Налицо что разработчики LLM не дремлют и вносят порой довольно узконаправленные улучшения.
Не знаю добавят ли они в какой-то момент встроенный компилятор для нескольких популярных ассемблеров, например – но по крайней мере этот коротенький текст послужит референсом чтобы следить за возможными модификациями.
Автор: RodionGork
