Здравствуйте, Petrovich_, Вы писали:
P_>А чем вам С не угодил?
Вопрос не в том, на чем писать уже можно. Есть идея создать новый язык, набрав понемногу из других. Очень нравится дизайн Nemerle.
Здравствуйте, Алексей П, Вы писали:
АП>Здравствуйте, Petrovich_, Вы писали:
P_>>А чем вам С не угодил? АП>Вопрос не в том, на чем писать уже можно. Есть идея создать новый язык, набрав понемногу из других. Очень нравится дизайн Nemerle.
Если нравится именно метапрограммирование, то лучший выбор Forth. При этом требования к ресурсам близкие к нулю.
Здравствуйте, Алексей П, Вы писали:
АП>Как вы считаете, каким должен быть сабж? АП>Си не предлагать
А чем вам С не угодил?
Могу еще предложить асемблер, у контроллеров он зачастую достаточно прост, плюс у специализированных контроллеров может быть архитектура или просто какието фичи которые довольно сложно будет переложить на какой либо универсальный язык программирования. Вобщем особых альтернатив связке С + асм я не вижу.
Здравствуйте, Алексей П, Вы писали:
АП>Здравствуйте, Petrovich_, Вы писали:
P_>>А чем вам С не угодил? АП>Вопрос не в том, на чем писать уже можно. Есть идея создать новый язык, набрав понемногу из других. Очень нравится дизайн Nemerle.
Когда программируешь под микроконтроллер должен нравится не дизайн какого либо языка, а архитектура этого МК. В микроконтроллер идеи для которых требуются навороченные ЯП не влезут просто физически, память закончится Плюс если есть какойто специфический микроконтроллер задача написания компилятора какого либо языка под него, да еще такого который бы оптимально использовал специфику данного контроллера будет более трудоемкой чем задача написания всего софта который в этом контроллере будет крутиться на ассемблере.
Здравствуйте, Алексей П, Вы писали:
A>>Forth смотрел? Именно для микроконтроллеров — имеет смысл в некоторых A>>приложениях (переносимость в т.ч.). АП>Посмотрел, раз уж все советуют. На первый взгляд — ужас и еще более ассемблер чем Си. АП>Программу должно быть легко не только писать, но и читать! Это я к декларативному стилю веду.
а на второй? там интерпретатор под твоим контролем.
какой захочешь синтаксис, такой и будет.
Здравствуйте, Алексей П, Вы писали:
АП>Здравствуйте, azzx, Вы писали:
A>>Forth смотрел? Именно для микроконтроллеров — имеет смысл в некоторых A>>приложениях (переносимость в т.ч.). АП>Посмотрел, раз уж все советуют. На первый взгляд — ужас и еще более ассемблер чем Си.
Базовый форт да очень даже ассемблер Только есть существенное отличие от си, язык легко расширяем до уровня декларативных DSL.
АП>Программу должно быть легко не только писать, но и читать! Это я к декларативному стилю веду.
Куда уж декларативней (не в смысле функционального программирования, а в смысле построения DSL). Метапрограммрование там на очень высоком уровне просто как и в лиспе "нестандартный" синтаксис и своя философия. Чтобы понять годится ли для тебя эта философия или нет советую прочитать Leo Brodie "Thinking FORTH" (A Language and Philosophy for Solving Problems).(в переводе "СПОСОБ МЫШЛЕНИЯ — ФОРТ")
Здравствуйте, Алексей П, Вы писали:
P_>>А чем вам С не угодил? АП>Вопрос не в том, на чем писать уже можно. Есть идея создать новый язык, набрав понемногу из других. Очень нравится дизайн Nemerle.
Дизайн Немерле — для микроконтроллеров?
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, AVC, Вы писали:
AVC>Дизайн Немерле — для микроконтроллеров?
Нет конечно. Имею в виду сделать подобный сборник, но специфический для... контроллеров, да.
Здравствуйте, Petrovich_, Вы писали:
P_>Когда программируешь под микроконтроллер должен нравится не дизайн какого либо языка, а архитектура этого МК. В микроконтроллер идеи для которых требуются навороченные ЯП не влезут просто физически, память закончится Плюс если есть какойто специфический микроконтроллер задача написания компилятора какого либо языка под него, да еще такого который бы оптимально использовал специфику данного контроллера будет более трудоемкой чем задача написания всего софта который в этом контроллере будет крутиться на ассемблере.
Ну контроллеры разные бывают, килобайт 8 памяти кода — легко.
Ведь существуют же для них некоторые типичные решения, самые простое из которых — те же if и while. Часто приходится делать например разбор данных, пришедших откуда-то извне, или синтезировать пакеты... Это паттерн-матчинг. Я для тех же целей, но со стороны компа написал макрос для Немерла, который пакеты разбирает, на манер списков.
Здравствуйте, Алексей П, Вы писали:
AVC>>Дизайн Немерле — для микроконтроллеров? АП>Нет конечно. Имею в виду сделать подобный сборник, но специфический для... контроллеров, да.
Тогда имеет смысл начать с обсуждения требований к языку: в чем их отличие/сходство с требованиями для "больших" языков.
Наверное, лучше не предугадывать заранее, на какой из уже существующих языков это будет похоже.
Возможно, получится оригинальное решение.
Иначе, все сведется к тому, что каждый станет предлагать свой любимый язык, без учета реальных требований.
Что касается Си, то его популярность, кроме прочего, основана на том, что можно заимствовать много готового кода.
Но существует одно качество, которое нельзя купить, — это надежность. Цена надежности — погоня за крайней простотой. Это цена, которую очень богатому труднее всего заплатить.
Здравствуйте, Алексей П, Вы писали:
АП>Ну контроллеры разные бывают, килобайт 8 памяти кода — легко. АП>Ведь существуют же для них некоторые типичные решения, самые простое из которых — те же if и while. Часто приходится делать например разбор данных, пришедших откуда-то извне, или синтезировать пакеты... Это паттерн-матчинг. Я для тех же целей, но со стороны компа написал макрос для Немерла, который пакеты разбирает, на манер списков.
Основная проблема языка который как С не будет очевидным образом отображаться в асм это написание эффективного компилятороа, плюс интеграция с все темже асмом. А для типичных задач как правило существуют типичные решения которые при некотором опыте реализовуются практически на лету. Ифы и форы и так уже есть в асме, разбор данных тоже как правило реализуется довольно просто, т.к. ничего сложного как я уже писал в МК попросту не влазит. Я во всяком случае потребность в чем либо большем чем С компилятор испытываю крайне редко, да и то скорее от лени чем по необходимости.
Здравствуйте, AVC, Вы писали:
AVC>Тогда имеет смысл начать с обсуждения требований к языку: в чем их отличие/сходство с требованиями для "больших" языков.
Ну, исходя из действительной (исследовательской) задачи, которой является не создание нового языка, а компилятор, который бы оптимизировал проц под программу, можно вывести такие требования к языку:
— возможность определять очень часто используемые участки кода (хотя без профилировки видимо не получится, надо явно указывать)
— возможность производить эквивалентные преобразования кода, например разворот циклов с математической оптимизацией
Последнее очень похоже на требование к функциональности языка, т.е. отдельные участки должны быть представимы в виде лямбда-выражений. Но такой стиль программирования с контроллерами как-то не вяжется, там и список-то нормальный сделать нельзя...
Здравствуйте, FDSC, Вы писали:
FDS>Ну, эт ты загнул. Какие там форы? В самом лучшем случае аналог команды loop для Intel x86 FDS>Впрочем, незнаю как там в сигнальных МК.
Да тут я уже на сигнальники немного сьехал там есть инструкции по типу:
cntr = 10;
do loop loolabel;
some code;
looplabel:
на вышеприведенный пример будет потрачено (размер some code)*10+2 тактов, т.е. цикл будет крутиться на шару таксказать
Нам тут недавно создатель процессора рассказывал как наиболее эффективно программировать под этот проц на ассемблере, оптимизирующий компилятор с использованием его советов наверное и можно было бы написать, но вопервых в процессоре все еще есть баги (да и сам проц пка есть только в виде прошивки фпга), во вторых к моменту когда такой компилятор отладят на конвеер уже должны будут уйти чипы с прошивкой в ROMе, ну и в третьих трудозатраты на создание такого компилера будут сопоставимы с написание всего софта который будет для этого процессора когда либо написан.
ЗЫ Хотя конвееры все удлинняются и писать на асме с учетом всех сбросов конвеера и pipeline stalls становится все сложнее.
Здравствуйте, azzx, Вы писали:
A>Forth смотрел? Именно для микроконтроллеров — имеет смысл в некоторых A>приложениях (переносимость в т.ч.).
Посмотрел, раз уж все советуют. На первый взгляд — ужас и еще более ассемблер чем Си.
Программу должно быть легко не только писать, но и читать! Это я к декларативному стилю веду.
Здравствуйте, Алексей П, Вы писали:
АП>Здравствуйте, FDSC, Вы писали:
FDS>>Лично по мне: хороший ГРАФИЧЕСКИЙ язык программирования с ориентацией на ФЯ. АП>Графический? Это как?
А вы никогда в Simulink (MatLab) или OpenView не работали. SFC вы то же не видели?
Здравствуйте, Алексей П, Вы писали:
АП>Здравствуйте, azzx, Вы писали:
A>>Forth смотрел? Именно для микроконтроллеров — имеет смысл в некоторых A>>приложениях (переносимость в т.ч.). АП>Посмотрел, раз уж все советуют. На первый взгляд — ужас и еще более ассемблер чем Си. АП>Программу должно быть легко не только писать, но и читать! Это я к декларативному стилю веду.
Дка — основная трабла — синтаксис. Точнее, отсутствие оного. %)
В результате — от программиста требуется мозги и скамодисциплина.
Но именно для микроконтроллеров — вполне, имхо, подходящая цена, т.к. тут обычно
вопроса о быстрой заменяемости программиста не стоит. А вот возможности поддерживать одну
версию исходного кода для нескольких (даже разных производителей) микроконтроллеров — это то,
что некоторым очень нужно. Как-то довелось читать статью (к сожалению, ссылку не нашёл),
с описанием процессора одной фирмы (Канада, кажется) где Forth использовался для "внутреннего"
программирования трёъядерного сикроконтроллера, а "наружу" выставляется только C-компилятор.
Типа для не очень умных. Ну а Forth они ркассматривают как "конкурентное преимущество".
Здравствуйте, Алексей П, Вы писали:
АП>Как вы считаете, каким должен быть сабж? АП>Си не предлагать
А ЕС++? (Embedded C++)
Отличия от "обычного" С++:
— не поддерживается dynamic_cast и прочие type_info
— отсутствует множественное наследование
— не поддерживаются исключения
Если же стоит задача разработать свой язык, то надо понять, почему из EC++ убрали перечисленное. Да и вообще, программирование для микроконтроллеров требует немного других повадок, например:
— не должно быть привычки использовать метаинформацию в рантайме (ибо софт микроконтроллера имеет абсолютную статичность);
— уметь писать надежный код, не прибегая к технологии исключений;
— уметь кодировать состояния программы минималистическим способом (особый взгляд на использование ООП).
Fort действительно неплох для этих вещей, но нужен специфический кросс-Форт, который кладет определяющие и обычные слова в разные места. Затем при генерации бинарника надо освобождать образ от ненужных словарей.
Если ты рассматриваешь Nemerle, то тоже должен понимать специфику. Т.е. надо как-то отдельно обрабатывать код, который нужен самому компилятору, и отдельно — тот который нужен конечной программе.
Кстати, возможностей EC++ вполне хватает, чтобы программировать, например, ДКА в приятном ДКА-ориентированном синтаксисе.
Здравствуйте, vdimas, Вы писали:
V>А ЕС++? (Embedded C++)
V>Отличия от "обычного" С++: V>- не поддерживается dynamic_cast и прочие type_info V>- отсутствует множественное наследование V>- не поддерживаются исключения
В Си и тем более ++ мне больше всего не нравится идея метапрограммирования средствами препроцессора.
Пока вырисовывается такая идея системы (язык + компилер):
— Базовый синтаксис минимален, возможно даже без классов: они требуют встраивать в систему memory manager. Очень хотелось бы сделать поддержку списков, но для них крайне желательно еще и сборщик мусора, а это уж совсем не для контроллеров.
— Примитивы: скаляр (байт/слово/дв.слово?), кортеж, массив, указатель конечно, структура, любые комбинации вышеперечисленного с нормальным синтаксисом декларации типов; указатель на функцию
— Компилер пишу на Немерле, метапрограммирование через расширения в виде dll к компилятору, т.е. писать их надо на Немерле.
— Хранить скомпилированные модули в виде typed tree со всеми развернутыми макросами — типа, точно не содержит ошибок компиляции, но возможно доопределение, например generics
V>Если же стоит задача разработать свой язык, то надо понять, почему из EC++ убрали перечисленное. Да и вообще, программирование для микроконтроллеров требует немного других повадок, например: V>- не должно быть привычки использовать метаинформацию в рантайме (ибо софт микроконтроллера имеет абсолютную статичность); V>- уметь писать надежный код, не прибегая к технологии исключений; V>- уметь кодировать состояния программы минималистическим способом (особый взгляд на использование ООП).
Метапрограммирование я имел в виду статическое. А вот с исключениями да, проблемно... но может можно как-то их сделать? Продумаю.
Здравствуйте, vdimas, Вы писали:
V>Слушай, коллега. О каком Немерле речь? ФП-язык для контроллеров не подходит, ибо требует сборки мусора.
А я так и сказал, что сборщик мусора не катит...
V>В общем, согласен, что было бы неплохо что-то типа Nemerle с его макросами, но без ФЯ-фич.
Оно и выходит. На Немерле я пишу компилер, и видимо расширения к нему.
Здравствуйте, Алексей П, Вы писали:
АП>Как вы считаете, каким должен быть сабж? АП>Си не предлагать
Для микроконтроллёров с ограниченным набором ресурсов и фон-Неймановской архитектурой вычислений подходящ императивный язык со стэковой семантикой операций.
Причем уже есть куча реализаций Форта для embedded-железок.
, а там глядишь ведь ещё есть схемы РКС, язык SFC и т.п.
