Примеры программ: Обновился ассемблер, а также линковщик
Рекомендуется обновить линковщик, ассемблер, модель и отладчик.
Added by krufter_multiclet about 11 years ago
Рекомендуется обновить линковщик, ассемблер, модель и отладчик.
Added by krufter_multiclet about 11 years ago
Новая модель с расширенным функционалом по процессору P1 доступна для скачивания в составе SDK и по отдельности. Стоит заметить, что в новой модели и новом отладчике увеличился функционал, а также появилась возможность работы через TCP клиент с периферией по uart. TCP клиент можно скачать как отдельно, так и в составе SDK. Информация по использованию модели и отладчика приведена в документации по программному обеспечению. Более подробная информация будет доступна в ближайшее время в формате wiki страниц.
Added by krufter_multiclet over 11 years ago
Отладчик и краткое руководство по работе с ним доступны для скачивания.
Для ОС Linux: http://multiclet.com/community/attachments/download/62/(linux)model_debug.7z
Для ОС Windows: http://multiclet.com/community/attachments/download/61/(win)model_debug.7z
Краткое руководство: Обзор работы с отладчиком
Added by krufter_multiclet over 11 years ago
Обновлённую версию SDK можно загрузить в разделе Техническая документация и ПО или загрузить модули отдельно в меню Файлы.
Added by krufter_multiclet over 11 years ago
Постепенно будет появляться информация по работе с различными интерфейсами мультиклеточного процессора. Также в формате Wiki будут доступны простые примеры по работе с интерфейсами процессора.
Added by krufter_multiclet over 11 years ago
Содержание Wiki страницы и примеры программ можно обсудить на форуме http://multiclet.com/community/boards/4/topics/137
Added by krufter_multiclet over 11 years ago
Текущие примеры доступны в хранилище, появление их модифицированных версий, а также добавление новых примеров программ для платы LDM запланировано на 4.04.13
Added by krufter_multiclet almost 12 years ago
Самые актуальные версии примеров программ будут доступны в хранилище. Примеры скоро будут доступны для скачивания.
Added by m.bakhterev almost 12 years ago
Существуют два разных базовых подхода к построению компиляторов, изложенные в двух основополагающих книгах: "Compilers: Principles, Techniques, and Tools" (книга Дракона) и "Design Concepts in Programming Languages" (DCPL).
Книга Дракона предлагает разработчикам технику синтаксически-управляемой трансляции. Практической вершиной которой является техника перевода исходного текста программы на каком-нибудь языке в промежуточное представление этой программы при помощи аннотированной грамматики. Метод хорошо проработан и является на сегодняшний день основным, используемым на практике. Однако, у него есть недостатки:Самыми неприятными пунктами для небольшой команды разработчиков являются 2 и 3. 2 подразумевает действительно очень сложный разбор вариантов, и проделывать его каждый раз для каждого языка заново -- черезмерно трудозатратно. 3 указывает на то, что труда понадобится ещё больше.
DCPL описывает более фундаментальный подход к семантике языков программирования, и к их трансляции. Подходы эти очень сильно завязаны на lambda-абстракции в вычислениях и на концепцию доменов, особенно на суммы доменов (это когда мы говорим, что вот Value = Int + Char + Float + Double + Complex + Structure 1 + Structure 2 + и т.д.; что означает: Value может быть одним из: ...). При помощи lamda-абстракций, описывающих определённые функции, каждому узлу выражение программы на исходном языке, представленное в синтаксической алгебре S-выражения для этого языка (а любой язык можно перевести в такое представление), отображается в целевой язык.
Это всё замечательно, формально, корректно, открывающе различные чакры true-программиста. Есть и чисто технические достоинства подхода:Оба этих недостатка обусловленны одним и тем же. Даже если рассмотреть простейшее выражение на Си "a + b
" возникает множество контекстов его оценки. И то, как следует транслировать a
зависит от того, чем является b
. Комбинаций при этом множество: char + char
, char + int
, char + float
, char + double
, char + _Complex
, char + pointer
и так далее, int + char
, int + int
, int + float
, ...
Сопоставление по образцу (pattern-matching) внутри lambda-абстракции должно быть жёстко запрограммированным, по определению этой конструкции. Его можно сделать иерархическим, если, например, разбить домен всех возможных значений для подвыражений Value так:
Value = (Arithmetic = Char + Int + Float + Double + _Complex + ...) + (Struct = struct tag1 + struct tag2 + ...) + ...
и рассматривать сначала выражения по вариантов для крупных доменов, но всё-равно операторы сопоставления получаются внушительными, и пользователь языка не может их изменять, без вмешательства в код транслятора.
Указанные проблемы исчезли бы (взамен, вероятно, мы можем получить много новых, пока не известных), если бы у нас было средство выражать процедуру сопоставления по образцу динамически, в зависимости от текущего контекста, это бы сэкономило нам силы на программирование разбора вариантов и, возможно, доло бы средство расширения семантики языка программирования с уровня пользователя для лингвистических экспериментов над архитектурой MCp (а там есть с чем экспериментировать).
Это мы и пытаемся сделать в технологии LiME.
Подходящим для этой цели вычислительным формализмом могут быть потоковые логические вычисления (мы же должны выдерживать стиль Мультиклета). Вероятно, таких в природе ещё не было, поэтому надо раскрыть суть явления. Логические вычисления - это, как известно, вычисления, позволяющие вывести некоторое выражение, ограниченное некоторыми правилами вывода. Обычно, набор правил задаётся в виде фиксированной программы (Prolog) или, допустим, графа целей (планирование). Однако, мы можем добавить в процесс вывода немного динамики, когда правила возникают по определённым событиям. Здесь можно выбрать примерно тот же подход, что и в системе RiDE, когда правила продолжения потока вывода (вычисления в случае RiDE) могут возникать по мере активации уже существующих правил или по внешним событиям.
Внешними событиями для LiME являются линейно-упорядоченная последовательность синтаксических инструкций, описывающих структуру S-выражения программы. Эта последовательность -- результат разбора по грамматике исходного языка вполне стандартным методом (для Си99 мы используем bison). Каждое такое событие вместе с типом выражения, находящимся на вершине стека разбора, определяют набор правил, который нужно добавить в текущий контекст вывода промежуточного представления.
Возможно, этот метод является переформулировкой метода, излагаемого в DCPL (которую, впрочем, можно считать более формально построенным вариантом книги Дракона, в конце концов, все преобразования данных сводятся к машине Тьюринга). Но можно ожидать, что эта переформулировка позволит реализовывать в языках некоторые интересные для практики конструкции.
Предлагаем Вам присоединиться к обсуждению достоинств и недостатков нашей технологии.
Форум: http://multiclet.com/community/boards/4/topics/53
Спецификация (в состоянии дописывания): http://multiclet.com/community/projects/mcc-lime/repository (см. source:txt/spec.txt)
Also available in: Atom