Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 20
Так жоско мою плату еще никто не использовал :)
Спасибо, очень интересно. Не буду говорить за всех, но многие ждали когда же на Мультклете появится маленькая операционная система.
Несколько сопутствующих вопросов:
Сколько времени потратили на портирование? Какие планы на будущее — будете ли развивать проект дальше? Как разработчики Мултиклета отнеслись к новости? Наверняка узнали об этом первыми.
Интересно, BarsMonster сейчас не сожалеет, что свой чип вытравил кислотой :)
Несколько сопутствующих вопросов:
Сколько времени потратили на портирование? Какие планы на будущее — будете ли развивать проект дальше? Как разработчики Мултиклета отнеслись к новости? Наверняка узнали об этом первыми.
Интересно, BarsMonster сейчас не сожалеет, что свой чип вытравил кислотой :)
Микросхемы мне не жалко, их завод еще наделает :-)
На портирование ушло около недели, сильно помог отладчик. Параллельно была найдена ошибка в компиляторе LCC (Ошибка инициализации статических локальных и глобальных указателей). Да, проект планируется развивать далее. Хочется портировать более продвинутый эмулятор терминала и текстовый редактор, ещё есть плата с GSM модулем M20 от QUECTEL, которую тоже хочется подключить. Разработчики Мултиклета отнеслись к новости хорошо, узнали первыми, т. к. я на них работаю, но проект по портированию был начат и закончен как любительский.
а с учётом низкого энергопотребления и аппаратного распараллеливания ещё и гораздо эффективнее.Так вот и показали бы данные по сравнению энергопотребления на данной конкретной задаче для Мультиклета и той же atmega — всем было бы интересно. Потребление Мультиклета в покое больше атмеги при полной нагрузке на порядки — естественно за счет бОльшей мощности и отсутствия продвинутых оптимизаций энергопотребления, но тем не менее на конкретной этой задаче никакого низкого энергопотребления не получится.
LCC по прежнему компилирует без оптимизаций? О какой эффективности тогда можно говорить?
Сравнительные тесты планирую провести и оформить в ближайшее время.
Да, к сожалению LCC по прежнему не оптимизирует, но имеется кодогенератор с оптимальной расстановкой инструкций и удалением лишних инструкций чтения, что немного ускоряет код. Надеюсь не ошибся в заключении.
Да, к сожалению LCC по прежнему не оптимизирует, но имеется кодогенератор с оптимальной расстановкой инструкций и удалением лишних инструкций чтения, что немного ускоряет код. Надеюсь не ошибся в заключении.
Прошу прощения, если этот момент освещался ранее, но на базе чего реализован компилятор LCC? LLVM или custom target GCC?
Всё проще ru.wikipedia.org/wiki/LCC, к нему была написана целевая машина Multiclet.
Понятно, спасибо. А почему был выбран именно он? Простота реализации или не хотелось связываться с «монстрами»?
Просто, написав бакенд для LLVM, вы бы бесплатно получили бы огромное количество отлаженных оптимизаций и нормальный API для работы. Плюс ко всему, SSA нотация, как мне кажется, очень даже подходит для вашей специфики.
Просто, написав бакенд для LLVM, вы бы бесплатно получили бы огромное количество отлаженных оптимизаций и нормальный API для работы. Плюс ко всему, SSA нотация, как мне кажется, очень даже подходит для вашей специфики.
LCC был выбран, потому что в кодогенератор он передаёт кусочки графа программы, что идеально подходит для архитектуры Multiclet. При этом, в каждом линейном блоке графа нет ссылок на узлы из других блоков. Это соответствует концепции параграфов.
«Монстры» же ориентированы на генерацию кода для чисто регистровых машин, к которым наши процессоры не относятся в полной мере: внутри параграфов у нас стоит потоковое (dataflow) описание вычисления. Поэтому мы не можем автоматически использовать оптимизации, которые есть в LLVM и GCC. При помощи абстракций, используемых в них для описания архитектуры целевой машины, такие потоковые машины не выражаются (по крайней мере, штатными API). Например, LLVM при оптимизации спокойно выносит общие выражения в линейные блоки за циклы, а в линейных блоках циклов ставит на этот результат ссылку, подразумевая, что она соответствует абстрактному регистру, который не меняется. Для нас разрешение такой ситуации — совсем не тривиальная задача.
Поэтому нам приходится изобретать свой компилирующий велосипед. Надеемся, что в нём будет достаточно интересных фишек, чтобы привлечь к оптимизациям и разработке нормальных API сообщество.
«Монстры» же ориентированы на генерацию кода для чисто регистровых машин, к которым наши процессоры не относятся в полной мере: внутри параграфов у нас стоит потоковое (dataflow) описание вычисления. Поэтому мы не можем автоматически использовать оптимизации, которые есть в LLVM и GCC. При помощи абстракций, используемых в них для описания архитектуры целевой машины, такие потоковые машины не выражаются (по крайней мере, штатными API). Например, LLVM при оптимизации спокойно выносит общие выражения в линейные блоки за циклы, а в линейных блоках циклов ставит на этот результат ссылку, подразумевая, что она соответствует абстрактному регистру, который не меняется. Для нас разрешение такой ситуации — совсем не тривиальная задача.
Поэтому нам приходится изобретать свой компилирующий велосипед. Надеемся, что в нём будет достаточно интересных фишек, чтобы привлечь к оптимизациям и разработке нормальных API сообщество.
Ну подождите. IR код LLVM вообще не оперирует понятиями регистров или памяти. Единственная операция аллокации — alloca подарзумевает, что память надо выделить «где-то» (обычно на стеке). Да и то, применяется она только в тех случаях, когда действительно необходимо описать формальную работу с переменными. Операции с памятью тоже жестко формализованы в load/store и вспомогательную GEP (get element pointer).
SSA в чистом виде описывает только отношения неизменяемых сущностей, которые могут быть обработаны бакендом по своему усмотрению.
Если вынесение инвариантов за пределы циклов, алиас анализ и другие виды оптимизаций вас не устраивают — ради бога, просто не используйте их и все. Каждая оптимизация — это отдельный проход преобразования CFG, который может быть отключен или заменен на собственный.
Информация о графе есть на всех уровнях, так что тут я тоже не вижу особой проблемы.
P.S.: Не подумайте что я «наезжаю», мне действительно интересно, почему вы считаете, что LLVM тут не подходит, ведь практика показывает одинаково успешную реализацию компиляторов как императивных, так и функциональных языков, которые гораздо ближе к концепции dataflow.
SSA в чистом виде описывает только отношения неизменяемых сущностей, которые могут быть обработаны бакендом по своему усмотрению.
Если вынесение инвариантов за пределы циклов, алиас анализ и другие виды оптимизаций вас не устраивают — ради бога, просто не используйте их и все. Каждая оптимизация — это отдельный проход преобразования CFG, который может быть отключен или заменен на собственный.
Информация о графе есть на всех уровнях, так что тут я тоже не вижу особой проблемы.
P.S.: Не подумайте что я «наезжаю», мне действительно интересно, почему вы считаете, что LLVM тут не подходит, ведь практика показывает одинаково успешную реализацию компиляторов как императивных, так и функциональных языков, которые гораздо ближе к концепции dataflow.
Ну подождите. IR код LLVM вообще не оперирует понятиями регистров или памяти. Единственная операция аллокации — alloca подарзумевает, что память надо выделить «где-то» (обычно на стеке). Да и то, применяется она только в тех случаях, когда действительно необходимо описать формальную работу с переменными. Операции с памятью тоже жестко формализованы в load/store и вспомогательную GEP (get element pointer).
SSA в чистом виде описывает только отношения неизменяемых сущностей, которые могут быть обработаны бакендом по своему усмотрению.
Под регистрами понимаются переменные, которые обозначаются %X. «Регистровость» их поведения проявляется в том, что если в такую переменную присвоено значение, то потом на него можно ссылаться по этому имени на протяжении всего кода процедуры (за исключением привязок в phi-узлах, конечно). Изнутри, в структурах данных LLVM, ссылки расставляются по тем же принципам.
В нашем процессоре подобные ссылки не переживают архитектурные линейные блоки — параграфы. И нам пришлось бы делать нетривиальный анализ того, что именно LLVM имеет в виду под каждой ссылкой в каждой конкретной ситуации. И нам бы пришлось, так или иначе, переводить внутреннее представление LLVM в какое-то своё внутреннее представление, а потом уже с ним работать. Но если мы переводим в своё внутреннее представление, то выгоднее делать это из исходного текста программы, чтобы сохранить больше деталей для последующих оптимизаций.
Если вынесение инвариантов за пределы циклов, алиас анализ и другие виды оптимизаций вас не устраивают — ради бога, просто не используйте их и все. Каждая оптимизация — это отдельный проход преобразования CFG, который может быть отключен или заменен на собственный.
Собственно, один из frontend-ов к новой системе компиляции у нас именно такой. Мы берём не-оптимизированный биткод и получаем из него удобное для нас представление программы, из которого мы генерируем текст на ассемблере. Но таким образом полученный код всё-равно плохо учитывает особенности архитектуры, для которой лучше всего получать не SSA, а именно замкнутые графы линейных участков. Эти кусочки можно в разной форме представлять, но лучше без концепции присваивания чего-то в регистр, доступный потом из любого места процедуры (что, всё-таки, подразумевает SSA).
В нашем внутреннем представлении есть разделение на просто графы (именно, как взаимосвязи значений), и на символы (переменные), через которые информация передаётся между графами. И это ещё увязано с самим процессом компиляции, которые построен как процесс вывода графа по заранее задаваемым формам (подробности будут на Хабре, как только отладим систему до alpha-версии).
SSA в чистом виде описывает только отношения неизменяемых сущностей, которые могут быть обработаны бакендом по своему усмотрению.
Под регистрами понимаются переменные, которые обозначаются %X. «Регистровость» их поведения проявляется в том, что если в такую переменную присвоено значение, то потом на него можно ссылаться по этому имени на протяжении всего кода процедуры (за исключением привязок в phi-узлах, конечно). Изнутри, в структурах данных LLVM, ссылки расставляются по тем же принципам.
В нашем процессоре подобные ссылки не переживают архитектурные линейные блоки — параграфы. И нам пришлось бы делать нетривиальный анализ того, что именно LLVM имеет в виду под каждой ссылкой в каждой конкретной ситуации. И нам бы пришлось, так или иначе, переводить внутреннее представление LLVM в какое-то своё внутреннее представление, а потом уже с ним работать. Но если мы переводим в своё внутреннее представление, то выгоднее делать это из исходного текста программы, чтобы сохранить больше деталей для последующих оптимизаций.
Если вынесение инвариантов за пределы циклов, алиас анализ и другие виды оптимизаций вас не устраивают — ради бога, просто не используйте их и все. Каждая оптимизация — это отдельный проход преобразования CFG, который может быть отключен или заменен на собственный.
Собственно, один из frontend-ов к новой системе компиляции у нас именно такой. Мы берём не-оптимизированный биткод и получаем из него удобное для нас представление программы, из которого мы генерируем текст на ассемблере. Но таким образом полученный код всё-равно плохо учитывает особенности архитектуры, для которой лучше всего получать не SSA, а именно замкнутые графы линейных участков. Эти кусочки можно в разной форме представлять, но лучше без концепции присваивания чего-то в регистр, доступный потом из любого места процедуры (что, всё-таки, подразумевает SSA).
В нашем внутреннем представлении есть разделение на просто графы (именно, как взаимосвязи значений), и на символы (переменные), через которые информация передаётся между графами. И это ещё увязано с самим процессом компиляции, которые построен как процесс вывода графа по заранее задаваемым формам (подробности будут на Хабре, как только отладим систему до alpha-версии).
Теперь кажется начинаю понимать. То есть, для вас критична не столько изменяемость и алиасинг, сколько локальность полученного значения в пределах параграфа (либо наличие информации об источнике)?
Спасибо за развернутый ответ.
Спасибо за развернутый ответ.
Теперь кажется начинаю понимать. То есть, для вас критична не столько
изменяемость и алиасинг, сколько локальность полученного значения в пределах
параграфа (либо наличие информации об источнике)?
Да, примерно так. Нам важно знать о локализации значений. С одной стороны — это
дополнительные сложности. С другой, может быть, появятся новые возможности при
трансформации программ.
Aliasing нам тоже важен, но уже на стадии оптимизации для принятия решений о том,
какие параграфы можно комбинировать, что можно читать из памяти однократно и т.д.
Подойдут стандартные методы анализа, только с учётом особенностей работы с
параграфами.
Спасибо за развернутый ответ.
Да не за что. Вам спасибо за интерес!
изменяемость и алиасинг, сколько локальность полученного значения в пределах
параграфа (либо наличие информации об источнике)?
Да, примерно так. Нам важно знать о локализации значений. С одной стороны — это
дополнительные сложности. С другой, может быть, появятся новые возможности при
трансформации программ.
Aliasing нам тоже важен, но уже на стадии оптимизации для принятия решений о том,
какие параграфы можно комбинировать, что можно читать из памяти однократно и т.д.
Подойдут стандартные методы анализа, только с учётом особенностей работы с
параграфами.
Спасибо за развернутый ответ.
Да не за что. Вам спасибо за интерес!
При этом, в каждом линейном блоке графа нет ссылок на узлы из других блоков. Это соответствует концепции параграфов.Что вы понимаете под ссылками? Операции перехода или обращение к «внешним данным»? В описании IR кода LLVM используется классическая уже концепция Basic Block-ов, которые точно так же, имеют строгие правила организации. Basic Block не может содержать внутри себя инструкцию-терминатор, только в хвосте. Тело блока представляет собой линейную последовательность инструкций, которые могут обрабатываться одним куском.
Тело блока представляет собой линейную последовательность инструкций, которые могут обрабатываться одним куском.
Они могут, если все необходимые для них данные сохранены в какой-то памяти (регистрах). То есть, они не замкнуты в общем случае по потоку данных. Под ссылками я понимаю как раз ссылки на результаты других вычислений. И эти ссылки могут вести в другие линейные участки.
Они могут, если все необходимые для них данные сохранены в какой-то памяти (регистрах). То есть, они не замкнуты в общем случае по потоку данных. Под ссылками я понимаю как раз ссылки на результаты других вычислений. И эти ссылки могут вести в другие линейные участки.
Процессор Р1 это первая реализация мультиклеточной архитектуры и в ней действительно не сделано оптимизаций по энергопотреблению, поэтому и выходит, что в покое потребление 380 мА, а при полной нагрузке 500 мА. В процессор Р1 закладывалось продемонстрировать возможности и особенности новой архитектуры. В случае когда нужно считать большие объёмы данных, ну хотя как большие — десятки итераций, для мультиклеточного процессора можно не напрягаясь умственно и физически командами CTRL+C, CTRL+V и небольшой правкой меток составить параграф подлиннее и получить параллельные вычисления, которые в некоторых случаях позволяют сделать вычисления быстрее чем Интел, который у вас дома(разумеется сравнение в тактах).
multiclet.com/community/boards/4/topics/527?page=2
Опять же, вернувшись к теме энергопотребления, могу сказать, что второе исполнение мультиклеточной архитектуры в лице процессора Р2 по предварительным расчётам будет иметь потребление раз в 5 ниже, ждём пока испекут.
multiclet.com/community/boards/4/topics/527?page=2
Опять же, вернувшись к теме энергопотребления, могу сказать, что второе исполнение мультиклеточной архитектуры в лице процессора Р2 по предварительным расчётам будет иметь потребление раз в 5 ниже, ждём пока испекут.
Правильно ли я понимаю, что основная цель создания процессора мультиклет именно научная?
Как я думаю, для научного проекта в принципе не очень важна цена, но важно принципиально показать новые и будущие возможности.
Или процессор мультиклет уже можно считать коммерчески успешным по соотношению производительность / цена и он может в некоторых сегментах конкурировать с микроконтроллерами или DSP других производителей?
Спрашиваю, потому, что сам все время думаю и работаю над реализацией своей «альтернативной» архитектуры процессора в ПЛИС.
Как я думаю, для научного проекта в принципе не очень важна цена, но важно принципиально показать новые и будущие возможности.
Или процессор мультиклет уже можно считать коммерчески успешным по соотношению производительность / цена и он может в некоторых сегментах конкурировать с микроконтроллерами или DSP других производителей?
Спрашиваю, потому, что сам все время думаю и работаю над реализацией своей «альтернативной» архитектуры процессора в ПЛИС.
Основная цель — коммерческая — процессор для массового применения, но как что-то уникальное и новое в кремнии, разработка процессора имеет научный подтекст, но кто даст средства только на научную деятельность. В дальнейшем планируется выпустить радиационностойкий процессор для космического применения, который также может быть полезен и в атомной промышленности. Затем будет выпуск и низкопотребляющего процессора, конкурента MSP430 с лучшими показателями по энергопотреблению, в том числе за счёт реконфигурации. Первый процессор с реконфигурацией R1 выйдет вместе с Р2, обе процессорные платы будут подходить к универсальной отладке, хотя для обычных пользователей процессорная плата с R1 может быть доступна чуть позже, предположительно в апреле. Мультиклеточные процессоры можно считать конкурентноспособными в соотношении производительность/цена. Процессор Р1 стоит около 500 рублей, если не ошибаюсь, Р2 тоже не будет намного дороже.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Портирование FreeRTOS на процессор от «Мультиклет»