Идея такая. Для PIC'ов насколько я знаю существует только одна реализация языка Си - и она платная. Также я практически не встречал реализаций Си++ для микроконтроллеров, а некоторые из его возможностей ой как хочется иногда задействовать.

После некоторой тренировки в написании интерпретаторов языков вроде Бейска я начал потихоньку писать "нечто вроде асм с элементами Си". Параллельно я обдумывал, что нужно в этом языке, а что - лишнее (применительно к микроконтроллерному программированию). Основной удар, конечно, делаю на скорость и контроль над процессом.

Где-то в конце августа предполагаю выпустить первую версию, которая будет чуть-чуть удобнее ассемблера, но как таковым Протон 1 ещё высокоуровневым языком не будет считаться.

Пару дней назад к идее решил присоединиться quarz.

Всю информацию по разработкам буду выкладывать здесь, надеюсь кому-нибудь будет полезно. Если у кого есть какие-то идеи, которые хотели бы увидеть в Протоне - пишите. 

Это сообщение отредактировал(а) ManiaK - 4.3.2008, 13:11

Ух ты...
Поподробнее бы узнать, как это - ассемблер с элементами C.
Чего мне не хватало, когда работал на асме 51
- так это автоматизации распределения памяти под переменные.

Цитата(Crait @ 5.8.2005, 17:40)

Поподробнее бы узнать, как это - ассемблер с элементами C.

На этих выходных попытаюсь оформить

Цитата(Crait @ 5.8.2005, 17:40)

Чего мне не хватало, когда работал на асме 51 - так это автоматизации распределения памяти под переменные.

По-подробней пожалуйста.

прочёл название как "Высокоуровневый язык Питон для микроконтроллеров PIC". %)) аж дыхание перехватило. %)

(абзац. нельзя столько времени на работе проводить...)

Модератор: попрошу не флеймить...

Итак. Вот примерно то, что будет в первой сборке через неделю (альфа версия).

Во-первых. Протон - не столько самостоятельный язык, сколько надстройка над ассемблером. Все программы написанные на ассемблере без проблем компилируются как протоновские с одной - на синтаксис (каждая строка кода заканчивается ';' + Си-коментарии).

Вот пример программы на Протоне:

Код

orgd 0x03; byte_t Status;// Данная переменная располагается по адресу 0x03 (STATUS регистр) /* Демонстрационная программа */ main(byte_t Ch)// Это не то, что вы думаете :-) {     Status = Ch;// Г-гы :)) } orgc 0;// Точка запуска программы - ЗДЕСЬ!.. goto 10; orgc 4;// Если память не изменяет - это прерывания... swapf Status, 0// Хулиганим.... orgc 10; Status.bits[5] = 1;// У кого-то сейчас глаза на лоб полезут... :-) // ... и я даже догадываюсь кто это будет ... main(0xAA);// ХЛОП!.. goto pc-1;// Переход на прошлую строку кода :))

Как видно из этой демонстрационной совершенно бессмысленной программы, точка старта программы - это, отнюдь, не функция main Это первая команда программы (pc=0). Кроме того, стандартный тип byte_t (байт) оказывается несколько нестандартным В Протоне все базовые типы ничем не отличаются от определяемых пользователем, короме как тем, что их нельзя убрать. Но поддержку определяемых типов через неделю обещать не могу.

pc при использовании команды goto - это номер строки кода (строки заканчиваются точкой с запятой, не текстовые строки имеется ввиду). В определении функции можно не указывать возвращаемый параметр если функция ничего не возвращает. Вот, вообщем и всё, что я пока напридумывал

Как видно, все эти преобразования отличаются тем, что я не изобретаю свой язык, а лишь делаю надстройку над ассемблером - такая логика, как я считаю, может оказаться полезной, хотя пока я сам не вижу особого прорыва

Это сообщение отредактировал(а) ManiaK - 8.8.2005, 15:35

ManiaK хорошая затея. Одно время разрабатывал идею макро-ассемблера для x51, но идея оказалась замученой и не выжила.

А одной из причин была как раз не переносимость. Птому как не хочеться знать где у контроллера точка входа, как реализованны прерывания и т.д. Ещё большой проблемой был вызов существующих функций/процедур, написанных на асме. Каждый человек пишет по своему, кто то любит получать аргументы в регистрах, кто то обьявляет функции без рекурсии и "бронирует" место под аргументы, кто то пользуеться стеком(чего под PIC'ом нет...). Нужна была схема, описываемая формальным языком. А затем можно было вызывать: procedure(ar1, arg2, arg3): schema(keil c);
Конструкция должна разбираться в момент компиляции, потому если функция меняеться(либа компилилась другим компилером), то схему тоже нужно менять.


Вообщем складывай идеи, если нужна помощь(например задокументировать твой код, мануал и т.д.), с радостью

Цитата

По-подробней пожалуйста

Программируя на ассемблере 51, достаточно затруднительно было
обращаться к переменным на стеке (кстати, такой механизм - IMHO,
ещё один кандидат на то, чтобы повысить "уровень" ассемблера),
поэтому я обычно переменные делал статическими
(статическими в смысле языка C), ну и начинались танцы с бубном
- во-первых, размещением этих переменных в памяти с определённого
адреса занималась кучка самопальных макросов, во-вторых,
используя этот механизм, оптимально распределить память
было нельзя (некоторые процедуры точно не вызывают друг друга
и не активны одновременно, но память для их переменных
распределяется в разных адресах, а можно бы было
разделять пространство этих переменных).
Потом ещё, помню, была проблема - с какого адреса
начать распределять память, ибо довольно большой кусок
в архитектуре 51 отведён под битовые флаги, и часть их
также используется. Ещё есть регистровые банки, они, помнится,
тоже могли делать область статических переменных
фрагментированной.
Для других архитектур всё это, возможно, не актуально.

Вот ещё что было бы полезно : автоматический анализ используемых
подпрограммами регистров (с учётом вызовов всех
используемых в ней подпрограмм).

ИМXО для микроконтроллеров полезны такие фичи как:

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

Такой язык не удобен для компов, но удобен для микроконтроллеров, от простых, до сложных.

Цитата(Sardar @ 9.8.2005, 00:23)

если нужна помощь(например задокументировать твой код, мануал и т.д.), с радостью

Именно этим мне заниматься некогда, да и не умею я. Учту

Crait В pic12f675 стека как такового нет, поэтому эту идею я буду откатывать уже на нём. Только её надо доработать, передаваемые параметры для меня тоже пока проблема.

Цитата(Crait @ 9.8.2005, 04:43)

Вот ещё что было бы полезно : автоматический анализ используемых подпрограммами регистров (с учётом вызовов всех используемых в ней подпрограмм).

А для чего? Просто как информация кодеру?..

Цитата(Sardar @ 9.8.2005, 05:26)

процеруды и функции, а не просто функции

Если процедура от функции отличается только тем, что ничего не возвращает, то main на примере выше - процедура Кстати я подумал, там надо будет вставлять определитель func иначе трудно будет отделить в некоторых местах объявления переменных от деклараций процедур...

Цитата(Sardar @ 9.8.2005, 05:26)

задание физических адресов для переменных, т.е есть переменные которые не важно в какой окажуться памяти, а есть переменные с постоянным адресом, зачастую системные регистры.

У меня хитрость такая. Директива orgd перемещает каретку компилятора на нужный адрес. Допустим пишем - "orgd 0x03;". Каретка сдвинулась на третий адрес. После этого первая байтовая переменная, объявленная ниже будет лежать по адресу 0x03 (для pic12f675 это регистр STATUS). При объявлении переменной каретка сдвигается выше по адресу на размер переменной. Если мы следом объявим ещё одну байтовую переменную она будет лежать по адресу 0x04. То есть: 1. Мы не забиваем голову себе распределением переменных; если не нужно указывать конкретный адрес для каждой - указываем только для первой; 2. Мы имеем отличную возможность определять для каждой переменной свой адрес. По-моему удобно. Но для статических переменных, в динамические я пока вообще не лезу, это бы реализовать...

Цитата(Sardar @ 9.8.2005, 05:26)

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

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

Цитата(Sardar @ 9.8.2005, 05:26)

"Арифметика памяти" как в C

Не очень понял. Это ты про указатели?..

Цитата(ManiaK @ 9.8.2005, 10:25)

А для чего? Просто как информация кодеру?..

Ну да. Чтоб знать, какие регистры портятся.

Цитата(Crait @ 9.8.2005, 13:52)

Ну да. Чтоб знать, какие регистры портятся.

Это скорее функция IDE, а не компилятора. Хотя можно писать эту инфу в lst файл.

Цитата(ManiaK @ 9.8.2005, 13:24)

Это скорее функция IDE, а не компилятора.

Наоборот это функция компилятора, он должен выдать как используеться память, где ты наложил переменные друг на дружку и т.д.

Цитата(ManiaK @ 9.8.2005, 09:25)

Если процедура от функции отличается только тем, что ничего не возвращает, то main на примере выше - процедура

Синтаксис может быть каким угодно, пусть визуально процедура от функции не отличаеться, допустим function void main(...

При этом если мы пишем public int myvar=main(...) - то компиплер должен ругнуться.

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

Я когда то хотел придумать механизм схем. Схемы описывают где размещат переменные, перед вызовом "сабрутины", и где найти потом "возвращаемый результат". Затем обе схемы связываються с функцией.

Представим случай, есть средненкий микроконтроллер(х51, DS80320 память внешняя), в нём "загруженна" либа с общим функционалом и кооперативным менеждером задач. Всё это написанно на асме. Контроллер читает несколько сенсоров, простенько сжимает полученную инфу и пишет на какой нибудь большой флеш. Потключен какой нибудь сетью к общей системе, если что то не ладно, отсылает сигнал тревоги.

Пишем пару задачь/тредов, что будут выполнять работу. Вдруг упираемся что способ вызова твоей процедуры отличаеться от принятого в "системной" либе. Можно писать вызов на асме, но так придёться для всех функций, тогда смысла писать на "высокоуровневом" языке особо нет. Для этого нужны схемы возовов и получения результата. Функция может отдать не только один тип или массив, но и tuple, часть которого в регистрах, часть в памяти, ещё часть в стеке

Вот эту идею я не развил

Цитата(Sardar @ 9.8.2005, 17:53)

Вот эту идею я не развил

А надо Именно в этом весь смысл нового языка программирования. Я подумаю...

Цитата

Для PIC'ов насколько я знаю существует только одна реализация языка Си - и она платная.

а про GCC забыли? Я им пользуюсь под AVR, но под PIC его тоже можно скомпилить.

каким же образм, smalcom ? У пиков совсем другие команды, более того, их всего 35.

все предельно просто. берешь GCC и компилишь его(ну там еще binutils надо), так вот если надо для AVR , то пишешь в configure: --target=avr, а для PIC'ов --target=pic. И юзаешь себе C

да уж по поводу gcc я поторопился , но есть выход из положения. Первый - это линки нарытые мной в смущенном состоянии в сети

http://sdcc.sourceforge.net
http://anyc.sourceforge.net

Второй более глубокий но рулезный и думаю равноценный написанию ПРОТОН'а - когда ставица GCC ему через опции передаеца для какого процессора он будет создавать код, так вот можно посмотреть что он делает для AVR, сравнить архитектуры PIC и AVR и возможно чего дописать и нам хорошо и весь мир OpenSource будет благодарен(надеюсь).

smalcom Спасибо за ссылки, но задача именно разработать качественно новый язык специально для микроконтроллеров. Это интересно
Кстати, обсуждение теперь лучше вести тут: http://forum.qpp.ru/index.php?showtopic=3
Здесь всё же форум по решению проблем, а не разработке проектов. Эта тема скоро будет закрыта.

Модератор: тема закрыта. Всё обсуждение и вся информация о Протоне - по ссылке, указанной в посте выше.

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

1. Для микроконтроллеров сейчас необходим не ещё один Си-подобный язык, а язык, основанный на обобщении Ассемблера.

Иначе говоря, язык не должен вводить в Ассемблер никаких новых возможностей, но должен облегчить те задачи, которые выполняются программистами-ембеддерами ежедневно и выполняются с достаточной степенью схожести. И ключевые понятия здесь - процедуры и функции. Никаких переменных - у нас только голая память, которая, впрочем, может быть разбита на переменные - но условно!

2. Необходим более мощный препроцессор, нежели тот, что заложен в Си.

Если шаблоны в Си++ являют собой обобщение высокоуровневых операций (над типами главным образом), то в Протоне необходимо развить механизм автоматизации написания кода Ассемблерного. Иначе - все те механизмы, которые запускаются на этапе компиляции и ни в каком виде не фигурируют в конечном бинарном коде. Такие механизмы не тратят никаких ресурсов, однако на их основе часто можно организовать очень полезные в хозяйстве вещи, такие как автоматизированное размещение переменных (точнее того, что будет называться переменными; реально никаких переменных в Протоне, как и в Ассемблере нет, конечно) в оперативной памяти. На препроцессоре можно построить целый субязык. Сейчас у меня всё это в голове крутится, но на бумаге изложить нормально не могу, ухватить за хвост мысль, так сказать



Сейчас перед экзаменом трудно понять, что из этого вытечет и пр., а потому дальнейший анализ - чуть позже

Это сообщение отредактировал(а) ManiaK - 21.1.2006, 00:51

Идея всё-таки не умерла. Хотя в состоянии плачевном.

1. Лично мне кажется, что язык Си слишком высокоуровневый для микроконтроллеров.
2. Не под все embedded-платфоры есть бесплатные легальные трансляторы Си->Asm.
3. Ни один из существующих компиляторов, по моим данным, не протестирован современными научными методами.

Актуален ли хотя бы для посетителей этого форума данный вопрос?

Со своей стороны могу предложить:
    - Общение с фирмами-производителями микроконтроллеров от имени достаточно известного зарубежом Института Системного Программирования РАН.
    - Современные научные методы верификации нового компилятора

По деталям нового языка:
    1) Си-подобный (но не клонированный) синтаксис
    2) Возможность на уровне языка определять способ передачи аргументов в функции
    3) Однозначное соответствие между кодом на Языке и двоичным кодом (местоположение объектов, их размер, формат представления, ...)

Возможные платформы: PIC, ATmega, ATxxx, Fujitsu mb90xxx.

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

Прямая работа с памятью всё таки не очень хорошо. Моя идея выродилась в байткод, который обращаем в нативный при каждой сборке проекта.  Байткод самодостаточен, высокоровневый. Собирает память в сложные структуры, определяет для них операции. Свойства (аттрибуты) переменных и кода отслеживаются на манер, как Haskell отслеживает типы.

Аттрибутов много, задают границы манипуляций с кодом. К примеру переменная может быть связана с некоторым общим понятием из схемы девайса (регистр SP к примеру, при чём кидаем ошибку если схема удовлетворить свойства не смогла) или иметь жёстко заданный адрес. Хотя чаще переменные не будут требовать адреса, память управляется системой.

Код разделён на функции, функция изменяет своё поведение только согласно переданным аргументам (никаких глобальных переменных). Для собственных функций передача аргументов никак не оговаривается, система просто предоставит их в коде. Функция не рекурсивна, пока не будет отслежен сценарий, когда она будет вызвана рекурсивно. Отсюда ясно, что функции не являются конкретными процедурами, которе можно вызвать из левой asm'овой либы, конкретный код генерится из тела функции только ели он был использован, поэтому функция не имеет физического адреса. При генерации кода будут собраны все используемые функции, эквивалентные выражения будут собраны в ообщий код, отслеживается общая память (если две функции никогда не будут вызваны вместе, то память под их аргументы можно расшарить). Плюсы: код всегда максимально оптимизирован. Минусы: process image всегда меняется.

Функциям можно придать такие свойства как постоянный адрес, либо то, что она может быть вызвана из любого места (такая функция всегда будет присутствовать в process image, доступна для любых либ). Это заставит сборщик выделять экслюзивные ресурсы для этих функций.

Типов данных нет, на твой манер собираются сложные структуры массивов байти других структур. Можно всегда "увидеть"/применить какой либо тип к любому участку структуры. К структуре определяются операции над этой структурой,  код задаётся на asm'е для конкретного девайса. Так получаются int'ы, float'ы и прочие типы.

Идея была большая, но умерла как только перестал работать с микроконтроллерами. По любому новый язык никому не будет нужен, будут плеваться, извращаться, но использовать C - так сказало руководство 
Может поэтому ушёл в обычный прикладной софт, тут креатива больше.

Добавлено через 3 минуты и 26 секунд

Это плохо, теряется поле для оптимизации. Лучше явно объявлять функции, что могут быть использованы вне системы. Всё остальное собирается и упрощается до минимума, достаточного для вычисления результата. Реальные функции могут "исчезать" (вырождаться, вставляться inline), а могут появляться новые (на манер шаблонов в C++).

Забыл пояснить в предыдущем моём сообщении: сейчас мой взгляд на то, каким должен быть язык программирования для embedded-платформ (здесь: для платформ с катастрофически малым запасом ресурсов и относительно небольшой скоростью работы), совершенно иной, если сравнивать его со взглядом того времени, когда я начал этот топик. Следует рассматривать только последнее сообщение.

Sardar, понял очень смутно твою идею. С переменными понял.



Что такое - собственная функция? И что значит - просто предоставит их в коде? Поясни, пожалуйста подробней.



Моя идея состояла в другом. Я как раз не хотел отдавать оптимизацию компилятору, напротив: я хотел забрать у языка Си то, что мне было бы полезно при оптимизации, но при этом максимально сохранив простоту работы с функциями и переменными.



Я тоже сейчас занимаюсь "прикладным софтом", но всё же хотел бы вернуться к контроллерам. Оно мне роднее, да и в России, похоже, начинается подъём мелкого предпринимательства, значит и частные рукодельцы нужны будут. А имея возможность прикрыться дипломом и повторить подвиг Торвальдса, написав компилятор для диплома и для себя одновременно, было бы недурно, согласись? 

Добавлено через 1 минуту и 37 секунд
Я всё же в раздумьях относительно верности вектора моих размышлений, поэтому, Sardar, жду от тебя пояснений.

Это сообщение отредактировал(а) ManiaK - 4.3.2008, 16:26

Функция определённая на этом (новом) языке и не доступная как API другим (внешним, чужим) либам. Компилятор может делать с ней всё, что угодно, упростить, создать реальную функцию, вставить блоком в другую функцию, выполнить на этапе компиляции и заменить константой и т.п.


Расчитать нужен ли конкретный аргумент, как его лучше передать в функцию, выделить под него ресурсы. Зависит от железки, для тебя же это просто аргумент, которым можно пользоваться. К примеру можно оптимизировать использование функции, если точно известно, что она не меняет свои аргументы (если в языке есть INOUT аргументы).


А зачем? Конечно ты веришь, что можешь написать под конкретный камень наиболее оптимизированный код. Только код не переносим, без большой переработки кода новые фичи не добавить, да и не всегда удаётся удержать софтину в голове, если проект растягивается на пару сотен функций (отсюда менее эффективная, но более простая работа с аргументами, баги).



Ты по моему хочешь построить ассемблер, дополненный макросами для обычных, рутинных операций. Штука по идее вредная, т.к. привязывает к железу. C - по сути высокоуровневый ассемблер, этим он и хорошь - компилить под разное железо. Хотя язык ограничен, люди извращаются разными расширениями (к примеру прерывания у SDCC) или макросами с чёрной магией.

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

Sardar, мы работали, видимо, в диаметрально противоположных углах embeded-области. Я занимался преимущественно микроконтроллерами с настолько низкими запасами ресурсов, что не то, что сотни - пары десятков функций уже будет много. Программы для таких кристалло обычно представляют собой вполне обозримый код, полностью обозримый. И проблема переносимости тут так остро не стоит. Зато проблемы скорости и миниатюрности - на первом плане!



Да, что-то вроде этого. Кстати, сейчас до меня дошло, что это действительно макросы, но узкоспрофилированные. Кстати тогда возможно и новым языком мой гипотетический Язык назвать нельзя: это ведь просто очередной ассемблер-транслятор с макросредствами, синтаксисом похожие на язык Си...



Теперь понятно. Тогда такой вопрос: какими контроллерами ты пользовался, когда разрабатывал этот язык, и какие задачи выполнял?

ManiaK я тож на досуге разрабатываю язык для контроллеров. Именно твоя идея близка..  Си расширенный низкоуровневыми возможностями для оптимизации.

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

Идея такая заставить кампилить функции поразному..

Или например передавать и возвращать переменные из функций не только через стек..

Мини-вебсервер на eZ80 проце, вернее этот девайс. Ты прав, там с ресурсами действительно посвободнее чем в pic'е... 
С железкой идёт RTOS, каркас вебсервера и всякие полезные либы. Нужен был темплейтер для страниц, нормальная, очень компактная работа со строками (константы, ссылки на блоки, никаких копирований массивов символов) + нормальная среда для разработки простых XML сервисов. Начали с разработки языка, к середине забили, написали на чистых C'ях + собственные либы из движка языка.