Project

General

Profile

LLVM based compiler

Added by m.vlasov_multiclet almost 8 years ago

Добрый день, всем неравнодушным к проектам отечественной микроэлектроники в целом и к мультиклеточным процессорам в частности.

Предлагаем Вам принять участие в тестировании альфа версии компилятора C для мультиклеточного процессора MCp042R100102 (Multiclet R1) на базе фреймворка LLVM версии 3.9.0.

Представленная версия компилятора НЕ является полноценным завершённым компилятором для языков программирования C/C++. Это всего лишь бета версия компилятора, бекенд которого поддерживает только программы с исходным кодом на языке C для мультиклеточного процессора MCp042R100102 (Multiclet R1) со множеством различных ограничений и недоработок, а также, естественно, различных ошибок, допущенных при разработке. Другими словами, слишком много от него ждать не стоит.

Список очевидных недоработок текущей версии компилятора:
  1. отсутствует полноценная поддержка 64-х разрядной целочисленной арифметики;
  2. отсутствует поддержка векторных инструкций, которые в ограниченном наборе поддерживаются процессором Multiclet R1;
  3. архитектурно-зависимые оптимизации на стороне бекенда находятся в зачаточном состоянии (реализованы лишь очевидные оптимизации);
  4. компилятор не учитывает всех возможных аппаратных ошибок процессора Multiclet R1 (вообще учёт и обход таких ошибок хочется сделать на стороне ассемблера, чтобы компилятор верхнего уровня был, по возможности, освобождён от решения данной задачи, а также не повторять один и тот же код в различных компиляторах верхнего уровня, если таковых имеется несколько (у нас есть компилятор C89 на базе lcc));
  5. отсутствует в каком-либо виде стандартная библиотека языка C, математическая библиотека и др.
  6. отсутствует возможность генерации позиционно независимого кода (-fPIC), весь генерируемый код является статическим;
  7. отсутствует генерация отладочной информации;
  8. реакция компилятора на использование в исходном коде программы атрибутов (attribute) и ассемблерных вставок не известна, так как тесты такого кода не проводились (возможно в некоторых случаях произойдёт аварийное завершение работы компилятора);
  9. ...
Текущие "достижения" представленной альфа версии компилятора:
  1. короткие программы на языке C, использованные для тестирования во время разработки;
  2. тест Coremark (http://www.eembc.org/coremark/download.php) с результатом 0.56 Coremark/MHz;
  3. A Lightweight TCP/IP stack (http://savannah.nongnu.org/projects/lwip/) версии 1.4.1;
  4. ...
Архив с альфа версией компилятора можно скачать:
  • для 32-х разрядной ОС Linux здесь
  • для 64-х разрядной ОС Linux здесь
  • для 32-х разрядной ОС Windows 7 здесь
В архиве содержатся следующие файлы:
  1. clang - дравер, компилятор (фронтенд с интегрированным бекендом);
  2. llc - бекенд;
  3. mc-as - ассемблер;
  4. mc-ld - редактор связей (linker);
  5. файлы начальной инициализации (crt0.o, init_mems.o);
  6. доступные на данный момент заголовочные файлы;
  7. доступные на данный момент реализации некоторых библиотечных функций (библиотека librt.a);
  8. README файл.
Несколько примеров, как всем этим пользоваться:
  • запуск только препроцессора
    clang -target multiclet -E src_file.c -I<header_files_directory> -o src_file.i
  • запуск препроцессора и фаз компиляции (фронтенд, бекенд)
    clang -target multiclet -S src_file.c -I<header_files_directory> -o src_file.s
  • запуск препроцессора, фаз компиляции (фронтенд, бекенд) и ассемблера (внешний исполняемый файл mc-as, директория расположения которого должна быть прописана в переменной среды PATH)
    clang -target multiclet -c src_file.c -I<header_files_directory> -o src_file.o
  • запуск препроцессора и фронтенда для получения промежуточного представления LLVM IR в текстовом виде
    clang -target multiclet -emit-llvm -S src_file.c -I<header_files_directory> -o src_file.ll
  • запуск препроцессора и фронтенда для получения промежуточного представления LLVM IR в виде двоичного биткода
    clang -target multiclet -emit-llvm -c src_file.c -I<header_files_directory> -o src_file.bc
  • запуск бекенда для получения ассемблерного файла, на входе файл с промежуточным представлением LLVM IR в текстовом виде
    llc -march=multiclet -filetype=asm src_file.ll -o src_file.s
  • запуск бекенда для получения ассемблерного файла, на входе файл с промежуточным представлением LLVM IR в виде двоичного биткода
    llc -march=multiclet -filetype=asm src_file.bc -o src_file.s

И в завершение несколько пожеланий. Если кто-нибудь из вас, уважаемые пользователи, столкнётся с какими-либо проблемами (а вы с ними обязательно столкнётесь) при использовании представленной альфа версии компилятора, не стесняйтесь задавать вопросы, описывая свою проблему как можно подробнее с примерами, по возможности, исходного кода компилируемой программы; предлагайте свои варианты дальнейшего развития компилятора (какую функциональность хотелось бы видеть как можно раньше, а с какой можно и подождать); высказывайте любую конструктивную критику ("здесь плохо, лучше было бы вот так", а не просто "здесь плохо, зачем вообще нужен такой компилятор?") получаемого ассемблерного (объектного) кода; также вопросы, связанные с ассемблером и редактором связей, пишите здесь же, так как, во-первых, они являются составляющими элементами системы сборки (toolchain'a), а, во-вторых, всё равно решать их тоже мне. В общем нужна обратная связь, одному тащить всё это просто не хватает времени.


Replies (30)

RE: LLVM based compiler - Added by VaalKIA about 6 years ago

Если архитектура позволяет, то никакая ОС не спасёт.

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

RE: LLVM based compiler - Added by Yaisis about 6 years ago

VaalKIA wrote:

Если архитектура позволяет, то никакая ОС не спасёт.

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

А я вспомнил про Эльбрус.
Там программа не может получить доступ в область памяти другой программы -- это аппаратная защита и её не обойти, если только сама программа не окажется дырявой и не даст свою память.
Так же Эльбрус контролирует типы данных, т.е. если вы отвели тип данных float, то Эльбрус не даст его использовать, например, как указатель -- это тоже аппаратная защита.

Все современные архитектуры - Тьюринг полные, это значит, что можно эмулировать любое устройство на любой архитектуре, вопрос только в эффективности.

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

Это утвреждение должно навести вас на мысль, что всё зависит исключительно от ПО.

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

RE: LLVM based compiler - Added by Yaisis about 6 years ago

VaalKIA wrote:

Если архитектура позволяет, то никакая ОС не спасёт.

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

А я вспомнил про Эльбрус.
Там программа не может получить доступ в область памяти другой программы -- это аппаратная защита и её не обойти, если только сама программа не окажется дырявой и не даст свою память.
Так же Эльбрус контролирует типы данных, т.е. если вы отвели тип данных float, то Эльбрус не даст его использовать, например, как указатель -- это тоже аппаратная защита.

Все современные архитектуры - Тьюринг полные, это значит, что можно эмулировать любое устройство на любой архитектуре, вопрос только в эффективности.

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

Это утвреждение должно навести вас на мысль, что всё зависит исключительно от ПО.

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

RE: LLVM based compiler - Added by VaalKIA about 6 years ago

В своей памяти пусть делает, что хочет, а в чужую нельзя -- это и есть защита.

Для процессора нет понятия другая программа, на нём исполняется единственная. Вы путаете понятия программа и приложение. От какой другой программы должна быть защита в среде DOS, какие уязвимости в DOS предоставил мелтдаун? А я подскажу - никаких.

Плюс достоинство аппаратного решения в том, что в Эльбрусе весь контроль производится параллельно вычислениям, а если его попытаться возложить на ОС, то это приведёт к лишнему коду, отъедающему ресурсы.

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

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

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

И что бы закончить уже нашу дискуссию вы должны себе уяснить, что не надо защиать код от самого себя, а процессор исполняет именно код. Когда же появились ОС позволяющие одновременно выполнять несколько приложений, причём на одноядерных процессорах! Вот тогда в полный рост встал вопрос того, что для этого надо полностью ЭМУЛИРОВАТЬ процессор и окружение для КАЖДОГО приложения. Если этого не делать, то всё будет плохо. Производительность такого решения на несколько ПОРЯДКОВ ниже чем прямое исполнение программы. И это не проблема процессора, это проблема ОС. Что сделали создатели ОС? Они просто забили на всё и дали прямой доступ и везде, где только можно отказались от эмуляции, но как оказалось, програмы пишут и со злым умыслом, так что пришлось повышать уровень эмуляции. Этот процесс происходит до сих пор. Спрашивается чья вина в том, что ОС контролирует доступ к памяти, но совершенно спокойно отдаёт "секретные" данные в кеше другому приложению? Да просто потому, что разработчики решили, что даже если там будет пароль, а он там бывает, то просто не поймут что это он, но внезапно, оказалось, что это не такой уж случайный процесс и с помощью Мельтдаун им можно управлять. А раз так, то это грубое нарушение изоляции (эмуляции кода) приложений. При этом, производители процессоров активно включились в "драку" и стали предоставлять аппаратные решения по эмуляции кода, это и защита памяти, и всякие супервизоры и супервизоры над супервизорами, и даже шифрование памяти на лету. Но надо понимать, что это всего лишь ускорители, а по факту дело обстоит таким образом: ОС никак не изолировало определённые вещи приложений, потому что это дорого, появлась такая возможность - получите больший уровень безопасности приложений. А иногда случаются откаты - вроде как взяли новую планку и все к этому привыкли и тут - Мельтдаун и оказыватеся поставляемые ускорители стали бесполезны, а сказать, что это норма в работе приложений уже нельзя. И таких провалов в ОС очень много, это системная проблема и не потому что процессоры плохие, а потому что целенаправленно был выбран такой подход - изолируем там, где это дёшево и забиваем болт в остальных местах, пусть пользователь сам контролирует свои приложения.

RE: LLVM based compiler - Added by VaalKIA about 6 years ago

Кстати говоря, по моему, производители процессоров уже включили механизмы для полной эмуляции (эти самые супервизоры), но производители ОС пока их не используют, а так уже возможно исполнять приложение когбуд-то оно одно на компьютере. И я просто не интересуюсь этой темой, но возможно эти фишки используются в серверах, для одновременного запуска нескольких ОС на одном компьютере, что бы из одного компа сделать 10, разбив ядра по клиентам.
И да, хочу заметить, что дыр, подобных Мельтдаун в ОС ещё навалом, например не секрет, что видеоускорители стали настолько навороченными, что уже заменяют ценральные процессоры в вычислених, поэтому с помощью видеокарт можно нарушать изоляцию приложений, запуская на них код, который будет иметь доступ , например, к памяти (самое страшное и простое нарушение изоляции), минуя центральный процесссор, а значит и механизмы ОС, по изоляции. Это известно уже давно, и никто ничего не делает, объяснить почему? Да потому что возможность играть в игры важнее вирусов, но когда-нибудь это выстрелит и все будут возмущаться - как же так, видекарты уязвимы - на кол нвидиа, но сейчас ещё не время и это хорошо, хотя уязвимость уже есть - уязвимость ОС.

(26-30/30)