Forums » Программное обеспечение »
LLVM based compiler
Added by m.vlasov_multiclet over 8 years ago
Добрый день, всем неравнодушным к проектам отечественной микроэлектроники в целом и к мультиклеточным процессорам в частности.
Предлагаем Вам принять участие в тестировании альфа версии компилятора C для мультиклеточного процессора MCp042R100102 (Multiclet R1) на базе фреймворка LLVM версии 3.9.0.
Представленная версия компилятора НЕ является полноценным завершённым компилятором для языков программирования C/C++. Это всего лишь бета версия компилятора, бекенд которого поддерживает только программы с исходным кодом на языке C для мультиклеточного процессора MCp042R100102 (Multiclet R1) со множеством различных ограничений и недоработок, а также, естественно, различных ошибок, допущенных при разработке. Другими словами, слишком много от него ждать не стоит.
Список очевидных недоработок текущей версии компилятора:- отсутствует полноценная поддержка 64-х разрядной целочисленной арифметики;
- отсутствует поддержка векторных инструкций, которые в ограниченном наборе поддерживаются процессором Multiclet R1;
- архитектурно-зависимые оптимизации на стороне бекенда находятся в зачаточном состоянии (реализованы лишь очевидные оптимизации);
- компилятор не учитывает всех возможных аппаратных ошибок процессора Multiclet R1 (вообще учёт и обход таких ошибок хочется сделать на стороне ассемблера, чтобы компилятор верхнего уровня был, по возможности, освобождён от решения данной задачи, а также не повторять один и тот же код в различных компиляторах верхнего уровня, если таковых имеется несколько (у нас есть компилятор C89 на базе lcc));
- отсутствует в каком-либо виде стандартная библиотека языка C, математическая библиотека и др.
- отсутствует возможность генерации позиционно независимого кода (-fPIC), весь генерируемый код является статическим;
- отсутствует генерация отладочной информации;
- реакция компилятора на использование в исходном коде программы атрибутов (attribute) и ассемблерных вставок не известна, так как тесты такого кода не проводились (возможно в некоторых случаях произойдёт аварийное завершение работы компилятора);
- ...
- короткие программы на языке C, использованные для тестирования во время разработки;
- тест Coremark (http://www.eembc.org/coremark/download.php) с результатом 0.56 Coremark/MHz;
- A Lightweight TCP/IP stack (http://savannah.nongnu.org/projects/lwip/) версии 1.4.1;
- ...
- для 32-х разрядной ОС Linux здесь
- для 64-х разрядной ОС Linux здесь
- для 32-х разрядной ОС Windows 7 здесь
- clang - дравер, компилятор (фронтенд с интегрированным бекендом);
- llc - бекенд;
- mc-as - ассемблер;
- mc-ld - редактор связей (linker);
- файлы начальной инициализации (crt0.o, init_mems.o);
- доступные на данный момент заголовочные файлы;
- доступные на данный момент реализации некоторых библиотечных функций (библиотека librt.a);
- 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 almost 7 years ago
Если архитектура позволяет, то никакая ОС не спасёт.
Все современные архитектуры - Тьюринг полные, это значит, что можно эмулировать любое устройство на любой архитектуре, вопрос только в эффективности. Это утвреждение должно навести вас на мысль, что всё зависит исключительно от ПО. А вот когда уже в комьютер встривают всякие терминалы удалённого доступа, работающие при выключенном компе.. но это несколько параллельная вселенная, мы вроде как о процессорах.
RE: LLVM based compiler - Added by Yaisis almost 7 years ago
VaalKIA wrote:
Если архитектура позволяет, то никакая ОС не спасёт.
Все современные архитектуры - Тьюринг полные, это значит, что можно эмулировать любое устройство на любой архитектуре, вопрос только в эффективности. Это утвреждение должно навести вас на мысль, что всё зависит исключительно от ПО. А вот когда уже в комьютер встривают всякие терминалы удалённого доступа, работающие при выключенном компе.. но это несколько параллельная вселенная, мы вроде как о процессорах.
А я вспомнил про Эльбрус.
Там программа не может получить доступ в область памяти другой программы -- это аппаратная защита и её не обойти, если только сама программа не окажется дырявой и не даст свою память.
Так же Эльбрус контролирует типы данных, т.е. если вы отвели тип данных float, то Эльбрус не даст его использовать, например, как указатель -- это тоже аппаратная защита.
Все современные архитектуры - Тьюринг полные, это значит, что можно эмулировать любое устройство на любой архитектуре, вопрос только в эффективности.
Опять же сам эмулятор, например, в Эльбрусе -- это программа, у которой есть своя память и в которой можно, например, эмулировать какой-нибудь другой процессор, но эта программа никак не сможет получить доступ к области памяти другой программы. В своей памяти пусть делает, что хочет, а в чужую нельзя -- это и есть защита.
Это утвреждение должно навести вас на мысль, что всё зависит исключительно от ПО.
Выше написал вам, как защита не мешает эмулировать любое устройство и как ПО не может обойти эту защиту.
Архитектура же не должна всё позволять программам. Должны быть определённые правила, которые программам нужно выполнять.
Она должна контролировать области памяти, как в Эльбрусе -- это повышает защиту многократно.
С помощью одного ПО нельзя добиться такой защиты.
Плюс достоинство аппаратного решения в том, что в Эльбрусе весь контроль производится параллельно вычислениям, а если его попытаться возложить на ОС, то это приведёт к лишнему коду, отъедающему ресурсы. И толку от этого будет мало, т.к. это будет легко взломать, ведь какие бы ограничения не вводила ОС, есть инструкции процессора, с помощью которых можно залезть в любую память и контролировать их может только сам процессор.
RE: LLVM based compiler - Added by Yaisis almost 7 years ago
VaalKIA wrote:
Если архитектура позволяет, то никакая ОС не спасёт.
Все современные архитектуры - Тьюринг полные, это значит, что можно эмулировать любое устройство на любой архитектуре, вопрос только в эффективности. Это утвреждение должно навести вас на мысль, что всё зависит исключительно от ПО. А вот когда уже в комьютер встривают всякие терминалы удалённого доступа, работающие при выключенном компе.. но это несколько параллельная вселенная, мы вроде как о процессорах.
А я вспомнил про Эльбрус.
Там программа не может получить доступ в область памяти другой программы -- это аппаратная защита и её не обойти, если только сама программа не окажется дырявой и не даст свою память.
Так же Эльбрус контролирует типы данных, т.е. если вы отвели тип данных float, то Эльбрус не даст его использовать, например, как указатель -- это тоже аппаратная защита.
Все современные архитектуры - Тьюринг полные, это значит, что можно эмулировать любое устройство на любой архитектуре, вопрос только в эффективности.
Опять же сам эмулятор, например, в Эльбрусе -- это программа, у которой есть своя память и в которой можно, например, эмулировать какой-нибудь другой процессор, но эта программа никак не сможет получить доступ к области памяти другой программы. В своей памяти пусть делает, что хочет, а в чужую нельзя -- это и есть защита.
Это утвреждение должно навести вас на мысль, что всё зависит исключительно от ПО.
Выше написал вам, как защита не мешает эмулировать любое устройство и как ПО не может обойти эту защиту.
Архитектура же не должна всё позволять программам. Должны быть определённые правила, которые программам нужно выполнять.
Она должна контролировать области памяти, как в Эльбрусе -- это повышает защиту многократно.
С помощью одного ПО нельзя добиться такой защиты.
Плюс достоинство аппаратного решения в том, что в Эльбрусе весь контроль производится параллельно вычислениям, а если его попытаться возложить на ОС, то это приведёт к лишнему коду, отъедающему ресурсы. И толку от этого будет мало, т.к. это будет легко взломать, ведь какие бы ограничения не вводила ОС, есть инструкции процессора, с помощью которых можно залезть в любую память и контролировать их может только сам процессор.
RE: LLVM based compiler - Added by VaalKIA almost 7 years ago
В своей памяти пусть делает, что хочет, а в чужую нельзя -- это и есть защита.
Для процессора нет понятия другая программа, на нём исполняется единственная. Вы путаете понятия программа и приложение. От какой другой программы должна быть защита в среде DOS, какие уязвимости в DOS предоставил мелтдаун? А я подскажу - никаких.
Плюс достоинство аппаратного решения в том, что в Эльбрусе весь контроль производится параллельно вычислениям, а если его попытаться возложить на ОС, то это приведёт к лишнему коду, отъедающему ресурсы.
Это аппаратные решения можно сравнить с графическими ускорителями только для исполнения приложений, никто не гарантирует вам, что они покроют все нужды и не ограничат работу, точно так же как в ускорителях запрещены многоугольники, в угоду аппартной простоте, тогда как в прогрмных реализациях графики это не нужно. Точно так же и с типами: типов бесконечное количество, то что контролирует Эльбрус и позволяет передавать помимо данных ещё флаг разрядностью несколько бит, не хорошо и не плохо, это просто фишка. И да, нет никаких проблем передачи типа в программах, именно так работает тип ваирант, но на софтовом уровне.
И толку от этого будет мало, т.к. это будет легко взломать, ведь какие бы ограничения не вводила ОС, есть инструкции процессора, с помощью которых можно залезть в любую память и контролировать их может только сам процессор.
Нет, эмулятор полностью контролирует исполнеие кода, вподь до того, что код вообще не исполняется, а вычисляется.
И что бы закончить уже нашу дискуссию вы должны себе уяснить, что не надо защиать код от самого себя, а процессор исполняет именно код. Когда же появились ОС позволяющие одновременно выполнять несколько приложений, причём на одноядерных процессорах! Вот тогда в полный рост встал вопрос того, что для этого надо полностью ЭМУЛИРОВАТЬ процессор и окружение для КАЖДОГО приложения. Если этого не делать, то всё будет плохо. Производительность такого решения на несколько ПОРЯДКОВ ниже чем прямое исполнение программы. И это не проблема процессора, это проблема ОС. Что сделали создатели ОС? Они просто забили на всё и дали прямой доступ и везде, где только можно отказались от эмуляции, но как оказалось, програмы пишут и со злым умыслом, так что пришлось повышать уровень эмуляции. Этот процесс происходит до сих пор. Спрашивается чья вина в том, что ОС контролирует доступ к памяти, но совершенно спокойно отдаёт "секретные" данные в кеше другому приложению? Да просто потому, что разработчики решили, что даже если там будет пароль, а он там бывает, то просто не поймут что это он, но внезапно, оказалось, что это не такой уж случайный процесс и с помощью Мельтдаун им можно управлять. А раз так, то это грубое нарушение изоляции (эмуляции кода) приложений. При этом, производители процессоров активно включились в "драку" и стали предоставлять аппаратные решения по эмуляции кода, это и защита памяти, и всякие супервизоры и супервизоры над супервизорами, и даже шифрование памяти на лету. Но надо понимать, что это всего лишь ускорители, а по факту дело обстоит таким образом: ОС никак не изолировало определённые вещи приложений, потому что это дорого, появлась такая возможность - получите больший уровень безопасности приложений. А иногда случаются откаты - вроде как взяли новую планку и все к этому привыкли и тут - Мельтдаун и оказыватеся поставляемые ускорители стали бесполезны, а сказать, что это норма в работе приложений уже нельзя. И таких провалов в ОС очень много, это системная проблема и не потому что процессоры плохие, а потому что целенаправленно был выбран такой подход - изолируем там, где это дёшево и забиваем болт в остальных местах, пусть пользователь сам контролирует свои приложения.
RE: LLVM based compiler - Added by VaalKIA almost 7 years ago
Кстати говоря, по моему, производители процессоров уже включили механизмы для полной эмуляции (эти самые супервизоры), но производители ОС пока их не используют, а так уже возможно исполнять приложение когбуд-то оно одно на компьютере. И я просто не интересуюсь этой темой, но возможно эти фишки используются в серверах, для одновременного запуска нескольких ОС на одном компьютере, что бы из одного компа сделать 10, разбив ядра по клиентам.
И да, хочу заметить, что дыр, подобных Мельтдаун в ОС ещё навалом, например не секрет, что видеоускорители стали настолько навороченными, что уже заменяют ценральные процессоры в вычислених, поэтому с помощью видеокарт можно нарушать изоляцию приложений, запуская на них код, который будет иметь доступ , например, к памяти (самое страшное и простое нарушение изоляции), минуя центральный процесссор, а значит и механизмы ОС, по изоляции. Это известно уже давно, и никто ничего не делает, объяснить почему? Да потому что возможность играть в игры важнее вирусов, но когда-нибудь это выстрелит и все будут возмущаться - как же так, видекарты уязвимы - на кол нвидиа, но сейчас ещё не время и это хорошо, хотя уязвимость уже есть - уязвимость ОС.
- « Previous
- 1
- 2
- Next »