Лига программистов C/C++

Автор: Денис Аветисян

Исследование потенциала больших языковых моделей для прямой компиляции кода без традиционных этапов обработки.

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

Несмотря на значительные успехи в различных областях, возможность использования больших языковых моделей (LLM) в качестве полноценных компиляторов оставалась малоизученной. Данная работа, 'Exploring the Feasibility of End-to-End Large Language Model as a Compiler', посвящена исследованию потенциала LLM для прямой трансляции исходного кода в машинный, с акцентом на разработку датасета CompilerEval и фреймворка LaaC. Эксперименты показали, что LLM демонстрируют базовые способности к компиляции, однако текущий процент успешной компиляции остается низким. Возможно ли, путем оптимизации запросов, масштабирования моделей и внедрения методов рассуждения, создать LLM, способные генерировать высококачественный ассемблерный код и изменить парадигму компиляции?

Эволюция Компиляции: От Надежности к Гибкости

Традиционная компиляция, несмотря на свою надежность, представляет собой сложный и ресурсоемкий процесс. Растущий спрос на кроссплатформенность и поддержку специализированного оборудования требует адаптивных решений. Технологии искусственного интеллекта, в частности, большие языковые модели (LLM), предлагают принципиально новый подход к компиляции, способный упростить и ускорить разработку. Прозрачность алгоритмов – ключ к безопасному и эффективному программному обеспечению.

Возможность сквозной компиляции с использованием LLM демонстрирует потенциал для упрощения процесса разработки.

LLM как Компилятор: Новый Парадигма

Предлагаемый подход основан на непосредственном преобразовании исходного кода в машинный язык с использованием больших языковых моделей (LLM), минуя традиционные этапы компиляции. Разработанная платформа LaaC (LLM as a Compiler) является развитием данной идеи, ключевым компонентом которой является база знаний, содержащая информацию об исходных языках и наборах инструкций целевых архитектур. Несмотря на перспективность, текущие показатели успешной компиляции остаются относительно невысокими.

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

CompilerEval: Строгий Анализ Возможностей LLM

Для систематической оценки возможностей больших языковых моделей (LLM) в генерации ассемблерного кода разработана платформа CompilerEval, использующая специализированный набор данных CompilerEval Dataset. В рамках исследования была проведена оценка коэффициента успешной компиляции (Compilation Success Rate) для LLM, включая GPT-4o, Gemini-2.0, Claude-3.5 и Llama-3, на различных аппаратных архитектурах. Результаты демонстрируют зависимость эффективности от архитектуры и используемой модели.

Применение методов оптимизации запросов (Prompt Engineering) позволило улучшить показатели успешной компиляции. Так, для Claude-3.5-Sonnet наблюдалось увеличение на 7,5%, для GPT-4o с применением Chain-of-Thought – на 5%, а масштабирование Llama с Llama-70B до Llama-405B дало прирост в 1,55%.

Кроссплатформенность и Перспективы Будущего

Оценка продемонстрировала потенциал LLM для генерации кода для различных архитектур (x86, ARM, RISC-V), обеспечивая кроссплатформенную совместимость и автоматизацию разработки. Генерируемый код показал более высокие показатели корректности для ARM и RISC-V по сравнению с x86, что может быть связано с более стандартизированной природой этих архитектур.

Дальнейшие исследования могут быть сосредоточены на оптимизации LLM и масштабировании для обработки сложных кодовых баз. Комбинация AI-управляемой компиляции с традиционными методами обещает будущее оптимизированной разработки. Каждая строка кода, созданная машиной, – это попытка расшифровать правила, лежащие в основе цифрового мира.

Исследование демонстрирует, что большие языковые модели могут выступать в роли компиляторов, генерируя ассемблерный код непосредственно из высокоуровневых инструкций. Однако, успешность компиляции остаётся переменной величиной, требующей дальнейшей оптимизации и проработки. Это напоминает о высказывании Грейс Хоппер: “Лучший способ предсказать будущее — это создать его.”. В контексте LaaC Framework и необходимости повышения точности и эффективности компиляции, данная фраза подчеркивает активную роль исследователей в формировании будущего компиляционных технологий. Вместо пассивного ожидания прогресса, необходимо создавать инструменты и методы, способные преодолеть текущие ограничения и обеспечить надежную кросс-платформенную поддержку.

Что дальше?

Представленная работа демонстрирует, что границы между языковыми моделями и компиляторами становятся всё более размытыми. Однако, воспринимать это как немедленную замену традиционным системам было бы наивно. Достигнутые результаты – скорее, намек на возможность, чем окончательное решение. Ключевым вызовом остаётся не только повышение процента успешной компиляции, но и обеспечение предсказуемости, эффективности генерируемого кода и, что немаловажно, его переносимости между различными платформами. Необходимо признать, что текущие модели, по сути, "угадывают" компиляцию, а не выполняют её на основе строгой логики.

Дальнейшие исследования должны быть направлены на разработку более надёжных методов оценки и верификации сгенерированного кода, а также на создание инструментов для "отладки" логики языковых моделей, используемых в качестве компиляторов. Интересным направлением представляется изучение возможности интеграции существующих компиляционных технологий с LLM, создавая гибридные системы, сочетающие в себе сильные стороны обоих подходов. Ведь хаос — не враг, а зеркало архитектуры, которое отражает скрытые связи.

В конечном счёте, успех этого направления зависит от способности выйти за рамки простого "перевода" кода и создать системы, способные к оптимизации и адаптации к специфическим требованиям целевой платформы. Это потребует не только улучшения алгоритмов обучения языковых моделей, но и глубокого понимания принципов работы компиляторов и архитектуры вычислительных систем.

Оригинал статьи: denisavetisyan.com/yazykovye-modeli-kak-kompilyatory-vozmozhno-li-eto

Связаться с автором: linkedin.com/in/avetisyan

Я почему-то уверен, что она у тебя уже есть. Либо в списке литературы для самообразования, либо где-то среди скачанных pdf, а может, даже в печатном виде. Возможно, ты даже начинал её читать, но… работа, таски, собеседования… деньги вроде и так платят… и ты так и не осилил Мейерса "Эффективный и современный С++".

А ведь именно эта книга — ключ, который поможет тебе пробить потолок уровня middle и начать движение к senior.

Да, можно скачать список из 400 популярных вопросов, выучить их и бодро ответить на вопрос: «Расскажи про std::unique_ptr». А потом тебе прилетает дополнительный вопрос: «А как изменится размер std::unique_ptr при использовании пользовательского удалителя?» Иии… Я не буду додумывать твой уровень знаний. Попробуй сам ответить на этот вопрос и поставь себе оценку🙂
И это только один из примеров тонких нюансов, которые описаны в этой книге и которые реально спрашивают на собеседованиях.

Ещё одна сильная сторона книги: почти каждая фича современного C++ иллюстрируется примерами её использования в реальном проде. А это большая редкость для технической литературы.

Хватит откладывать эту книгу на «потом». Поставь цель на этот год и, наконец-то, найди время, чтобы прочитать 300 страниц "Эффективного и современного С++".

Привет всем ребятам с пикабу! Сегодня столкнулся с проблемой, что мне нужно было сделать так, чтобы я вводил PID процесса, или хотя-бы имя самого процесса, вместо имени окна чтобы скрыть, или показать его в панели задач. Пробовал сам - не получилось. Спросил ChatGpt - нерабочая тарабарщина. Просьба помочь чем сможете, буду благодарен любому совету!

Вот сам код: #include <windows.h>
#include <iostream>
#include <string>

int main()
{
int choice;
std::string programName;
HWND hwnd;

std::cout << "Choose an option:\n";
std::cout << "(1) Hide Window\n";
std::cout << "(2) Show Window\n";

std::cin >> choice;
std::cin.ignore();

switch (choice) {
case 1:
std::cout << "Enter the Window Name to hide: ";
std::getline(std::cin, programName);
hwnd = FindWindowA(NULL, programName.c_str());
if (hwnd == NULL) {
std::cout << "Program not found." << std::endl;
return 1;
}
ShowWindow(hwnd, SW_HIDE);
std::cout << "Window '" << programName << "' was hidden." << std::endl;
break;
case 2:
std::cout << "Enter the Window Name to show: ";
std::getline(std::cin, programName);
hwnd = FindWindowA(NULL, programName.c_str());
if (hwnd == NULL) {
std::cout << "Program not found." << std::endl;
return 1;
}
ShowWindow(hwnd, SW_SHOW);
std::cout << "Window '" << programName << "' is now visible." << std::endl;
break;
default:
std::cout << "Invalid option selected." << std::endl;
return 1;
}
return 0;
}

Столкнулся сегодня с проблемой. Мне нужно сделать так, чтобы когда консоль была открыта, то у меня там отображался мой текст TriggerBot и AimAssist, а в памяти оно бы шифровалось. Пример: в консоли у меня есть "анимация" TriggerBot, но когда я сканирую память (к примеру с помощью Process Hacker или Cheat Engine), то в поиске строк в памяти вместо "TriggerBot", у меня бы там писалось к примеру hhajhfgdsghf==. Я сначала думал об VMP Protect, но решил, что он мне практически не поможет, поэтому решил обратиться к вам. Просьба помочь чем сможете, буду благодарен любому за помощь. Вот код:
#include <iostream>
#include <windows.h>

void fadeInText(const std::string& text) {
for (int i = 0; i <= 10; ++i) {
std::cout << "\r";
for (int j = 0; j < i; ++j) {
std::cout << text[j];
}
Sleep(50);
}
}

void fadeOutText(const std::string& text) {
for (int i = 10; i >= 0; --i) {
std::cout << "\r";
for (int j = 0; j < i; ++j) {
std::cout << text[j];
}
Sleep(50);
}
std::cout << "\r";
}

int main() {
std::string aimAssist = "AimAssist";
std::string triggerBot = "TriggerBot";

while (true) {
fadeInText(aimAssist);
Sleep(1000);
fadeOutText(aimAssist);

fadeInText(triggerBot);
Sleep(1000);
fadeOutText(triggerBot);
}

return 0;
}

Автор текста: dlinyj

Совсем недавно появилась следующая новость: На GitHub опубликован исходный код MS-DOS 4.00 под лицензией MIT. Раз появились исходные коды, стало сразу интересно: а можно ли собрать эту операционную систему?

Задача оказалась нетривиальной и совсем неочевидной. Оказывается, что исходные файлы DOS не так-то уж и легко переносятся в git, и уж как минимум, не как текстовые файлы в кодировке UTF-8. Но, к счастью, в отличие от утечек исходников MS-DOS 6.0, здесь имеется полный комплект файлов и инструментов, достаточный для корректной сборки и тестирования. Остались сущие нюансы, которые попили много крови.

Поэтому я, как и многие — начал свои эксперименты по сборке MS-DOS 4.0, с исправлением ошибок, а также возможностью исследования исходных кодов и тестирования их на реальном железе.

В статье же изложено краткое руководство по сборке и созданию загрузочной дискетки.

❯ Инструментарий

Собирать всё буду в Linux Mint (читай Ubuntu). Средой DOS для сборки выбрал dosbox, к сожалению, это не самый лучший вариант, потому что там идёт замедление частоты (чтобы старые программы корректно работали), поэтому сборка идёт достаточно долго. Лучше всего использовать любой удобный DOS, запущенный в виртуальной машине.

Для создания загрузочной дискеты и тестирования полученной сборки буду задействовать виртуальную машину qemu. А чтобы получить дискеты с готовым образом, я буду использовать установочную дискету MS-DOS 4.0 (найденную тут см. 4.00 OEM [Sampo]).

Прежде чем пойдём дальше — важное замечание:

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

❯ В чём сложности сборки?

Проблемы две:

1. Некорректная инициализация переменных среды (в самом bat-файле SETENV.BAT содержится ошибки или опечатки).

2. Проблемы с кодировкой при переносе кода с дискеток DOS в GIT с кодировкой UTF-8.

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

Значительно сложнее обстоят дела с тем, что в части кода, при переносе в UTF-8, побились некоторые символы. У меня была попытка сборки, которую я описывал у себя в ЖЖ, и, в конце концов, я получил вот это:

Это достаточно частая и болезненная проблема со старыми исходниками времён DOS. С аналогичной задачей я столкнулся и при попытке собрать программу RAM View. Об этом пути и исправлении проблемы, я подробно написал в статье Правка чужого кода.

Здесь же мы исключим ручной труд и автоматизируем исправление проблем с кодировками.

❯ Подготовительные операции перед сборкой

Итак, шаги по сборке ДОС. Клонируем оригинальный репозиторий:

git clone https://github.com/microsoft/MS-DOS.git

Исправляем проблемы с кодировками:

sed -i -re 's/\xEF\xBF\xBD|\xC4\xBF|\xC4\xB4/#/g' MS-DOS/v4.0/src/MAPPER/GETMSG.ASM
sed -i -re 's/\xEF\xBF\xBD|\xC4\xBF|\xC4\xB4/#/g' MS-DOS/v4.0/src/SELECT/SELECT2.ASM
sed -i -re 's/\xEF\xBF\xBD|\xC4\xBF|\xC4\xB4/#/g' MS-DOS/v4.0/src/SELECT/USA.INF

Переходим в рабочую папку:

cd MS-DOS/v4.0

Перекодируем все текстовые файлы в формат MS-DOS:

find -iname '*.bat' -o -iname '*.asm' -o -iname '*.skl' -o -iname 'zero.dat' -o -iname 'locscr' | xargs unix2dos -f
find -iname '*.BAT' -o -iname '*.ASM' -o -iname '*.SKL' -o -iname 'ZERO.DAT' -o -iname 'LOCSCR' | xargs unix2dos -f

и создаём там обновлённый бат-файл для переменных среды окружения, следующего содержания:

$ cat src/e.bat
@Echo off
echo setting up system to build the MS-DOS 4.01 SOURCE BAK...
set CL=
set LINK=
set MASM=
set COUNTRY=usa-ms
set BAKROOT=e:
rem BAKROOT points to the home drive/directory of the sources.
set LIB=%BAKROOT%\src\tools\bld\lib
set INIT=%BAKROOT%\src\tools
set INCLUDE=%BAKROOT%\src\tools\bld\inc
set PATH=%BAKROOT%\src\tools;%PATH%

В принципе этих операций достаточно для сборки, а то что ниже — это лично моё хулиганство, чтобы продемонстрировать, что DOS в действительности собрался, и нет подмены файлов. Я заменяю компанию Microsoft своим ником:

find -name "*.ASM" -type f -exec sed -i 's/Microsoft/Dlinyj/g' {} +
find -name "*.INC" -type f -exec sed -i 's/Microsoft/Dlinyj/g' {} +
find -name "*.H" -type f -exec sed -i 's/Microsoft/Dlinyj/g' {} +
find -name "*.MAC" -type f -exec sed -i 's/Microsoft/Dlinyj/g' {} +
find -name "*.MSG" -type f -exec sed -i 's/Microsoft/Dlinyj/g' {} +
find -name "*.C" -type f -exec sed -i 's/Microsoft/Dlinyj/g' {} +
find -name "*.CLB" -type f -exec sed -i 's/Microsoft/Dlinyj/g' {} +
find -name "*.SKL" -type f -exec sed -i 's/Microsoft/Dlinyj/g' {} +

Всё, теперь исходники подготовлены, для того чтобы их можно было корректно собрать.

❯ Сборка

Собирать буду в dosbox, как показала практика — это не самое лучшее решение, сборка занимает около часа, что, мягко скажем, раздражает.

Запускаю dosbox:

dosbox

Далее в нём монтирую текущую директорию как диск E.

mount e: ./

И переходим на диск e, запускаем в dosbox бат-файл, который инициализирует среду окружения, и начинаем сборку:

e:
cd SRC
e.bat

и запускаем сборку командой nmake:

Если вы делаете это в dosbox, то можно пойти погулять. Окончанием сборки будет выглядеть следующим образом:

После этого надо скопировать все собранные файлы в один каталог. Создаём каталог «4» в корне диска и копируем все бинарники специальным скриптом:

mkdir \4
CPY.BAT \4

Далее самое интересное:проверка того, что файлы запускаются. Для этого надо сделать так, чтобы dosbox прикидывался старым ДОСом. Выполняем следующую команду:

ver set 4.0

После переходим в каталог\4и можно выполнить в нёмcommand.com:

Хулиганство сработало, ДОС собрался и прикидывается, будто бы я его разработал. Дело стало за малым — протестировать это на реальном железе.

❯ Создание загрузочной дискетки

Дальше я думал просто примонтировать в dosbox пустой образ дискетки, и прямо из собранных файлов выполнить перенос системных файлов командой:

sys <path> a:

Но, факир был пьян, и фокус не удался. Поэтому решил MBR (Master Boot Record) позаимствовать с загрузочной дискетки DOS 4.0. К сожалению, MBR от MS-DOS 6.22 у меня не заработал.

Скачиваем установочные дискетки, попутно создаём пустую дискетку командой:

truncate --size 1474560 fdd.img

Загружаемся с установочной дискетки и ставим наш пустой образ 1,44 МБ дискетки в дисковод B, с помощью qemu:

qemu-system-i386 -fda Disk01.img -fdb fdd.img

Отменяем установку и форматируем дискету с переносом системных файлов:

По окончании можно закрывать окно qemu. Возвращаемся к окну с dosbox и монтируем полученный образ дискетки, с помощью следующей команды:

imgmount a: <path to fdd.img> -t floppy

И потом просто вручную переносим файлы COMMAND.COM, IO.SYS и MSDOS.SYS на дискету:

Всё, образ готов. Можно его протестировать в виртуальной машине, или даже записать на настоящую дискету и загрузиться!

Для запуска в qemu следует использовать следующую команду:

qemu-system-i386 -fda fdd.img

Записать на дискетку можно командой dd, я использую USB-FDD дисковод.

sudo dd if=fdd.img of=/dev/sdk status=progress

И, да! Эта система успешно работает на реальном железе. В данном случае проверка идёт на 386 компьютере.

❯ Выводы

Не буду лукавить, сборка MS-DOS 4.0 оказалась не столь простой. Пришлось посмотреть некоторые видео, пошерстить различные репозитории. Но всё же это прекрасный опыт, который позволяет заглянуть внутрь исторических исходников и покопаться в них.

Давняя утечка MS-DOS 6.0 была неполной, и собрать его не представлялось возможным. А теперь у исследователей есть готовый инструментарий, для того чтобы попрактиковаться в разработки каких-то своих модулей старой операционной системы.

Конечно же, я по-настоящему жду, когда же обнародуют исходники MS-DOS 6.22, так как ещё надеюсь увидеть их на своём веку.

Удачи вам в ваших экспериментах!

❯ Полезные ссылки:

1. Исходные коды MS-DOS от Microsoft

2. Пример сборки MS-DOS 4.0 во FreeDOS (видео)

3. Compiling MS-DOS 4.0 from DOS 4.0, on a PS/2!

• Написано специально для Timeweb Cloud и читателей Пикабу. Подписывайтесь на наш блог, чтобы не пропустить новые интересные статьи.

• Облачные сервисы Timeweb Cloud — это реферальная ссылка, которая может помочь поддержать наши проекты.